Regarding UAVs and Ogre 2.1
Posted: Sun Apr 12, 2015 4:52 pm
Jesse, aka. holocronweaver, has already implemented image load/store functionality in GL3+ (but it requires manually calling the C++ function). He was thinking into incorporating this functionality at the material level.
I've been researching into how D3D11 does things (they call them UAVs, Unordered Access Views).
D3D11 equals UAVs to RenderTargets; while OpenGL equals them more like textures.
In fact, the D3D11 API call to bind UAVs must set RenderTargets at the same time. There is no API call to only set UAVs.
This is so for performance improvements: they can check for hazards when setting RTs and UAVs (i.e. make sure you don't bind the same resource as both RT and UAV) while they still use the same hazard checking they do for textures to check that you're not binding a texture at the same time it is bound as an RT/UAV.
If the UAV equals a texture, as in OpenGL; they would have to check textures against textures every time a texture changes, which is O( N! ) complexity; and also a very common operation. Considering past experiences, I'm guessing OpenGL just simply skips the check and lets the hazard happen (which is cool when there are hardware extensions that allow you to read/write from these resources at the same time as long as you abide to certain rules).
So, to comply with both I'm drastically changing Jesse's plan on how UAVs are going to be bound in Ogre (since D3D11 is more restrictive than OGL). You will do them via compositor scripts; or via explicit RenderSystem calls in C++; rather than leaving this to materials.
Since UAVs in D3D11 equals SSBOs + image load/store in OpenGL; I'm requiring OGL 4.3 to support the "UAV" feature (rather than OGL 4.2 to just get image load/store).
In the new system, you will bind the UAV to binding points beforehand, that are kept in a list; which will be set the next time a render target is set.
It will be the user's responsibility to ensure the shader's binding point for each ssbo/imagestore variable is in sync with the binding points you set from C++ or compositor scripts.
This is much more simple, elegant, and easy to implement. Plus, all UAV applications I can think of involve switching RenderTargets or doing postprocessing effects (advanced shadow mapping, Order Independent Transparency, Bokeh depth of field, Forward+, Tiled Deferred Shading), for which moving the interface to the compositor (rather than the material) feels like natural.
I'm just keeping you all in the loop.
Cheers
Matias
I've been researching into how D3D11 does things (they call them UAVs, Unordered Access Views).
D3D11 equals UAVs to RenderTargets; while OpenGL equals them more like textures.
In fact, the D3D11 API call to bind UAVs must set RenderTargets at the same time. There is no API call to only set UAVs.
This is so for performance improvements: they can check for hazards when setting RTs and UAVs (i.e. make sure you don't bind the same resource as both RT and UAV) while they still use the same hazard checking they do for textures to check that you're not binding a texture at the same time it is bound as an RT/UAV.
If the UAV equals a texture, as in OpenGL; they would have to check textures against textures every time a texture changes, which is O( N! ) complexity; and also a very common operation. Considering past experiences, I'm guessing OpenGL just simply skips the check and lets the hazard happen (which is cool when there are hardware extensions that allow you to read/write from these resources at the same time as long as you abide to certain rules).
So, to comply with both I'm drastically changing Jesse's plan on how UAVs are going to be bound in Ogre (since D3D11 is more restrictive than OGL). You will do them via compositor scripts; or via explicit RenderSystem calls in C++; rather than leaving this to materials.
Since UAVs in D3D11 equals SSBOs + image load/store in OpenGL; I'm requiring OGL 4.3 to support the "UAV" feature (rather than OGL 4.2 to just get image load/store).
In the new system, you will bind the UAV to binding points beforehand, that are kept in a list; which will be set the next time a render target is set.
It will be the user's responsibility to ensure the shader's binding point for each ssbo/imagestore variable is in sync with the binding points you set from C++ or compositor scripts.
This is much more simple, elegant, and easy to implement. Plus, all UAV applications I can think of involve switching RenderTargets or doing postprocessing effects (advanced shadow mapping, Order Independent Transparency, Bokeh depth of field, Forward+, Tiled Deferred Shading), for which moving the interface to the compositor (rather than the material) feels like natural.
I'm just keeping you all in the loop.
Cheers
Matias