PDA

View Full Version : Compile display lists and multithreading



aronsatie
03-04-2007, 01:45 PM
Hi,

My question is: is it possible to compile a display list (without calling it!) in one thread while open gl renders in another thread.

Thanks.

Zengar
03-04-2007, 03:22 PM
A GL Context is bound to a thread, so you can't call GL commands for the same context in different threads. You could create a second context and share you dispay list space, but a better choice would be using the VBOs :-)

aronsatie
03-05-2007, 03:54 AM
Thanks.

Next question (sorry if it is trivial): Can I use a VBO to store material data (diffuse and specular colour, shininess, etc.)?

I know a VBO is more flexible than a display list, I just wanted to know if I can use display lists efficiently for never or infrequently changing data. I thought that if some data changed, I can free the corresponding display list and compile a new one.

I plan to use a lot of text in my application, and font outlines are stored in display lists. Do you think that I should use VBOs for everything else (geometry, materials)?

Thanks for the help.

oc2k1
03-05-2007, 04:20 AM
Store the material data as uniform variables. (if they are per mesh)

The VBO stores only the per vertex attributes (position, per vertex color, normal, tangent....)

aronsatie
03-05-2007, 08:59 AM
Could you elaborate this a little further and maybe with a sample or a link to a sample?

This is exactly my problem. I don't need per vertex colours, I use materials (with ambient, diffuse and specular colours, etc.) instead. I would only use one material for one VBO (1 VBO= 1 mesh). Is it possible without having to use immediate mode?

Thanks.

knackered
03-05-2007, 09:22 AM
VBO's have nothing to do with fixed function materials. VBO's are for storing vertex attributes (pos,texcoord,colour etc.), nothing else.
Use display lists for your materials if you want, you will claw back some CPU but probably not any rendering performance. Share the display lists between your 2 threads/contexts, but put in place some kind of synchronisation, so as you're compiling a display list in the worker thread, your render thread is not trying to draw it...otherwise you may get undefined/undesirable results.

aronsatie
03-05-2007, 10:49 AM
"Use display lists for your materials if you want, you will claw back some CPU but probably not any rendering performance"

Do you think it would not be a lot faster to switch from one material to the other when I draw the elements of my scene if I used display lists? Because if the gain is negligible than I don't think it would be worth the bother. The extra CPU time I would gain I don't need. I will dedicate a full CPU core for rendering.

My application won't need millions of vertices and will use at most up to a hundred materials at a time. Probably a lot less. I just thought it would be worth a little effort to optimize when I use only a few materials but still switch between them dozens of times. But is it really worth the effort (share display lists, etc. although I can easily guarantee that a display list being compiled by another thread will not get called by the rendering thread until it is ready)?

Thanks.

Zengar
03-05-2007, 11:32 AM
Originally posted by aronsatie:

Do you think it would not be a lot faster to switch from one material to the other when I draw the elements of my scene if I used display lists?
I don't think you will see any gain at all. Just store your material settings along with your VBO and call the Material command before each drawing. This is more flexible too, you can change the material for the same mesh which won't be possible with display lists. VBOs are supported on almost all consumer hardware nowadays, they were integrated in 1.5

knackered
03-05-2007, 11:50 AM
In the end, it probably comes down to function call overhead. A single glCallList versus 4 or 5 glMaterial calls. But then again what does the driver do when it gets a glCallList? Is the look up expensive versus just setting some uniforms (which is what is happening under the hood whenever you call glMaterial - all modern hardware is shader based emulating fixed function)?
If I were you I wouldn't bother compiling my materials into display lists.
Also, be aware that display lists are only worth while on nvidia hardware - lesser hardware such as ATI don't have good support for display lists, as they're mainly a D3d/gamers IHV.

aronsatie
03-05-2007, 01:30 PM
You sound very convincing, so I started thinking about why I even asked this question. Then I found that on page 283 of the read book it suggests that lights, material properties and lighting models can be optimized by compiling them into display lists.

But probably this is not the case for me. I will set the ambient only once for the scene and not per mesh (I see no point in it). This leaves the diffuse and specular colours that would change quite a few times and several others less frequently (I plan to use parameters like culling, PolygonMode, BlendFunc, BlendEquation, etc. as parameters for a material).

Maybe I can store current values and use the CPU to check for only the parameters of the next material that are different. All in 'immediate' mode.

Do you think it is the best thing to do? It certainly is the easiest.

Sorry for asking for a 'final confirmation', I just want to make sure.

Thanks.

aronsatie
03-05-2007, 01:32 PM
I forgot to mention that I will not bother with all types of VGA card, I will only support Nvidia and G80 or better. I can do that easily, because the application will be more or less for my own use :)

Zengar
03-05-2007, 01:49 PM
> I will only support Nvidia and G80 or better

Then you have all the cards ;-)

The method you suggest sounds most reasonable to me. You could also implement some sorting, so that objects that use the same material settings are drawn in groups, but that is most probably not worth the time.

Why bother with the fixed function pipeline anyway? Just implement your own lighting and you will end with better quality and performance anyway.

aronsatie
03-05-2007, 02:42 PM
"Why bother with the fixed function pipeline anyway? Just implement your own lighting and you will end with better quality and performance anyway."

I suspect you are referring to something I don't know. Could you please elaborate?

knackered
03-05-2007, 04:07 PM
look at the left panel on this page:-
http://www.lighthouse3d.com/opengl/glsl/index.php?intro

aronsatie
03-06-2007, 12:15 AM
Aha, I thought so. Maybe for version 2.0 :)

Right now I want to have a working version and there is still a lot of other stuff I don't have experience with.

Thanks, guys.