No, I don’t want that. I want a modification of glBufferData/glBufferSubData that will not copy the data right away but will return immediately and then the driver will wait for the GPU buffer to be available before DMA-copying the data from my original pointer. When this is done the driver will use the new sync objects API to signal that this data is now safe to be deleted or modified. If the app at some time wants the data to be available for deletion or modification before it’s copying is ready - it can force this by calling ClientWaitSync.
See my first two posts in this thread and John Leech’s answer for more details on pages 3 and 4.
No, I don’t want that. I want a modification of glBufferData/glBufferSubData that will not copy the data right away but will return immediately and then the driver will wait for the GPU buffer to be available before DMA-copying the data from my original pointer. When this is done the driver will use the new sync objects API to signal that this data is now safe to be deleted or modified. If the app at some time wants the data to be available for deletion or modification before it’s copying is ready - it can force this by calling ClientWaitSync.
[/QUOTE]
Are you not able to accomplish what you want to do using MapBufferRange? Pay careful attention to the extra mapping options it provides that are not available to the original MapBuffer call.
The suggested method to bind attributes to locations from within the shader is an extremely good idea.
This will make writing GL applications soo much easier AND it would bring us a big step forward in the “binary blob” issue.
A central part of my GL code is either inefficient or wastes a lot of memory for caching all those states for attribute locations, uniform locations and such. I automatically build shader combos, which generates a few hundred versions of a shader and all those need to be kept track of.
Often i simply rebind everything, just to make sure, because it would be too complex to keep track of everything.
I’d say, the current method could be kept as fallback, but allowing the shader writer to fix locations would be great. And the GL could detect, when all locations are fixed, and then allow to query for the shaders binary blob.
Also an engine could reject a shader, where someone forgot to fix some attribute’s location.
Well, thinking a bit more about it, it is a very complicated issue. For example you will definitely have a problem when you want to do this with uniforms, because an engine could provide so many different uniforms, that when their locations are fixed, some shader will always need some, that would clash.
Has anyone tried to program using new NV drivers? I have a problem with them (190.56 beta for XP32), because when try to bind VAO (e.g. glBindVertexArray(m_vaoID[0]) CPU is 100% utilized (both cores on C2D CPU), and program is stopped. It happens even if I use GL 3.0 or 3.1 rendering context. Till these drivers everything worked perfectly using GL 3.1 forward compatible context. Any clue?
Perhaps… did a quick lookup on some prices for full colour plasticized prints at a copy shop (assuming double sided prints to safe on plasticizing costs) and that made a total of 20 euro’s. Of course this can be done cheaper if mass produced… and they have to be shipped as well (not a big package, but still).
So I assume for something like 10-15 dollars/euros including shipment I would be interested.
Edit:
I agree with rsp91 (below) that a reference card with only the OpenGL 3.2 core and GLSL 1.50 core functions on it would be even more appreciated. Of course, this means less pages, but I’d still buy it for about 10 euros.
I’m not interested in the quick ref card at all until there is one without the fixed pipeline functions on it… Other than that it looks good and I’d be willing to get one in real life as well as some other nerd gear like an OpenGL baseball cap or something…
I’m not interested in the quick ref card at all until there is one without the fixed pipeline functions on it… Other than that it looks good and I’d be willing to get one in real life as well as some other nerd gear like an OpenGL baseball cap or something… [/QUOTE]
I have similar feelings, I just had the OpenGL programming guide for 3.0 and 3.1 delivered today, it’s even thicker filled with the crap from 2.x (which I already have a book for) why is anyone new to openGL going to want to purchase a 3.x spec book when if they really wanted to learn 2.x they could buy an old edition? I feel a little ripped-off. It’s bloated and difficult to navigate. I feel that, like the API itself, the Quick-Reference card and the programming guides should not include any of the old functionality, there’s no logic to it.
What’s worse is I’ve had the book on pre-order for weeks, and they dispatch it the day the 3.2 spec is released, that’s terrible =S I’ll end up having to buy the 3.2 book in no time. So please, at least remove the crap and slim it down so that it’s cheaper!
The quick reference card includes le all crap but in a different color! I actually really like having it included to see the functions I don’t want to used. I have been surprised to notice that texture priority is deprecated and without this quick card I would still no know about that!
However, beside the goodies and geeky side of having it printed I don’t see the point of such idea. I don’t like loss paper on my desk and I have third screens for such purpose: the documentation! When it comes to documentation I like “references” on the screen, copy/paste, “deep” articles in books.
So instead of the redbook I would perfect an updated OpenGL reference page to OpenGL 3.2. The quick reference is good too.
To be fair my first documentation is my own code, it gives an instance of use of a function, a concept, that’s the best!
Well, thinking a bit more about it, it is a very complicated issue. For example you will definitely have a problem when you want to do this with uniforms, because an engine could provide so many different uniforms, that when their locations are fixed, some shader will always need some, that would clash.
My take is that for uniforms you won’t be able to bind the location apriori from the shader source. The simple reason being that not all uniforms are vec4’s (I don’t think drivers collapse 2 vec2 interpoaltors to one vec4, so the locations of ins and outs is kind of easy). To get location binding correct by hand of uniforms is a really, really nasty business when alignment comes into play and not to mention inadverdent aliasing if you get sizing wrong. (UBO’s have a packing format and the rules can get icky on the details).
Also worth noting in GL_EXT_seperate_shader_objects, the scope of uniforms is per shader, i.e. if one has a uniform named myUniform decalred in a fragment and vertex shader, in GL_EXT_seperate_shader_objects they refer to different variables (and thus if they are to mean the same thing need to be both set).
I understand why most of the deprecated features in OpenGL 3.x were deprecated, but there are a few that don’t make sense to me. Could someone on the inside please explain why the following features were ripped out? The only plausible explanation seems to be that these features aren’t in DX10, so they were dropped from OGL3 just for parity. I know that nothing has actually been removed from OGL3 – I’m just looking for the reasons that came up when the ARB decided to put the following items on the deprecated list.
Alpha test. Yes, we can put kill/discard statements in our fragment shaders, but alpha test has been in hardware forever and is faster than adding shader instructions. This feature also presents a negligible burden on driver developers.
Quads. These are extremely useful for all kinds of things, and they’re supported directly by the setup hardware. Yes, I know the hardware splits quads into two triangles internally, but being able to specify the GL_QUADS primitive saves us from either (a) having to add two more vertices to the four needed for each quad, or (b) adding an unnecessary index array to the vertex data for a list of disjoint quads. This feature is also trivial for driver writers to implement.
Alpha, luminance, luminance/alpha, and intensity formats. These are very useful for specifying 1-2 channel textures! But the most important reason to keep these is that the hardware has remapping circuitry in the texture units that’s independent of the shader units, so a shader doesn’t have to be modified in order to work with an RGBA texture or a LA texture. If these formats can’t be used, then two separate shaders would be necessary: one that operates on an RGBA sample, and another that reads an R or RG sample and then swizzles/smears to get the proper result.
Solution to this is using R or RG textures with GL_EXT_texture_swizzle.
IMO, once this ext. is in core we don’t need I,IA,A textures.
Would be nice to promote this extension to core one day.
I wouldn’t pay money for such a thing in general. The idea as a PDF is really nice. The fact that it includes the GL2.1 [censored] is sooo GL 3.0…
Deprecated stuff:
I am actually happy to see 1) and 3) go away. One state less to manage, the shader clearly says what it does (discard or not) and i always hated L,I,LA,etc. textures, because they were a solution to the FFP syndrom. Also we still have more than enough texture formats left.
Quads are a thing, that i would like to see included again, they are indeed useful.
CPU is 100% utilized (both cores on C2D CPU), and program is stopped. It happens even if I use GL 3.0 or 3.1 rendering context. Till these drivers everything worked perfectly using GL 3.1 forward compatible context. Any clue?