I am wondering how is Nvidia going about doing this? UBO? or some kind of extension that isn't out yet? I been waiting for ever on this tech, to allow you to bind as many textures as you need no more need for texture atlases, texture arrays ect....
I am wondering how is Nvidia going about doing this? UBO? or some kind of extension that isn't out yet? I been waiting for ever on this tech, to allow you to bind as many textures as you need no more need for texture atlases, texture arrays ect....
There is this: Bindless Texture and image API patent, going to the last 2 pages of the pdf of the patent application, one can see the interface. It looks like to me that they are doing a very similar interface as for GL_NV_shader_buffer_load, you make the "texture handle resident", (see MakeTextureHandleResidentNV), and looks like a new uniform type whose value is set with the function UniformHandleui64NV. The application also mentions a spec extension name (which I guess is what the final beans will be): NV_bindless_texture. There is stuff for both image (i.e. write access too) and textures (read only)..
Obviously, NVIDIA is trying to find a way to get people to write as little OpenGL in their OpenGL applications as possible. Currently, you can use NVIDIA-sanctioned APIs for shaders (Cg/assembly), vertex data (bindless attributes), uniform blocks and buffer textures (bindless uniforms). And now texture/image binding.
What does that leave? Blending? The viewport? FBOs (they'll probably have a way to use "bindless textures" with that)? Can you even call it OpenGL at that point when 90% of your "OpenGL" calls have "NV" at the end?
Obviously, NVidia is trying to innovate to provide the fastest method to use their GPUs possible.Originally Posted by Alfonse Reinheart
The purists can scoff. Those of us on the practical side shipping products where perf sells will happily just use it when advantageous and available. I'm personally glad they're applying their expertise here.
Hopefully the ARB is looking carefully at what the vendors come up with for driving GPUs harder/faster and will promote up what is (or could be) broadly supported.
Lets put it in a different perspective: the GL specification, although worked on ALOT and has a revival has not kept up with the hardware capabilities.. neither has D3D.
AMD has partially resident textures (Cool)
NVIDIA has "no more limits on number texture units" (Cool)
and neither D3D or OpenGL-Core have anything to expose these features. Lets face it, D3D and unextended OpenGL represent the lowest common denominator.
Just to put gasoline on the fire: GL4.2, if one wishes to abuse it, already has something to get away from FBO's: the image API (i.e. GL_ARB_shader_image_load_store) and now with NVIDIA's jazz, it looks like the limit on number of these active at once is essentially only bounded by VRAM... though using image instead of FBO's to render to texture is going to foo-bar performance.. it is not meant for thatFBOs (they'll probably have a way to use "bindless textures" with that)?
I'd doubt though that 90% calls end with NV
That's about right. The extension spec was published on the NVIDIA developer site this morning:
http://developer.download.nvidia.com...ss_texture.txt
I've submitted it for publication in the OpenGL extension registry, but it hasn't been pushed out yet.
Does it require Kepler GPU?That's about right. The extension spec was published on the NVIDIA developer site this morning:
http://developer.download.nvidia.com...ss_texture.txt
I've submitted it for publication in the OpenGL extension registry, but it hasn't been pushed out yet.
Yes; the extension is not supported on Fermi or earlier NVIDIA GPUs.
Why not? If it proves to be useful and becomes adopted by AMD in some form why not?
OK, then we'll call it NVGL.
NV is very permissive with its GL implementation. Nobody prevents anyone to use "standard" OpenGL. But, if there is a faster way to do something, and one can afford it to buy particular piece of hardware in order to achieve better performance, than I don't see any reason why NV extensions shouldn't be used.
Exactly! Those extensions maybe cannot be used for games and other software aiming wide audience at the moment, but for the specialized software they are more than welcome. Furthermore, if audience become aware of benefits and increase purchase of NV cards it will force competitors (I mean AMD at the first place) to improve their capabilities and drivers.
There are no downsides of API improvement. We all benefit. Even AMD users will benefit from bindless, if AMD accepts the challenge.
So why is nothing being done to improve the LCD?Lets face it, D3D and unextended OpenGL represent the lowest common denominator.
Bindless vertex rendering identified a performance issue with regard to caching and such when it comes to vertex setup. That was years ago. The ARB has done nothing to solve this performance issue. Integrating bindless as-is is a bad idea, but they've done nothing to even attempt to correct the binding problem.
Because NVIDIA patented it. Which means AMD would have to license it from NVIDIA.Why not? If it proves to be useful and becomes adopted by AMD in some form why not?
Somehow, I don't see that happening.
It's called "vendor lock-in."But, if there is a faster way to do something, and one can afford it to buy particular piece of hardware in order to achieve better performance, than I don't see any reason why NV extensions shouldn't be used.
NVIDIA needs to retain their hold over the workstation graphics card market, because CPU-built GPUs are currently eating the low-end GPU market. The best way to do that is to change their API from OpenGL to something proprietary. Of course, workstation app creators aren't going to change APIs wholesale.
But they'd be willing to make a few modification to the current one.
Hence NVGL. Cg/assembly shaders, fed by bindless vertex attributes, accessing bindless uniforms, and now sampling from bindless textures. You can pick how much NVGL you want, but once you start using it, your codebase is at least partially NVGL. And thus, unless you write a new codepath, not compatible with non-NVIDIA hardware.
For "Those of us on the practical side shipping products," this means that they'll have to continue spending money on NVIDIA's products. Rather than letting capitalism and competition work to drive prices down, they're locked into NVIDIA's world. They write NVGL applications that only work on NVIDIA's GPUs, and their customers must therefore continue to buy NVIDIA's cards. It creates a cycle, a monopoly that's difficult to break.
That is only a good thing for those who are personally invested in NVIDIA's world.
Posting Permissions
