New GL spec means: new begging.

OpenGL
21

Well, who can argue with a polite request like that.

That comment made me laugh, it made my day :smiley:

At any rate, considering the new layout thingy added to GLSL, does not seem like a stretch to add it for vertex shader outputs, etc. I suppose that might be even the plan.

Though… it does make me nervous some, some GPU’s are vector centric, some are scalar centric and some are just funky. Additionally, for some implementations of GL, having 2 vec2 interpolators is same cost as one vec4 interpolator, where as for others it is not…

Still I’d love to have separate shader object’s mixed with a little DSA syntax to state which shader you are setting the uniform of.

22

Or like someone mentioned long ago: the driver could simply store a 50MB hashtable of glsl program srccode and its binary; no extra specs necessary. Internal binary format for the given driver, update of driver invalidates that cache.

This I guess is okay-ish for beefy desktops, but for smaller things is not really feasible… there are small embedded devices that do GL2.x and GL3.x (not just GLES1 and GLES2).

23

Indeed, the driver-side cache seem very fragile.
A given application will have a hard time to tune the cache size, as if it is too small, that defeats the purpose.

That could be a plus provided transparently by some drivers, but it would be impossible to rely on it.

24

Completing my request for a generalized “explicit location” / sementic oriented design and separate shader progrom based on that, it would be great to have a glTransformFeedbackVaryings function that take locations instead of (stupid) names. glTransformFeedbackVaryingsNV in fact… I never really understand from where drop this glTransformFeedbackVaryings with names but I would be pleased not to put it right my own and personal deprecated functions list.

By the way I would like to say that I love the work done on transform feedback for OpenGL 4.0. I quite think that a lot of it could find a place in OpenGL 3.4 but I might be wrong.

25

[censored], there is a user wish list now? That’s great!

For binary shaders? Why isn’t this made available until now? Last time I heard there was discussion at khronos meeting about it.

26

i think there should be the possibility to set defines/macros during the compile of a shader.

maybe extend the glCompileShader function to take another string as second parameter in the usual compiler parameter form.

for example:

glCompileShader(_gl_shader_obj, “-D_MY_MACRO=3 -D_MY_SECOND_MACRO=2”);

currently this can only be achieved my parsing the shader source for the #version statement and pasting the custom definitions into the source string. maybe this could help custum shader instantiation aside the subroutines.

27

Move up this good thread with my little OpenGL wish-list:
OpenGL 3.4 / 4.1: Expectations / Wish-list (DSA!)
OpenGL 3.4 / 4.1: Expectations / Wish-list (major)
OpenGL 3.4 / 4.1: Expectations / Wish-list (others)
OpenGL 3.4 / 4.1: Expectations / Wish-list (summary)

28

OpenGL 3.4 / 4.1: Expectations / Wish-list (DSA!)

Oh Jesus Christ. “Direct State Access (DSA) is the most wanted feature for OpenGL 3.4 and OpenGL 4.1 by most serious OpenGL developers.” I call total BS on this statement. And considering that it’s the very first sentence, that does not bode well for the rest.

The presence or absence of DSA doesn’t prevent you from getting your work done. The only thing it might prevent is a reasonable multithreaded implementation. Important, yes. But far from overwhelming. The simple fact is this: except for the multithreading issue (which I admit isn’t something one should easily gloss over, but it does require additional API support), what are you going to do with DSA that you could not do without it?

Nothing. It is pure convenience.

When there are real problems and needs with regard to the API, convenience is a luxury.

Currently, at linking the compiler need to link the output variables of the vertex shader to the input variables of the fragment shader using the variable string name. With explicit varying location, this task would disapear: output vertex shader variable with location 0 would automatically communicate with input fragment shader variable with location 0 automatically.

So you get to name things by different names in different stages. Again: pure convenience; the types still have to match. Personally, I prefer names. They have an actual meaning, unlike a number which doesn’t.

And having the same variable defined with different names in different places is pretty much the definition of “confused logic”.

VAO alternative idea with explicit binding points and layout sharing:

That’s a pretty terrible idea. The offsets are baked into the format, and you can only bind the buffer object’s base. Because the bindless “handles” are simply GLuint64’s, you can “bind” any arbitrary number. This allows you to put multiple meshes with the same format in the same buffer, and simply “binding” a different set of addresses for each attribute in each mesh. To make this work, you need to be able to use something like glBindBufferRange.

More important than that, by NVIDIA’s admission, the reason bindless gets its performance advantage is from cache issues. Cache issues specifically related to having to read data from buffer objects. Making the user bind buffer objects more frequently is not the way to solve this problem. The performance benefits come from locking the buffer, not from rearranging commands.

29

**** ! Whouhouuu ! ****

I love physics, strong action, strong reaction!
Next time I will say REQUIRED by ALL and observe how you react.
If you look at the OpenGL thread announcement, DSA is at a lot of places. That night I talk to a friend about that announcement and he reacts first with a “damn it again no DSA!” and then he cares about the details. How rational is this wish? But people don’t make wish by reasons otherwise it would be no war. Anyway, number 1 item in my wish list!

For the second part, I didn’t say that is was the solution, it was just an introduction for the problems solve bindless graphics. I saw that statement for cache pollution in the spec. Moreover, I don’t think that just bindbuffer pollute the L2 cache all this calls must be evolve. I probably haven’t been accurate enough here, thanks!

PS: For a change, I would enjoy to see you posting your wish list just to change role and be for once the guy that suggest instead of just being always the critic one. Don’t give me wrong, I have nothing again critics at all, he would just be nice to see you perform on other side. :stuck_out_tongue:

30

Agreed! Way too much vitreol.

To support and refine your “critic” reference, there’s nothing wrong with constructive criticism and suggestion at all (helps folks grow, encouraging, gives them something to think about)! But too much of what I’m seeing from him is just flat bitter-old-man destructive criticism (ranting, demotivating, egotistical [my-way-is-the-only-way], and sometimes even totally false).

31

i am totally with you on that. one thing i wonder whould fit into the DSA scope: initialize/update textures from PBOs.

there are only the glTextureImageXD functions. what would be really helpful would be something like:

glTextureSubImage_data_from_unpack_buffer_offset(uint texture, uint unpack_buffer, enum target, int level, int xoffset, int yoffset, sizei width, sizei height, enum format, enum type, intptr offset);

i am not good at function names, but i hope you get the idea. because with the current DSA extension we would have to actually bind the unpack buffer and to the texture update.

32

For a change, I would enjoy to see you posting your wish list just to change role and be for once the guy that suggest instead of just being always the critic one.

I have. Look at the announcement thread.

1: Separate shader.

2: Whatever lowers vertex submission overhead.

3: Multithreading.

There’s simply not much more that OpenGL actually needs at this point. Even the vertex submission thing is just a “would like to have,” since OpenGL is already quite good and better than D3D at this.

But too much of what I’m seeing from him is just flat bitter-old-man destructive criticism

The ARB has limited time and resources. That means prioritization is important. That means that they should work on features that will actually make OpenGL programs more capable before working on niceties and API cleanup.

DSA doesn’t make OpenGL more capable. DSA only matters as a potential component of full-on multithreading support. There is nothing you can do with DSA that you can’t currently do without it, so I see no need for it. And I consider it constructive to say that, as it pushes things in a good direction, rather than a useless one.

I like DSA. But I’m not going to let people act like it is anything more than syntactic sugar. I like sugar, but it shouldn’t get in the way of the actual meat.

33

From what you say, if DSA help multithreading (how?), so DSA is the meat.

On that side the separate shader is actually really similar to DSA. There is nothing we can’t do without separate shader. Duplicate shader and you go.

Anyway, I didn’t even said that DSA or separate shaders are the most important feature to have, I said, they are 1 and 2 in my wish-list.

Following your ‘meat’ idea, the main thing left is RWTexture and RWBuffer and at least RWTexture is really on its way to OpenGL 4.1 and hopefully RWBuffer too. Which I put in the category “expectations”.

34

From what you say, if DSA help multithreading (how?), so DSA is the meat.

No, multithreading is meat. DSA is merely a means to that end.

And the reason DSA is needed is because of state issues. If you confine your state to one thread, it is easy to be responsible for the current state of everything. However, if you have multiple threads that can change the current state, this is a real problem.

Being able to have a worker thread that can do operations on an object without having to bind that object to the context (and thus mess up context state) is important to making multithreading work.

On that side the separate shader is actually really similar to DSA. There is nothing we can’t do without separate shader. Duplicate shader and you go.

Duplicating the shader takes up precious compile time. The more fully linked programs, the longer it takes to load. This is non-trivial for serious application.

Following your ‘meat’ idea, the main thing left is RWTexture and RWBuffer and at least RWTexture is really on its way to OpenGL 4.1 and hopefully RWBuffer too. Which I put in the category “expectations”.

Which is part of the argument that your priorities are wrong. These provide actual, tangible functionality to rendering. So they should be higher priority than other things.

35

great work on that wishlist there Groovounet, I second your last 3.4/4.1 list.

Personally I would prefer the separate shader (explicit attribs) stuff first, as I miss that most from working with Cg, which also means transform feedback is more generic to setup (doesn’t need to know about the shaders to come) and parameters don’t need to be updated for every linked pair combo.

And then DSA… it just makes it more natural to write modern renderers this way, multi-threading… and great that you took the attention to detail and point out issues within DSA.

hopefully DSA for core stuff will pave the way for the overhauled display/command list thing. Having the includes for GLSL would add a lot of convenience, yes one could write their own yadda yadda, it’s just nicer this way.

Which is part of the argument that your priorities are wrong. These provide actual, tangible functionality to rendering. So they should be higher priority than other things.

your reasoning here is that exposing new things should have highest priority, however one can also reason that DSA would improve the situation independent of a hardware feature for all general opengl development on “current main stream” hardware (ogl 3.x). And I would think that has some serious importance as well. If you want to play with the “latest” you will have the EXT and vendor stuff to get going and ARB stuff will follow and not be fundamentally different. But DSA simply exposes a new form of quality to OpenGL in total, the earlier that comes, the better for all of us.

36

one can also reason that DSA would improve the situation independent of a hardware feature for all general opengl development on “current main stream” hardware (ogl 3.x).

No, it wouldn’t. It might make them slightly more intuitive to use, but it would not make them better hardware features. It doesn’t let you do things you couldn’t before.

37

OpenGL is an API, as such its core idea is not only to provide a feature-set, but also to make it pretty. Otherwise we could really just push opcodes to the GPU (or whatever the lowest level of programming those darn things is).

In the beginning OpenGL focused strongly on providing an interface that is actually NICE. It’s simply that over time this style of programming became more in the way, than it was helping.

In recent years there have been so many new features, that changed these APIs so radically, that OpenGL simply had trouble keeping up. This seems to be mostly over now with 4.0. We really have all the important features, now the focus should shift back to making the interface more usable.

DSA has two benefits: First, it makes the API more streamlined and easier to use correct in bigger projects. Second, it should be generally better for multithreaded use. Both from a performance and a correctness standpoint.

Depending on HOW multithreaded rendering will be added, it MIGHT be beneficial to first add DSA (as core). Maybe it would be good, to explicitly disallow any glBind* (ie. selectors) calls in a thread. But i can only speculate here, the ARB will certainly find a good solution.

@Alfonse: Take a look at the first few sentences of your posts. They usually start with something like “No it’s not.”, “No, that’s wrong.”, etc. You are regularly writing posts where you “state facts”. Now, you know your stuff, that’s true, but many things are still up to debate, especially things to come. Often you ARE right, but not always. But even in those cases people consider the way you write your posts kinda rude. Nobody likes people who claim to know it all.

Jan.

38

At OpenGL code level you are right Alfonse but at software design level, DSA are just like separate shader programs, a breath!

When I was working on a 10 years old OpenGL software (I let you imagine the mess!) how many time I had been confronted to a black box that perturbs my OpenGL states (and contexts actually sometimes…) I was simply: “How the heck I am going to make this work?!” (and reaching a gun hidden in my desk just in case.)

Honestly, I did some really not pretty things, everything done in a very inefficient processing and development ways. What do you think of using the 3Dsmax SDK and stealing the OpenGL context with glGetCurrentContext to render my entire scene? What do you thing of 2 OpenGL threads using 2 different contexts working in parallel on the name rendering code path but with different quality setting all this working on 4 viewports with 4 different surfaces? Well that was the context I had to deal with. Awful stupid and weird but that the kind of stuff you find out there and there is a point where releasing is necessary.
DSA fixes the problem of tracking states and objects. It doesn’t even make this question relevant anymore. A black box? Who cares with DSA? (Well the black box better us DSA too!)

An other point you seems to miss Alfonce: Even if these image load and store give me a whahouuu effect, concretely tomorrow beside trying it out, I don’t think I am going to use them for a while. I can’t way for paper and documentation about there use but well, it’s a big deal! DSA and separate shader programs are those features that as soon as they get release, I can use them and … enjoy them! In one day or two, a complete complex software can be entirely updated. To really take advantage of them? Maybe not instantly but soon it an alternative way of thinking and to design an OpenGL software.

So YES it would!

39

First, it makes the API more streamlined and easier to use correct in bigger projects.

More streamlined, perhaps. But easier to use in large projects? Not really. DSA makes it easier in more decentralized projects, where it is difficult to enforce coding standards rigorously. But large projects are not necessarily decentralized.

Second, it should be generally better for multithreaded use. Both from a performance and a correctness standpoint.

My question is simply one of why you want it. Do you want DSA for the sake of API cleanliness and whatever? Or do you really just want multithreading, and see DSA as one of the necessary components of that?

This isn’t an academic distinction; this is important for the ARB to know. Because if you’re just asking for DSA, they may ignore the multithreading stuff or postpone it to later. Whereas if you’re asking for multithreading, then the ARB knows that they need DSA, but also some other things (possibly encapsulating the last few bits of context state in objects, etc).

40

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.

What do you call a decentralized project?

The ARB likes to do thing step my step and if DSA is necessary for multithreading, then chances are that OpenGL 4.1 will be with DSA and the rest later on. This would be especially true if they even need to encapsulate last states in objects (There are actually a lot left!) If we just have to way 6 more months… well, I won’t die.

By the way, I’m so into some kind of immutable state objects to replace display lists use for this purpose… I’m not sure a still believe it might happen