Hello, here are a few suggestions of things I would really like to see in OpenGL.
Offline GLSL Compilation and Official Bytecode
Okay, this is something that’s been requested before, but it has been ignored. There needs to be an official bytecode format that specifies the binary. Why? Offline compilation with ALL optimizations on and third party compilers. As it stands currently, you must distribute the GLSL with your app (not a big deal) then waste the user’s time (in addition to the time it takes to perform an install) to recompile a shader that is perfectly capable of being done offline. This has two detrimental effects. 1: Slower start-up time whenever hardware or drivers change. 2: You don’t get the best optimizations you could. Maybe the driver implementation of the compiler is flawed. Maybe there’s a bug in the compiler implementation. Maybe you simply don’t want to use GLSL. Yeah, you can use Cg but that’s no better. You’re locked to one company to provide updates to a closed source compiler. Not good for me.
Offline GLSL compilation can be accomplished, by more than just implementors of OpenGL, if an official bytecode exists, and is maintained. Make it an extension at first, then make it part of the official spec. It doesn’t matter how the bytecode looks, how complicated it is, or anything like that as long as it’s functional. Once you have the bytecode, just use the existing APIs to apply the binary. Maybe it’s in the format of GL_BYTECODE_FORMAT or something similar. Direct3D has this feature. I can implement my own HLSL compiler and not be locked in to Microsoft’s implementation if I want to. I can’t do that with GLSL. It’s kind of funny actually, I can compile GLSL to HLSL bytecode. (Which is documented in the WDK btw.)
Some people will argue that the GL_ARB_get_program_binary extension allows you to produce binaries that are optimized for the hardware instead of just in general. Yes, that’s true. However, there’s no reason the bytecode format couldn’t be converted to a binary by the GL in the same way to produce a binary optimized for the hardware. It would probably be easier too since everything’s in a bytecode format and easy to optimize/interpret.
This extension should be propogated back all the way to the first hardware that’s capable of executing shaders. Why? Compatability. D3D worked with bytecode all the way back to when shaders were first introduced. GL can too.
Here’s a comparison between D3D9 bytecode shader loads, and OpenGL shader loads (among other things).
Official Bindless Objects Extension
NVIDIA and AMD offer separate but (as far as I can tell) equivalent solutions for accessing textures without binding them, saving a lot of unnecessary driver overhead. These are the two big players in the game. Then there’s Intel. I’ve heard they offer a bindless solution as well, but I haven’t bothered verifying this. In this day and age where virtual texturing is starting to become common place (at least in one form or another) the ability to just directly access texture memory is becoming increasingly more important.
For reference, see GL_AMD_pinned_memory, GL_NV_bindless_texture, and GL_NV_vertex_buffer_unified_memory.
API To Determine What’s Supported By Hardware
D3D9 and below had GetDeviceCaps(). D3D10+ has “feature levels” and “feature sets” that you can check. These feature sets are useful to determine what the driver has support for.
Now, believe me, I like that OpenGL forces the driver to support some things, even if it has to fallback to software to do so. However, I also want to find out what falls back to software. That way, in my code, I can choose to avoid that particular feature and perform a work-around. Maybe this can be done through queries. e.g., issue an Is Hardware query for a set of OpenGL commands using the current state. Then, check the query for a boolean value. If true, then the hardware can execute the GL commands within the query statement. If false, then the hardware can’t, so do something else. This seems like it would be easy to implement. At least, it would be easy to add to the specs. (No new entry points, one added enum value, and some description.)
Programmable Blending
Why is this still fixed function? I’ve noticed that in OpenGL ES, on NVIDIA Tegra hardware, whenever you change the fixed-function alpha blending state, the shader bytecode is regenerated. (Someone at Unity discovered this actually. I don’t remember where I read this from specifically though, sorry.) So, I assume that means hardware is capable of performing it. The D.I.C.E. Frostbite 2 (Battlefield 3) guys seem to want this as well. I’ll leave this section short since AAA developers already want this feature. (Sorry for not providing more in terms of citation here.)
Sampler Shaders
Samplers seem quite fixed-function to me as they rely on various state settings and so on. Perhaps sampler shaders could be implemented? Basically, when a sampler shader is applied it would allow for programming exactly what type of filtering is applied when a texture image is retrieved. This can be accomplished to some degree already by using point/nearest filtering (that is, no filtering at all) and applying several samples within the pixel shader. However, it is my understanding that the hardware that handles sampling can make a few optimizations based on the areas sampled. If that is correct, perhaps a sampler shader could be used as a more optimized method for performing said sampling. Here are two examples. 1: Virtual textures and atlas textures have page boundaries that cannot be crossed. You usually have to add padding (which is unfortunate) around each page, or put the data within volume textures (which can cause other issues, or may not be feasible based on certain hardware limits). The third alternative being: implement the filtering yourself. 2: Implement elliptical texture filtering (a higher quality form of filtering) and use it across multiple shaders without using subroutines. With programmable samplers it would be easier to implement other shaders. You wouldn’t have to use subroutines, just generate a new sampler then access the texture data like normal within the shader.
Overall, this isn’t something that’s hugely necessary, but I haven’t heard of anything like it before and, at least for me, it would be fairly convenient. Also, with AMD’s introduction of partially resident textures I think this is probably hugely unnecessary.
Official OpenGL Support for Partially Resident Textures
I like AMD’s implementation, but it’s just limited to AMD. This should be a core requirement for GL 5~.
[HR][/HR]
If there are ARB extensions available for anything I’ve mentioned above, I would love to know their names.
I’m not looking for alternatives or work-arounds to any of the above suggestions. I know what I’m doing. These are just some things I’d fancy seeing in an official GL specification.
Cheers,
Aaron