Texture formats and compute shaders

[Technologicat]

@rdb

These features are all supported by Panda.

Ok. Thanks!

@rdb

As for float textures, just set a texture component type to float, and set an appropriate format from the list.

Thanks for the keywords

So, based on https://discourse.panda3d.org/t/setting-tfloat-texture-from-numpy-array/9093/3] and [url]https://www.panda3d.org/reference/1.8.1/python/classpanda3d.core.Texture.php, maybe something like:

mytex = Texture("my_procedural_texture")
mytex.setup2dTexture(...)

choosing TFloat for ComponentType, and format… I suppose for arbitrary scalars, any one of FRed, FAlpha or FLuminance should be ok, but it seems there’s no format for float3 or float4 vectors? Or am I missing something? What happens with the combination TFloat and FRgba32?

(From a data storage and memory access perspective, it would be ideal to store the three values on each row of the tridiagonal matrix in the .xyz components of a float3. Or even better, using a float4, store the row and the corresponding element of the load vector (right-hand side in the linear equation system) into .xyzw.)

@rdb

As for 3-D textures, this is described in the manual:
panda3d.org/manual/index.php/3-D_Textures
2-D array textures are also supported in a similar fashion.
As for compute shaders, this is described in detail in the manual:
panda3d.org/manual/index.ph … te_Shaders

Thanks for the specific links! I’d previously read the page on compute shaders, but had missed the one on 3D textures.

@rdb

I don’t really understand your question about using a shader on a part of the viewport. That all depends on the shape and posistion of the mesh you’re rendering. You can also discard fragments from a fragment shader.

Ah, that’s true. That is indeed how it was done in the GPU Gems link that I posted. The geometry was set up so that each computation kernel (implemented as a fragment shader) operates on the appropriate fragments of the buffer.

How about 3D textures, i.e. how to update a selected subset of cells? For a 3D PDE application, it seems inefficient to run the boundary shaders (for a cube domain, all 6 of them) on the whole domain and discard almost all fragments.

(For a time-dependent PDE simulation in 3D space, at each frame (time step), all voxels in the 3D texture need to be updated. The choice of the computational kernel to use for each particular cell depends on whether the cell belongs to the interior of the domain, or to one of its boundaries. The branch can be resolved statically in the code that invokes the shaders, but to do that, one needs to be able to invoke each shader on a subset of cells.)

@rdb

Keep in mind that compute shaders are slower than fragment shaders for most image processing purposes, and may be overkill for something that fits very well within the scope of a fragment shader. I haven’t read the paper, but it might just suffice to write a fragment shader to do each reduction step. The whole thing reminds me a bit of mipmapping, in fact, which is done along similar reduction principles.

Hmm, good point. I’ll investigate if the tridiagonal solve can be done using regular fragment shaders.

If I understood correctly, it should be enough to configure the component format of the intermediate buffers as float (if that is even necessary in this very special application), create a fullscreen quad for each (imitating FilterManager), and then render in the usual fashion.

The number of steps required depends on the pixel dimensions of the original viewport, so resizing the window while this filter is running may be problematic, but I suppose that can wait for later. The postprocessing framework could be later extended to provide an onResize() event, to which the depth-of-field filter would react by requesting a pipeline reconfigure (so that the internal texture buffers are re-generated before the next frame is rendered).

@rdb

As for adding a compute shader step in the FilterManager; the simplest way would simply be to replace the full-screen quad in a particular pass with a ComputeNode configured appropriately, although you don’t technically need a bound buffer for compute shaders to work.

Ok. Thanks for the tip!