New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Texture compute support #138
Comments
All seems pretty reasonable. For the second item would it just be a matter of changing |
@tsherif Not sure if github pings you when entries are edited, so adding this comment just in case. |
Thanks for the thorough treatment! This sounds very interesting. I'll read in more detail and make comments later, but one note is that a core part of how I've developed PicoGL is to go "example first", i.e. choose an algorithm I want to implement and build out the API to support it (I should probably document this somewhere). There are two reasons for this:
So what I'd suggest is start by building out that reaction diffusion example and adding the API features required to support it. |
Oh and to answer your questions about FBOs. I believe all attachment to an FBO have to be the same size, but I'll double check that... |
Example first sounds good! |
So I spent some time investigating some details regarding textures, reading and writing them , how the format parameters work etc. Ultimately I should write a one or two page tutorial regarding the details that are important for machine learning and physics simulations, but for now I'm going to place bits and pieces here.
So one basic question that needs to be decided is that for the purposes of picogl, should a My guess is that there aren't many use cases where data is being marshalled into and out of texture in multiple formats but since picogl does a good job of keeping possibilities as open as possible I figured I would at least raise the question. Probably a reasonable compromise is to always remember the last used marshalling parameters, and use them by default, if they are not specified. |
There are some features that I think might be useful to add to simplify performing 'texture compute' (such as the stuff done in tensor.js). This primarily involves adding helpers for reading and writing data from textures; I don't think this requires much code or refactoring, but as I was thinking through the various issues it seemed tricky enough to first write things down and get some outside input.
High Level Goals
New Features
Texture
(or the parameters accepted by theTexture
constructor) suggest:TypedArray
to useflipY
(I never get this right)Gotchas
It would be helpful if the following quirks could be addressed properly for the user automatically:
app.gl.pixelStorei(PicoGL.UNPACK_ALIGNMENT, 1)
forR8
app.floatRenderTargets().linearFloatTextures();
Cleanup
The following points came up as I was reading through the current code base
pixelStorei
calls inTexture.resize
need to be called for bothread
andwrite
of pixels (with properUNPACK
/PACK
variant)generateMipMap
should be possible to trigger by users (for instance after rendering to texture)https://stackoverflow.com/questions/50979565/summing-the-values-in-a-webgl2-r32f-texture-by-generating-a-mipmap
width
andheight
autoset to the last attachment'swidth
andheight
-- want to better understand if this has unintended consequences in support multiple attachments... ask @tsherif?Implementation Path
Texture/Typed Array details
Texture
(or the parameters accepted by theTexture
constructor) suggest:TypedArray
to useR8
->Uint8Array
or normed...RGB9_E5
see https://webgl2fundamentals.org/webgl/lessons/webgl-data-textures.html?precision
directive to use in shaderThe text was updated successfully, but these errors were encountered: