-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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 API issues #4290
Comments
Not at the moment, but here are some best practices for WebGPU: https://github.com/toji/webgpu-best-practices/blob/main/img-textures.md |
From forum: https://forum.playcanvas.com/t/pre-uploading-of-pc-texture/3212/ Users are requesting the ability to manually upload textures to the GPU so they can control the potential framerate stutter when loading in sections of an open world. Eg, they could upload textures over several frames. |
To add to that: currently the textures are loaded "on demand" (i.e. when they are first drawn). We would like to be able to upload large textures during our initial loading screen instead, in order to prevent frame stutters later in the game. We would be fine with all textures being uploaded in 'one frame' in that case. It's just the overall timing of that frame we are concerned with. |
Regarding the timing - we work around it by drawing a bunch of cubes with all materials that will be used in game during the first frame (which is hidden by a loading screen, so the player doesn't see them), then remove them and show the game. |
Hi everyone, I recently started looking into adding support to update particular textures/slices from a Texture2DArray. In it's current iteration texture 2d array support is not flexible enough and not that useful. While investigating this I was reading all the discussions from #6004, this ticket and the references mentioned here. Let's look at texture 2d arrays. They could be used to load a sprite flipbook upfront but it can also be useful to construct atlases dynamically. Those can be used to render terrain or props more optimally (minimizing draw calls, etc.) or used for virtual texturing. These don't have to maintain the CPU side buffers, instead each texture/slice could be uploaded on demand. Another use case would be for a lightmap atlas or AO atlas for a chunked terrain/scene. We would know how many chunks we have in advance, hence how many textures/slices we need in the texture array and reserve that space with no upfront available data (maybe initialize it with sensible defaults?), so we can start using the texture right away. Over a number of frames we could upload the slice for each chunk. Consider discarding of CPU side data for reducing memory usage. If I'm not mistaken at the moment PC preserves the texture data on the CPU side, most probably to quickly recover from context lost events, but that duplicates the memory needed for textures (RAM + VRAM, or in case of most mobile devices 2XRAM because RAM is shared with GPU IIRC). With all the above we should target an API that:
(additionally)
Let me know if any of this makes sense or if anyone has additional use cases or thoughts on how the API should look like. |
I worked on some of the changes mentioned above when time allowed for the last couple of weeks.
If this is something that the team won't consider please let me know so I can stop going into this direction, otherwise I'll continue towards a PR. |
Thanks for working on this @heretique. I find it unlikely to go ahead with the split of the Texture class into multiple classes, as that would have large impact to our user base / Editor. Maybe we can just extend the
I have not looked in detail to see if this is possible. We could also add a new member, for example |
Thanks for the feedback @mvaligursky I'm going to take a new stab at this. |
Some observations of the current texture API:
setSource
only works with 'browser interface' objects (not arrays of data) and the function correctly tracks which mipmap levels are dirty using_levelsUpdated
.getSource
will return browser interface objects and also arrays of data which it strictly probably shouldn't (since it is matched withsetSource
).lock
andunlock
work with arrays data and the entire texture is always re-uploaded if any mipmap level is locked, whether for read or write.Ideally we'd have an API that:
Also, the current API assumes textures have CPU-side data which is uploaded to GPU. However we often have GPU-side texture data which we want to copy back to CPU.
@mvaligursky are there any additional restrictions or requirements imposed by webgpu on texture handling?
The text was updated successfully, but these errors were encountered: