PDA

View Full Version : 4.1 == 11?



glfreak
11-29-2010, 11:45 AM
Does the current GL 4.1 core beat Direct3D 11 capabilities?

I'm asking this because I noticed some recent video cards support D3D 11 and OpenGL 3.2 while its vendor already have GL 4.1 drivers for more advanced cards. So I figured out it's GL 4.1 that requires more capable hardware than what D3D 11.

Thanks.

Groovounet
11-29-2010, 11:49 AM
lol
It is just because at the time of the release, the drivers were not ready. So many website report some dumb information on that regard.

OpenGL 4.1 is still a subset of Direct3D 11 despite what few nVidia guys would say.

glfreak
11-29-2010, 11:54 AM
I'm not sure what features D3D 11 has that GL 4.1 does not have...

http://arstechnica.com/software/news/201...direct3d-11.ars (http://arstechnica.com/software/news/2010/07/khronos-group-releases-opengl-41-claims-to-leapfrog-direct3d-11.ars)

Groovounet
11-29-2010, 11:58 AM
At least:
- Descent multithreading capabilities
- Buffer & image load & store with atomic operations

aqnuep
11-29-2010, 12:43 PM
There are already some OpenGL 4.1 features that D3D 11 does not support but I also agree with Groovounet that D3D 11 has still some capabilities not available in OpenGL 4.1 but that will change next year.

When the currently developed extensions will be included in OpenGL 4.2 I think we can say that OpenGL is a superset of D3D (even though such multithreading capabilities won't be included in OpenGL, however that is more an API feature than a feature of the underlying hardware architecture).

Still, how I understand your question, you are much more interested whether they target the same hardware generation. From this point of view, you can take OpenGL 4.1 as equivalent with D3D 11.

glfreak
11-29-2010, 12:53 PM
So this means a D3D 11 hardware is capable of GL 4.1 core features regardless of the driver support?

Talking about multi-threading support, cannot GL context be threaded anyway? I thought it's something already exists in GL for long.

Another thing I would love to see is support for pixel/fragment read from the frame-buffer inside the shader. Probably this is a hardware limitation?

aqnuep
11-29-2010, 01:04 PM
No, D3D 11 hardware is capable of GL 4.1 if the driver also supports GL 4.1. Currently, AFAIK both NVIDIA and ATI has GL 4.0 support in their drivers and have some GL 4.1 support at least in their beta drivers.

Multi-threading support in GL is now working in a way that you can have a separate GL context for every single thread and yes, it exists in GL for long time. D3D just added such support with their latest releases and it is now a bit more superior compared to GL now.

There is possibility to read from the current framebuffer inside a shader if you attach the framebuffer texture for reading. Of course, hardware has some limitation over this. For more details check these extensions:

http://www.opengl.org/registry/specs/NV/texture_barrier.txt
http://www.opengl.org/registry/specs/EXT/shader_image_load_store.txt

These extensions are both supported by NVIDIA and ATI drivers and they overcome some of these limitations.

Alfonse Reinheart
11-29-2010, 01:08 PM
So this means a D3D 11 hardware is capable of GL 4.1 core features regardless of the driver support?

What do you mean by that? OpenGL 4.1 specifies features that are in D3D 11, so any D3D 11 hardware would be capable of doing GL 4.1. But without driver support "capable" doesn't mean anything.


Talking about multi-threading support, cannot GL context be threaded anyway? I thought it's something already exists in GL for long.

That's not the kind of multithreading they're talking about.

In D3D 11, you can create "deferred" contexts. Rendering commands issued on deferred contexts are not executed immediately, but instead wait until the non-deferred context is explicitly told to execute the deferred commands. This allows multiple threads in the user application to be used for rendering purposes.

You can't imitate this in OpenGL (yet). Even with display lists, since display lists use state from the current context while rendering, whereas each D3D deferred context has its own state.

It shouldn't be too difficult to add, though. There just needs to be a parameter added to glX/wglCreateContextAttribsARB that will create a deferred context (you will need to pass a specific share context so the contexts share objects). Then there needs to be a glX/wgl function that is told to render a deferred context.

The difficult part revolves around issues of multithreading into GL contexts. What happens if objects created in one context are modified deleted in another. D3D doesn't really have that problem, since their objects are, for the most part, immutable.

glfreak
11-29-2010, 01:23 PM
OpenGL display lists are pretty much deferred context in D3D 11 that worked for antiquated versions. Unfortunately they are deprecated instead of being improved to fit in the new core specification.

I could simply emulate the D3D deferred context partially by having every GL context its own display list and execute them in different threads.

Alfonse Reinheart
11-29-2010, 02:23 PM
OpenGL display lists are pretty much deferred context in D3D 11 that worked for antiquated versions.

No, they aren't. D3D deferred contexts have different state from one another. The functioning of a deferred context cannot be affected (outside of changing the objects in use) by the functioning of another deferred context. You cannot make a deferred context render to a different framebuffer or whatever from outside that context.

You very much can with a display list. A display list contains only the commands it was compiled with. It does not contain the list of state that those commands were compiled with at the time of compilation. Because of that, the results of executing a display list can depend on state that was set after the display list was compiled.

And yet at the same time, display lists cannot be affected by changes to objects that they use. Binds are not compiled; they are executed immediately. So all object contents must be read by the display list. The contents of buffer objects and textures have to be stored in the list separately from the original objects used in building the DL.

That means you cannot change the contents of a buffer object and expect the DL to use the new contents. You cannot have one DL do a transform feedback into a buffer, then have another DL read from that buffer for some operation.

Display lists are like deferred contexts in only the most superficial way. The differences are quite substantial.


I could simply emulate the D3D deferred context partially by having every GL context its own display list and execute them in different threads.

Partial emulation means nothing. The differences remain. Plus, it would be incredibly slow, since compiling a DLs is not exactly a fast operation.

glfreak
11-29-2010, 04:24 PM
Then i would suggest for future releases something like

Deferred Display Lists

In addition to direct read operations of frame-buffer from within a fragment shader.

Dark Photon
11-29-2010, 05:45 PM
When the currently developed extensions will be included in OpenGL 4.2 I think we can say that OpenGL is a superset of D3D
We should include OpenCL in that, as they did last year at SIGGRAPH. That is, what was alleged was that OpenGL 4.1+OpenCL was a superset of DX11.

Alfonse Reinheart
11-29-2010, 08:00 PM
Deferred Display Lists

No. We already have multiple context support in OpenGL. And you have to make multiple contexts in order to issue commands in different threads anyway.

All you need is a way to create a deferred context and a way to have the main context render execute what was rendered in the deferred one. It's really that simple.

Re-establishing something like display lists would be entirely unnecessary. Just let them go; they weren't a good idea and its best to leave them gone.

Groovounet
11-29-2010, 11:13 PM
No. We already have multiple context support in OpenGL.

No we already have black magic support in OpenGL

Alfonse Reinheart
11-30-2010, 12:06 AM
No we already have black magic support in OpenGL

... Care to explain that?

Multiple contexts is not black magic. You just use the context creation again. The new context creation function even takes a context to share objects with. This is a first-class feature of the API.

Display lists are not as well understood as multiple rendering contexts.

Groovounet
11-30-2010, 01:49 AM
:p

I disagree multiple context is black magic to me. Using it is about ok, using it efficiently... challenging!

Can you provide a guide line? I mean a guide line that nobody will would complain about. Definitely challenging!

EDIT: D3D9 has black magic multithreading support as well if you wish.

Alfonse Reinheart
11-30-2010, 02:28 AM
Using it is about ok, using it efficiently... challenging!

Using it efficiently to do what?

We are talking about co-opting multiple contexts for a different purpose. This would not involve things like multithreaded texture upload and the like. This is all about building self-contained state (as opposed to state that can be altered by other state like display lists) and rendering commands and executing them later.

There's no question of locks, multithreading, and other things like there are with issues of multithreaded uploads and such.


Can you provide a guide line? I mean a guide line that nobody will would complain about. Definitely challenging!

What do you need guidance about? You do it like you do in D3D 11. A D3D deferred context is almost exactly like an OpenGL rendering context. The only differences are the ones I'm proposing be removed by the context creation flags (namely, the delayed execution).

The only things that could possibly get in the way are issues relating to mutable state objects.

Groovounet
11-30-2010, 02:35 AM
We are talking about co-opting multiple contexts for a different purpose.

We You are talking about co-opting multiple contexts for a different purpose.

Alfonse Reinheart
11-30-2010, 03:05 AM
We are talking about co-opting multiple contexts for a different purpose.

We You are talking about co-opting multiple contexts for a different purpose.

Yes. Because OpenGL rendering contexts are almost identical to D3D 11 deferred contexts. Unlike display lists, which are almost exactly the opposite.

If you're looking to port D3D 11 functionality, you should look for the most similar GL construct and modify that, rather than looking for the least similar construct that happens to sound something like the original.

The correct way to port this functionality is to use rendering contexts, not display lists.

Groovounet
11-30-2010, 04:14 AM
Sorry, I just could not resist. :p

kRogue
11-30-2010, 12:03 PM
Oh well I will add to the, somethings. Right now, as far as I know, to get GL+CL to have all the goodies as the D3D11+DirectCompute, one needs:
GL_EXT_shader_image_load_store GL_NV_shader_buffer_load GL_NV_shader_buffer_store Something new and funky to build commands in other threads outside to be executed

The NV extensions are needed because, if I remember correctly, D3D11 also has a link list traversal thing in there too.

aqnuep
11-30-2010, 12:09 PM
You can do linked list traversal with GL_EXT_shader_image_load_store and you can use buffers with that extension as well if you use buffer textures.
The only major thing that the NV extensions provide is pointers to GPU memory but that is a not so portable feature so you should not expect anything like that get into GL (at least that what would be logical).

kRogue
11-30-2010, 01:53 PM
You can do linked list traversal with GL_EXT_shader_image_load_store and you can use buffers with that extension as well if you use buffer textures.

Very true in spirit, but the pain of setting it up is notable, since.. likely what would happen is that one would use a texture buffer object (R16UI or such) to make a list of indices to walk, or needing to create a linked list, one would have an image of format RG16UI or similar for the list of indices "addresses", the .r for which value to use from a texture buffer object and the .g for the next element in a linked list...

but shudders, setting that up well... write a linked list in a shader would be quite painful too... where as NV_shader_buffer_load/store make it so much easier :cool:

aqnuep
12-01-2010, 01:26 AM
It is just an API thing. I'm pretty sure that D3D 11 does the same thing under-the-hood just it abstracts it with API.
Why I think that this is maybe not the best idea is that this way you hide the actual memory access pattern from the user.

I agree that it is much easier to have struct fetches built-in but personally I would rather go with atomic texel fetches as this way at least I know how the various fetching instructions perform on the various cards (e.g. R32F or RGBA32F, etc.).

So, to sum it up, I'm happy with the current solution but not against struct fetches if they will come somewhen.