I can’t disagree more. The more the project get bigger, the more the ‘cases’ count increase and the state combination become hard to track. With DSA you don’t have to track the entire object edit parts.
Absolutely correct. The larger the project the higher the chance of non-deterministic interactions between its various components in a bind-to-edit API. This is especially true when integrating 3rd party components (a necessity in large projects), which enforce their own standards in state handling. You soon come to a point where you have to sacrifice performance to either save/restore state (glGet*) or aggressively reset state after every operation.
DSA resolves this issue cleanly and thoroughly. This is not an academic consideration, this is something that affects the daily work of many (if not most) OpenGL developers.
Um, this DSA + MultThreading point is bogus. A given GL context can only be current in one thread at a time. If you have multiple threads and you wish to change the state of any GL objects, then you create additional GL contexts in the same share group, as such the GL state issues that DSA deals with are NOT an issue as each thread has it’s own context and each context has it’s own latch/bind-state, what DSA does nicely for you is that can make layered stuff more easily.
I guess it’s not ‘bogus’ in the context of multithreaded OpenGL drivers. For example, if a thread want to update a texture parameter, it doesn’t have to check is the current binded texture OpenGL is use by another thread. It’s less thread sync.
One thread could manage the draw calls and severals, the various objects updated for various heavy tasks like on the fly DXTC compression.
Groovounet, the point is, you cannot do that glTexParameter call in a second thread, unless you create an extra context for that thread. OpenGL allows only one thread to talk to a context at any time.
kRogue is right, DSA doesn’t help to make OpenGL more ‘threadsafe’. It helps were several pieces of code that don’t necessarily know each other, need to work together without polluting each other’s assumed state.
DSA itself won’t make OpenGL threadable, but it is very much essential as the foundation.
Take a look at the D3D11 spec. For multithreaded use you create EXTRA contexts per thread there, but those are no real contexts, they are only for command-queuing. Their command queues are then executed on the main context.
This is a very clever idea and i’d like to see the same thing in OpenGL. However, without DSA it would be difficult to put meaningful commands in those queues, because you simply don’t know the state that OpenGL is in, when the queue is executed, so you would need to set each and every state to proper values, that might affect your operations.
In non-multithreaded use you usually have a good idea about the current states, or you have your own abstraction that caches those states, so you can avoid redundant calls, so DSA is not THAT important here, it is simply more convenient.
I implied that each thread has an OpenGL context as… it’s how it works with OpenGL.
However my guess doesn’t even require multithread software, I was speaking about multithread drivers, meaning, drivers that use multiple threads even if the software is single-threaded and for that purpose DSA should help.
And for multithreaded software, I agree with both of you.
This is as if we were writing the OpenGL drivers and where we need to add mutex and how probable the mutex is already locked. With bind and edit, it’s high probable because the mutex are on binding point. With DSA the mutex are on object so as far as multiple thread doesn’t work on the same object… it should be ok.
I would hope in such cases that they aren’t using locked mutexes of any kind. Well, I would hope that nothing in the OpenGL spec forces them to have to use them except for the most important synchronization points.
Lockless multithreading is a skill that any multithreaded programmer should learn.
As a programmer I want DSA because off the advantages in functionality more (the grounds work in multithreading it asks) than the API-convenience.
I want first a good foundation that allows the upsides of DSA to shine. I don’t care when! Even it’s not in the following version (4.1?) of OpenGL. That’s okay. I want to to ENABLE what it is ABLE TO do. Being able to multithread without locks, true multi-threading (performance-enhancement) is much more worth than the typing convenience.
Please don’t rush it.
We really need those foundations to be solid, future-proof.
If that is done, make it so that it always has the shader code in there in it’s current form.
Because for fallback-solution.
And when all combinations are a little too big to be done binary. And it has probably other advantages and solves problems that aren’t mentioned here.
This makes it very robust and problem-free compared to a only-binary shader approach.
And what do these so-called multithreaded drivers do exactly?
Are they working in the background trying to emulate a feature that is not directly supported by the GPU?
I hope not because I thought GL 3.0 was about moving closer to the hardware and making the drivers simpler and thus perform better.
glTexParameter? That should be dead. What happened to sampler objects?
glTexParameter* is still useful for a couple of things: texture swizzle, lod base / bias, base and max level.
Multithreaded drivers are just taking advantage of multicore CPU like any software. Even when we will have a proper multithreading API, the drivers would remain multithreaded.
Ok, so there is now glIsSampler, glGetSamplerParameter, glGenSamplers, glBindSampler, glDeleteSamplers,
AND THE VERY important glSamplerParameter.
GL_TEXTURE_LOD_BIAS, GL_TEXTURE_MIN_LOD and GL_TEXTURE_MAX_LOD are part of the sampler.
The swizzle stuff is not part of sampler for some reason but if you ask me, it should be.
To me it seems, swizzling belongs to texture image, because it is meant to make the shader agnostic of the actual layout of the texture (image data).
So, for instance, you can present the shader a GL_RED encoded grey-texture as RGB. Without swizzling, you’d have to specifically write a shader that ‘knows’ that it needs to duplicate the R channel into G and B when it accesses that specific grey texture.
Turning semantics around: putting swizzling in the shader (i.e. sampler) would always swizzle in a shader-specific way, independent of the real layout of the bound texture. This is not needed, you can do that already:
I was actually really surprise that the swizzle stuff remains a glTexParameter (and post something about that).
skynet, I must I find your view on the shader independence very convincing. One thing remain, what if we want to present a single texture with two different ways? (bound twice)
Chances are that the texture cache will do its job if we fetch as the same coordinates so the 2 sampling would be that more expensive. Also, why not different texcoords for both textures?
Humm for multi resolution noise…? (I’m not saying I really believe in this scenario!)
Here is something I don’t want to see going wrong.
Recently on Geeks3d there was an article about some new Nvidia extensions. They exposed memory usage and size.
Now an arb version might in the future be comming in OpenGL.
And, I can’t say this enough, use the correct PREFIX with the correct numbers.
What I mean is:
kB = 1000 B NOT 1024B
For the powers of two we have KiB, MiB and others with an ‘i’ in the middle. Please use the correct ones on the official extensions. Make it possible to choose the powers of two or the decimal way. But return the RIGHT COMBINATION.
Everybody is already beginning to switch: Apple with Snow Leopard, Ubuntu is talking about doing it in the 10.10 release.
Only Windows is kinda slow, nothing surprising.
Thing is, the right combinations could save a lot of headaches.
Especially the prefixes with the i’s in them.
This is crap, propagated by hard drive and other digital storage manufacturers.
kilobyte = kb, KB, kB was and is 1024 bytes (2^10).
megabyte = mb, MB was and is (2^20) bytes.
gigabyte = gb, GB was and is (2^30) bytes.
These conventions started because computers are based on binary transitors and thus powers of two. They were hijacked and mutilated (into 10^3, 10^6, 10^9, etc.) for hard disk storage capacities by hard drive manufacturers who found they could be used to imply that their disk drives contained more space than they actually did (the bigger the disk, the bigger the lie; the lie being absolutely huge nowadays). And a byte would be 10 bits (10^1) in their world if that helped their scheme (which it didn’t, so they didn’t)… I still remember the controversy on this back when PC hard disks were around 340MB.
There are true megabytes (2^20), and there are fake “hard disk” megabytes used by lying cheats (10^6). Question how a byte is defined with such characters…