I was not really interested in DX11’s API improvements till now only the hardware features as I’m always using OpenGL. However, a week ago or so somebody pointed me to DX11 deferred contexts so I decided to check that out.
The funny thing is that DX11 deferred context mechanism with its command list reminds me of an OpenGL feature: display lists
Actually the use case what they all talk about of DX11 deferred context is the following:
Thread #1: construct a command list in the deferred context
Thread #2: execute the command list in the immediate context
The funny thing is that (if I’m not wrong) is actually equivalent with the use of OpenGL display lists (which can be shared between contexts) so it is the same like the following:
Thread #1: compile display list in one context
Thread #2: execute the display list in the other context
What is really weird about this for me is why is that DX introduced this feature in their 11th version of the API while OpenGL marked it as deprecated since GL 3.0? This looks pretty funny
Maybe I’m missing something, but if they are really functionally equivalent then the question is: why we deprecated display lists?
Don’t make me wrong, I’m not a fan of display lists for a long time now, because it is simply unmanageable to decide when and how you can use various features inside display lists. Also OpenGL display lists are not friends with VBOs and actually that defeats their use in modern OpenGL, but these information made me think that we need a new refactored form of display lists back into core GL that would nicely interwork with VBO and stuff.
Rendering with display lists pulls all the vertex data into display list memory. If you draw 10^6 tris, they need to be copied from your vbo to display list. I think you ment this when you said they are not friends with vbo
This pretty much makes display lists useless for rendering. I have however seen a pretty cool display lists usage in an opensource project (cant remember name now) that used dl to create ‘state objects’. That was actually pretty cool.
Yes, I meant that. Actually that’s the main reason why display list is really deprecated. But otherwise it was okay.
I also used it for that purpose in the past, e.g. create some immutable blend state objects or complete material objects, but that was a long time ago (however, the principle still applies).
Anyway, I was just thinking that maybe a revised version of display lists could come back to OpenGL as it seems the DX11 deferred context idea became popular so most probably a modern version of display lists would also make OpenGL developers happy.
Deprecating Display Lists was very controversial. NVIDA was strongly against it. The concept of display lists is very good and I agree with you that OpenGL needs a new refactored form of display lists back into core.
Actually, I popped up with the topic because I started to write an OpenGL C++ wrapper, well, better to call it an abstraction layer as it is not a tight as possible layer.
The more I progress with it the more I see that there are too many context states and a lot of them belong to a particular operation inside the OpenGL rendering pipeline (e.g. blend state configuration).
I wanted originally to make it a generic wrapper for the community to access GL3+ but I see that writing a library that is good for everybody is practically impossible.
That’s why I’m now thinking of introducing some state objects that are not explicitly exposed by the GL spec (again, like blend state objects). Now I’m actually thinking again using display lists for these, but I hardly make myself decide to use something that is not in GL3 core…
Now I’m in a moral crisis :eek:
Should I stick to GL3 core despite the not-so-complete nature of it or fill the holes with display list based immutable objects?
Everyone implements compatibility spec, so if you dont need to be portable to ES then using compatibility with features that make sense for you (like dl here) is the way to go.
I know that there is and will be support for it and I definitely not plan to go for ES (at least not with my current project as it targets GL4+ and maybe GL3+ GPUs), but I feel like I should not use deprecated stuff. You know, it’s just an ideological thing as I strongly support the deprecation mechanism.
Anyway, maybe I’ll simply go with display lists and if there will be better alternative in OpenGL then I’ll use them. Actually don’t really have any other choice (if I would like to have better encapsulation and performance).
Maybe I’m missing something, but if they are really functionally equivalent then the question is: why we deprecated display lists?
Because they aren’t functionally equivalent. As you yourself point out, there are fundamental differences between the two.
There’s the drawing issue you pointed out. D3D commands reference objects. They refer to buffers and such. Therefore, if you change the contents of the buffer (not its location), the D3D command will see those changes. OpenGL requires that vertex state be absorbed into OpenGL display lists as is. So if you have some dynamic terrain, display lists cannot help you.
The problem is that DLs try to solve two distinct problems. One problem is giving an OpenGL implementation the freedom to arrange your vertex data for maximum transfer speed. The other is storing a sequence of rendering commands. The first interferes with the second.
These two problems need to be made into their own separate functionality.
Deprecating Display Lists was very controversial. NVIDA was strongly against it.
NVIDIA was strongly against removing anything, so display lists naturally fell under that.
I completely agree with you, Alfonse, both about the deprecation of display list and the need for a better replacement. My question was more a rhetorical one.
Does anyone remember that I proposed CBOs (Command Buffer Objects)? I’m not using D3D11, but from Daniel’s brief comparison, it looks like very similar thing.
At that time there was no such enthusiasm abut CBO, but of course that OpenGL needs such mechanism.
I think that the introduction of resident buffers alleviated transition. We could store absolute pointers to VBOs inside DLs, and freely modified data as long as the buffers stay in the same space. If the buffer itself is changed (not the content, but the size, location, or whatever), the list should be rebuilt. On the other side, rebuilding such lists should be lightweight because they do not contain huge amount of data. They can be very compact and easy to compile and transfer (I bet driver developers will be sullen when reading this but I hope it can be accomplished easily.)
Does anyone remember that I proposed CBOs (Command Buffer Objects)? I’m not using D3D11, but from Daniel’s brief comparison, it looks like very similar thing. smile
At that time there was no such enthusiasm abut CBO, but of course that OpenGL needs such mechanism.
The principle purpose of D3D command lists is to be able to generate them on other threads, then play them back (in the same frame or slightly later) in the main thread. It is not to do what prompted your CBO proposal, which was principally based on the belief that function call overhead was a large portion of your performance problems.
D3D deals with the issue by having each context generate a single command list. A context can either be “immediate” (ie: the rendering context) or deferred (builds a command list). I don’t know how they deal with changing object state data, but because D3D uses generally immutable objects, there’s not a lot of state data that can be changed.
So no. D3D command lists and deferred contexts are not like GL display lists, and is even further dissimilar from this CBO concept of yours. Deferred contexts have no side effects; executing one command list will never affect the state used by other command lists. Each context has its own state.
Unfortunately I’m pretty sure we will get it soon but it would be a definitely good thing to have.
Alfonse, I agree that display lists are not equivalent with DX11 deferred context but agree with Aleksandar that it wouldn’t need that much of change to make them something similar. Of course, from the specification and from driver vendor point of view this wouldn’t be that simple but still, it would be great to have it (if not in the near future, at least in the long run).
It is not so complicated to determine if the CPU is a bottleneck. When GPU execution time becomes equal to CPU execution time it is pretty sure indicator that the CPU is a bottleneck. The number of function calls can reduce performance because:
Function calls communicate to the drivers (and except on Quadro cards) that communication is usually sequenced. (I’m not sure about sequencing, because I’m not the drivers implementator, but it can be concluded from various articles and comments on this forum.)
Drivers execute on the CPU. Each function, hence, must be executed on CPU also.
Having a command-list that is on the server side can reduce execution time by skipping CPU/drivers execution time. Furthermore, commands can be rearranged and optimized to take advantage of the pipeline and relax/loose dependencies. Calling just one function that executes a command-list on the server side without no doubt is much faster than calling hundreds or thousands of independent commands.
Of course, deferred context is probably more advanced concept than CBO, but as Daniel said, “it would be great to have it”!
I know that OpenGL draw calls are actually quite cheap and usually state changes are more expensive from this point of view, but if you could merge several states together, what is currently true as we have texture arrays, subroutines and so on, high number of objects draw calls can be a bottleneck at some point.
Besides that if CBOs or display lists, whatever we call them, would be able to cache state changes also in a better form that is more suitable for the driver it would be even better.
It is still true that compiling bunch of state changes in display lists is faster than issuing them separately. As long as it is true, which I think will always be the case, there will be always a benefit from having some precompiled config objects in our toolset.
