I posted this in the wrong thread, so I’d just repeat myself and hear what others think (and hope that I am heard)
Things I’d like to see in the OpenGL API:
NV_Depth_clamp promoted to core; this is a useful and very old extension, not exactly brain surgery to add to current or even pretty old hardware.
pre-compiled shaders… now this is generally an icky bit since each hardware has different wishes on how a shader should be best compiled, but alteast something like this:
a) update and promote (i.e advertise) the assembly shader interface,
b) {hope} that IHV’s would then release shader compiler’s that create assembly code from GLSL, in truth nVidia actually already does this with their Cg compiler, cgc {cgc can be set to compile GLSL and not just Cg}. Use IHV compiler produced code and feed that into the driver… the only dumb bit of this, the assembly interface of OpenGL may or may not correspond very closely to what the internal driver compilers do; right now one can do this precompiling of shaders with NV hardware only using thier cgc compiler and their assembly shader extensions.
make fragment, geometry and vertex shaders interchangeable, i.e. ditch linking shaders to create a program, this puts requirements on the shaders to make sure their outputs align to the next stages inputs, something in GLSL to declare what interpolate/whatever to send an output to and take an input from.
this is not exactly OpenGL, but GLU needs serious help and work: matrix stuff for example; having utility for matrix operations would be good thing to have in GLU {rather than everyone using/writing their own matrix classes}. GLU has not been updated in well forever, all sorts of nice things could be made in GLU:
a) matrix ops, i.e. matrix stacks, common 3D matrix operations (i.e. acting on a matrix, the equivalent of glTranslate, etc)
b) pre-processor stuff for things like #include, etc to generate the raw string to send to GL for compiling.
c) since GL_imaging is going away, something to have GLU build mipmaps with custom filters in a similar way as GL_imaging deprecated API did.
ALOT of this stuff people end up writing themselves anyways, but seems odd that everyone has to write their own and a standarized way of doing it has a much better chance of being a good way rather than jsut a "good enough* way.
this has been stated before: kill the binding interface for manipulating objects; it is especially icky when combined with glActiveTexture(); both of these should go, just a simple new method like: glBindTextureToTextureUnit(GLenum texture_unit, Gluint texture_name) would be aces, and just make a new API family for glTexParameter functions to something like glTexParameterObjectInterface(GLuint texture_name, …) my names suck but you get the idea…
also stated before: decouple texture data from texture filtering.
promote geometry shader to core, I realize this is now ARB which means it should be core soon, but… just to state.
debug contexts: the idea is there is the new context creation routines, but right now there is nothing about them really, stuff like:
a) profiling of shaders
b) other performance profiling.
c) an API to write a real debugger {rather than the current and often unreliable hacks of trying to intercept all GL calls}
d) in light of c) some hooks, this is more wgl, glx, and whatever, for displaying textures, etc in a debug friendly way: separate channels, separate bits, etc. There are ways via context sharing to do this, but either something in GLU or GL to make this easier to do.
Some of performance profiling is available in 3rd party tools (msotly NV stuff for PC’s), and in line of profiling maybe profiling stuff does not need a debug context but something else…
I would LOVE to see the killing off of all the icky windowing system to GL glue goop of wgl, glx, etc… and a unified way to create GL contexts across different windowing systems; this is not exactly GL, but in the spirit of egl, but for desktops. What we have now is kind of painful for cross platform code (which we often just do by having another library handle the context making for us, for example SDL); doing this well and correctly is nasty icky work as something like this will depend on the windowing system, which they themselves can be quite icky to deal with… and to make that all platform independent!? I would not be surprises that this suggestion never happens baecause the needed efforts to make it happen are overly huge and they start to touch on all sorts of other icky non GL related issues.
I would really like to see a total rehash of the texturing system.
the texture objects that where originally slated for 3.0 is a good place to start, but i would like to see more generalized buffers used for the data instead of those image objects (or whatever they where called).
Really the only meta data needed would be texture size, whether it uses mipmapping and maybe format but that should be handled trough uniforms or something like that, everything else is done through shaders.
then the binding would be something like
I think love of DSA is pretty much unanimous, but it seems to me the question of how you adopt a pretty hefty chunk of API into the core without doing away with bind-to-edit has to be answered. I just don’t see DSA existing side-by-side with BTE in any form (but then maybe that’s just a lack of imagination on my part). Perhaps this is the stuff of the next major revision, at a point when BTE can be retired without a great disturbance in the force.
I don’t see a conflict between DSA and bind-to-edit. They are merely two different pathways to effect changes to an object or part of the context state. If NVIDIA has it implemented and running in their drivers, seems like it must be possible
Yes indeed. But what I actually meant was that it seems less than ideal to have both methods under the same hood (to these tired eyes anyway). Lack of vision on my part, or maybe just one too many bowls of split-pea soup
I am pretty sure we won’t see bind-to-edit go away anytime soon, simply because there are certain actions, which need some kind of binding. E.g. shaders / textures / and other resources. Therefore we will most certainly always have operations that only work on the currently bound object, and might not make sense without such context.
For the near future a clean DSA extension, that only handles non-deprecated functions would be great for GL3. For GL2 one might even keep / extend the current DSA, which includes all the legacy stuff, i wouldn’t mind that (and wouldn’t use it either).
In the future some operations on bound objects should be deprecated, but only after a proper DSA has been implemented and proven to be good.
I was / am one of the guys shouting loud, that GL3 should be a clean slate. But honestly, being able to gradually clean up my mess and switch to GL3 slowly does have its advantages. Still i hope that some day GL3 will be cleaner and more consistent (immutable objects, better state-management…) than today and that there will be drivers benefiting from it. Though that will certainly take a few years.
Yes nVidia has it implemented in it’s drivers but I keep struggling using it! There are many bugs, most of the time, I need to bind a the object before using a DSA command … Oo So I rather bind and edit to fix the bug but then I have to add some checking code and I can’t evaluate properly DSA …
I really hope this extension will evolved soon and nVidia implementation too, it’s been a while and it’s still not good enough.
I completely agree on for the texturing system. However, “buffer” I’m not sure because buffers and images doesn’t share one main feature. Buffers are a 1D data structure, images are a 2D data structure which allows GPU to have this really specific and dedicated 2D memory cache.
Then you can think of texture 1D and texture 3D and then well maybe some kind of buffer1d, buffer2d, buffer3d would be nice … Very complicated topic, I guest something consistent with OpenCL would be already amazing! (buffer / image)
One ickiness of GL_EXT_direct_state_access is that it is so much written to the tune of GL 2.1, and now in forward compatible contexts of 3.x, much of what is in GL_EXT_direct_state_access is not appropriate, if we look at how the binding interface is used there are two cases: editing parameters of the object or “using” the object; the need to bind to edit really needs to go out the window, there is no good need for it, somebody correct me if I am wrong on that one; By the way, the entire shader API, the GLSL program does not need to be bound to get into it, the object name is passed on all calls, the only exception being “make the program active bit”… I would like to see the following:
for buffer objects, for each call that is affected by what, if any buffer object that is bound, a new API entry point that takes as parameter the name of the buffer object, and those calls that require a buffer object to be bound to go away (i.e glVertexAttribute taking a void* pointer that is now used as an offset in GL 3.x). Ditto for the whole pixel buffer object stuff of read/write pixels; This wish is the wish to kill “the bind to use stuff”.
the texture API needs to reworked anyways to decouple that data from the filter; my fervent hope is that a new API is made for the texturing stuff, getting two kinds of objects: texture data objects and filter objects. When doing texturing, then a texture data and filter objects are tied to a texture unit. For texture data objects one can then get into sub textures and all sorts of stuff akin to sub-arraying which could be useful; The only bits a texture data object would have would be dimensions, raw bytes, and internal format. The filter objects then specify the texture looking up biz: filtering, mirroring, etc; basically most of the stuff done in glTexParameter functions.
the following might be nice, but again I am not so sure: glDraw* API’s: make a new API family that takes as parameter the name of a GLSL program, so the command is “draw with this program”, in light of the wish to decouple fragment, vertex and geoemtry shaders, which is actually saying “no GLSL programs” really, the the glDraw command family would take 2 or 3 named parameters: vertex, fragment and geoemtry shaders; the usefulness of this wish I admit is questionable, but it helps localize code and that is what people want for DSA anyways.
I agree with you on 1) and 2). To 2) i’d like to add what D3D afaik allows: specify a filter-object in the application, but be able to overwrite this in the shader. This would be very useful, if the application could say “filter textures anisotropically”, but a shader could say “no, i need this nearest filtered”. Same for clamping etc.
On 3) I don’t think that would be very useful. I have a lot of code that “just renders geometry” and doesn’t care about shaders. If i would need to specify shaders each time, i would need to pass this information everywhere through. I don’t see a benefit in this. Having both options would just make the number of drawcall functions unnecessary high. Also this is definitely not in the spirit of GL, because those functions would be useless, if another shader type were to be introduced, because the number of parameters it takes would be fixed.
PLUS: If there will be new drawcalls, i first want to see the “index offset” to be added (which the ARB ignores for years now).
Agreed. Whatever form DSA takes I think it’s generally agreed that b2e is a pain in the tuckus.
But the real question in my view is whether b2e can actually be removed to the satisfaction of the voting majority given the practical reality of the current deprecation model and the widespread dependency on maintaining backward compatibility. Such a removal would seem to imply a rather large modification to the current structure of the API at its roots, which ultimately proved unattainable for the similarly grand ambitions of the original GL3 design. Therein lies my doubt and motivation for my earlier comment.
my personal hope is that to kill off bind to edit, a new API family will be made, then the bind to edit is marked as deprecated and that is it. In order to decouple texture data from filtering a new texture API is needed anyways, if I had absolute power I would do this:
mark bind to edit stuff as deprecated and create new API points which just take as argument the name of the object to be edited.
for texture stuff, make a texture data and filtering object types, maintain the old API as deprecated and create a new API to bind a texture/filter pair to a texture unit.
I actually don’t see the real hassle for the users of GL in doing the above (the killing off of fixed function pipeline was much more dramatic) but the ones that will suffer the most are the implementers: for the next version of GL they will need to have both direct state access and bind to edit. The move away from bind to edit for most GL users would probably quite small, I bet most folks have their own “openGL object” wrappers that do the binding for them and ditto for setting vertex attributes, i.e. I bet most have this:
class myicky_globject_wrapper
{
private:
GLuint m_name;
public:
void
some_editing_function(arguments)
{
glBindCall(obejct-specifi binding point if necessary, m_name)
glSomeEditingFunction(arguments);
//matter of taste:
glBindCall(obejct-specifi binding point if necessary, 0);
}
};
the more anal will query the currently bound object at the bind point and restore it… but you get the idea, show of hands how many have their own layer for manipulating GL objects anyways and the big change for killing off bind to edit will be “to not bother binding” and changing the appropriate API calls.
The point of the separation between image and filter from a texture is to not bind any more and image to a texture unit switch is quite a none sense.
A texture unit is composed of “two parts” one for addressing and one for filtering. I quite expected the filtering part to become programmable and the addressing to remain as a specific instruction.
Anyway, the texture separation allows to use as many images as wanted with no image number limitation.
The point of the separation between image and filter from a texture is to not bind any more and image to a texture unit switch is quite a none sense.
I am having trouble parsing this… are you saying that by splitting the texture data and filter one does not need to bind the texture data? perhaps you are thinking this kind of API:
i.e. set the texture and filter directly rather than setting what texture unit to use and then biding the correct thingy to that unit… the above does look nicer, but I am not so sure that current day hardware is actually that flexible…
I don’t see why buffers can’t be 2D or 3D or why there should be any difference between them, that should all be up to the meta data or maybe cache hints.
The point here is that if you only use buffers for data you should be able to treat them the same way, maybe you might want to render directly to a height map that also works as a VBO or whatever, and sure most of it could be done today, i just don’t want the api to stand in our way
Essentially the way i envision it is that openGL ends up having a bunch of “slots”, you have data slots, shader slots and output slots.
at load time you load the buffers and then “bind” them to each slot, the same with the shaders.
(note that binding in this case is in the same way as you would bind uniforms, like texture samplers)
then you start rendering by calling lets say an object shader (basically it is a shader version of glDrawElements and the like)
glRender(GL_OBJECT_SHADER, objectShader1);
each shader would then execute in order using a standardized set of input/ouput vars (no more custom varying variables)
I don’t see why buffers can’t be 2D or 3D or why there should be any difference between them, that should all be up to the meta data or maybe cache hints.
The point here is that if you only use buffers for data you should be able to treat them the same way, maybe you might want to render directly to a height map that also works as a VBO or whatever, and sure most of it could be done today, i just don’t want the api to stand in our way[/QUOTE]
Groovounet is spot on about memory arrangement. Your suggestion would probably be a very slow implementation for texturing. The texture memory fetch operations are NOT random and follow some definite usage patterns with strong spatial coherency. This combined with hardware implementation decisions mean that there are ways to optimize the texture memory on the GPU which provide much better performance than a simple 2D array. The vendors didn’t do straight 2D arrays of data for a reason, and not only to make their life harder.
Memory arrangement is not anything one should concern onselfs with just yet, at least not at the API level, who says a texture has to be read in a specific way.
Lets say a lookup texture in where you store random sampling positions, these have a different usage pattern than one that is used for colors.
also imagine the day where we are not as much rendering as we are doing simple gpgpu computations then memory usage patterns will change once more.
I guess my point is that before you worry about the technical minutia let’s take a long and deep look at how the api should work so that it’s powerful, easy to work with and more or less future proofed.
If you don’t design you API so match the hardware, you are going to get bad performance.
As bertgp said, texture access is all about spatial coherency. Buffer are used as input stream which give two ready differences way to hide memory latencies.
Cuda and OpenCL take advantage of these 2D caches as well.
To test these texture spatial coherency you may display a subdivided quad with random texture coordinates, 1 vertex per pixel and obverse the performance difference with a usual texture coordinates.
