| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> You have somehow limitations on per pixel control, but there are other methods you can use instead.
<0> You don't have full access to the framebuffer.
<0> As Maloeran said, it's rasterization. Everything is mostly done with vertices.
<1> Okay, that's the kind of thing I was wondering.
<1> One thing i wish was present was letting me do matrix transforms directly. I have a former coworker that needs a lot of FFTs done on very large float data.
<0> You can.
<1> Some insane number of 1000x10,000
<2> If there isn't random memory access or branching, GPUs could help
<0> Make your matrix, and then use glLoadMatrix* or glMultMatrix*
<1> IT's just a FFT
<0> They have to be 4x4
<2> That's not exactly what I had in mind... :)
<1> FFT requires the whole matrix to operate.
<2> Store yor input data in textures, write specialized fragment programs
<0> GPU math is fun.
<1> They are considering it.
<0> Still somehow akward. I hope it becomes easier with Directx10
<1> FFT&IFFT are pretty common operations. I bet someone has already written a lib to do it, I would think that would be one of the first things you want to do
<2> Yes, there are libraries for GPU based computations
<1> Do you know the names? I bet he'd like it if he can p*** it on
<2> GPGPU I think it was called, there are others
<2> You better have a look yourself to see what meets your needs
<2> Actually, have a look at Nvidia's CUDA
<1> Thank you, I'll p*** it on to him. CUDA seems just like what he's looking for
<1> if he can use that to do the FFT and IFFT, that would really reduce their workload.
<1> He'll probably end up with a hell of a machine to play quake 4 on....
<1> If he can prove to his boss that it's worth it, they have no problem dropping $10k in a heartbeat.
<1> HAHA! But he'll have to multi-thread. I warned him this day was coming.
<2> It's far worse than multi-thread ;), GPUs are a tricky and... akward computation platform
<1> But there is an existing app, that's not written thread-safe.
<1> It's VERY not thread-safe.
<2> Poor planning then
<1> Yeah. Their app would really chew up a multi-core system. FFT would work well on it.
<2> Is it using SSE, prefetching, etc.?
<1> It uses a lib written by intel for doing FFT's
<2> So I guess it does, okay
<1> But the ffts are broken up into parts. Each part is independent.
<1> So you can FFT part 1 and part 2 at the same time, and they have indepent results. And there's like 500 parts.
<1> Actually.... I gota suggest that to him.
<2> Quite easy to parallelize
<1> Or get him to let me work on it for $$$$$
<1> I could REALLY speed it up throwing it at a multi-core system. And they have the funding to drop it on a lot of cores.
<1> Multi-core would pay off for them, because they have to operate on 1 set of data really fast.
<1> The set is something crazy like 250megs I don't remember the exact numbers.
<1> The problem is almost all ops will be a cache miss, FFT has to scan all of the data once to do a full loop. It's a matrix multiply.
<2> You really should be prefetching memory in that kind of problem
<1> I'm guessing the intel libs do that already.
<2> Perhaps so, but then cache misses shouldn't be too severe
<1> Yeah. But it's hard to do stuff like throw it on a bunch of machines because the io cost is soo high.
<1> But if he can queue up his calls to the IPPs and throw it on a 2x2 core system....
<2> Sure thing. That vaguely reminds me the distributed fluid dynamics computations I'll soon have to deal with
<1> Actually it's about the same problem.
<1> Hehe, I need to start lining that up as a backup plan. Just in case.
<1> Never hurts to have a spare job laying around.
<1> so when does swtiching from glVertex to glDrawElements start paying off?
<2> When dealing with hundreds, thousands vertices per frame
<1> I know opensl breaks that
<1> Heck, most objects in SL are cubes. 4*6 is 24 vectors each.
<1> 100 objects onscreen is nothing.
<1> How many objects do you have to do at once for it to pay off, I doubt calling drawElements works well on one point.
<2> You can't switch textures within a glDrawElements(), so the short answer would be... as many as possible
<1> Ouch, that's painful for this.
<1> Everything has a texture.
<2> Switch textures and vertex/fragment pipelines as rarely as possible
<1> Switching textures is required for every face.
<1> What do you mean by vertex/fragment pipeline?
<2> "Shaders"
<1> ah
<1> Okay, they have ****y shaders, so that's not a problem.
<1> Shaders are hard to turn on, so that's not a risk.
<2> You want to switch state as rarely as possible, rendering as much as possible between changes
<2> Bind texture A, render all that is visible and uses texture A, Bind texture B, [..]
<1> can you switch colors?
<2> Yes
<1> I wish it supported textures :(
<1> It would save soo much effort.
<2> It's a matter of efficiency
<2> You can hardly change textures between two glDrawElements(), that isn't the point..
<1> Yeah, but every quad needs a new surface.
<2> You can already* change
<1> I want one gldrawelements that lets me render... everything.
<2> As I said, sounds like very poor design :)
<1> Well it's a high-texture app.
<2> Primitives using the same texture should be rendered together
<1> Very few things use the same texture
<1> But is there a noticeable improvement by switching from rendering using glVector over gldrawElements? Just switching groups of 4 or 6 quads to using it?
<2> You won't see much of a difference, perhaps a tiny one...
<1> Okay
<1> Humm. Definatly ****s.
<1> There's linked groups, but I don't know if linked groups are pulled down all at once.
<1> linked groups are close to surfaces.
<3> wouldn't display lists be better as a simple optimization in SL?
<1> How so? I'm a opengl noob.
<3> an easier conversion was what I was thinking of :p
<3> without much loss in performance over drawElements
<1> What do you mean?
<3> well, a display list is more or less a compiled list of GL commands
<1> Ah, sounds good.
<3> that's to my understanding though, someone more experienced would have to comment more closely on that :p
<1> This code would be easy to make it use display lists. (I Just crashed coursed on them)
<1> All of the objects are inside of a C++ object. We can detect when the fields that build the object change.
<1> and invalidate the display list
<3> you could always give it a shot and profile it
<1> My big worries is that the display lists would be really short.
<2> You won't gain much there either, and display lists aren't always well optimized in drivers
<3> well, have you profiled SL in it's current stage?
<2> And profiling of OpenGL code never produces meaningful results..
<3> I thought that glDEBugger thingy or whatever did it pretty well?
<1> Nope, I don't know how. I'll learn soon.
<2> Oh sure, if you use a ogl-specific profiler of some sort
<1> Right now is to tinker and learn.
<3> anyway, gotta run, see you all later
<1> Thanks
<1> Oh no! this takes s, t, r, q... @#$@#$@
<1> Is that a Quaternion?
<2> Texturing coordinates?
<1> yes
<1> Or is that just texture cords in x, y, z, w?
<2> No, these are not quaternions, but coordinates
<2> Right
<1> okay, I'm still working on w... why does it default to 1?
<2> Read the redbook chapter on matrix transformations, it should be clear enough
<1> Thanks
<1> will do
<1> So what tools are there for measuring opengl code?
<4> Measuring?
<1> I want to insturment sections so I can see how change XXX effects render time.
<4> http://www.gremedy.com/
<4> I think NV has a suite of tools too, for use with their drivers
<4> I wouldnt be surprised if Ati had something similar
<1> How convient, I have a nvidia card!
<5> but would you be suprised if I did this "HOOOODEEEBADABA JOW JING JANGLE ABRA KADABRA"!!!!
<1> do you know the name of the nvidia tool? It'll make it much easier ot search for
<2> Nvidia profiler should lead to it
<1> doah! I was searching for nvidia profile...
<1> nvprefkit. Thanks
<5> http://world.std.com/~sweetser/quaternions/qindex/qindex.html
<5> lots of neat physics crap in there
<6> hi... again... well uniti if you still care to explain me i'm here to listen now D
<6> (the nurbs stuff)
<2> Did you have a look at http://fly.cc.fer.hr/~unreal/theredbook/chapter11.html ?
<2> Redbook's chapter on evaluators
<6> not yet... but evaluators sound like the bezier stuff
<6> ok read it... the article spares the details about using the knots
<6> first i would need the simple case of a straight line (without any magnetic effect) of maybe 3 points
<6> how would the appropiate knot vector look alike?
<7> using GL_LINE_STRIP and GL_SMOOTH I'm getting small gaps between line segments - is there any way to fix this?
<8> glHint(GL_LINE_SMOOTH_HINT, GL_NICEST)?
<9> i'm making a sphere in opengl. should i use lots of GL_QUADS or GL_QUAD_STRIP for each z depth?
<7> jenova - nope
Return to
#opengl
or
Go to some related
logs:
#politics
#nhl
#gamedev
jwawintype PULONG_ptr
dos2c64
execvp permission denied mpif77
#sunos
#computers
gigedy.com
#freebsd
|
|