3 ms·

Firefox / webrender developer here. We used to use texture arrays, but we ran in to countless driver bugs with them so have stopped. Back when we were using ar

Firefox / webrender developer here. We used to use texture arrays, but we ran in to countless driver bugs with them so have stopped. Back when we were using arrays, we indeed "resized" them as you describe. When they became large we ran in to terrible performance problems allocating and copying such large blocks of memory. We decided it was better to use fixed size textures and accept some batch breaks.

Const-me 6y ago
> but we ran in to countless driver bugs with them Interesting. I wonder how many of them were bugs of actual OS-supplied GPU driver, as opposed to Angle compatibility layer you seem to be using on Windows? My library uses better designed compatibility layer called diligent engine https://diligentgraphics.com/diligent-engine/ https://diligentgraphics.com/diligent-engine/ > and accept some batch breaks How do you solve Z order changes and similar runtime changes? The example is multiple layers with images. When first rendered they were Z ordered as ABCD, in a next frame reordered as DBCA. It's possible these images are grouped into 2 textures as AB and BC, this means after the reorder you need 1 draw call per image, which is less than ideal. Happens quite often on the web. Like a forum thread with avatars, as user scrolls, the rendering order of avatars changes randomly.
- jamienicol 6y ago
  I can't recall any issues with texture arrays on angle, though there may have been. certainly on macos and especially on mobile. We only have to break the batch if the avatars are in separate textures and they overlap, so it isn't a huge issue in practice. There are cases where it is, but it's much better than the issues we had "resizing" the texture arrays. edit: to clarify, yes if images are in separate textures we must use separate batches, but as long as they don't overlap we can still add more images to the old batch. so the total number doesn't grow too large
  - Const-me 6y ago
    > certainly on macos AFAIK it’s same as on Windows, if you want a reliable GPU API you have to use the native one, Metal or Direct3D respectively. > and especially on mobile Right, these can be hit and miss. There’s hope though, new Android seems to be transitioning from GLES to Vulkan, things might improve eventually. > the issues we had "resizing" the texture arrays. I wonder did anyone tried to use D3D tiled resources, or Vulkan sparse images, for this problem?

Const-me 6y ago

> but we ran in to countless driver bugs with them Interesting. I wonder how many of them were bugs of actual OS-supplied GPU driver, as opposed to Angle compatibility layer you seem to be using on Windows? My library uses better designed compatibility layer called diligent engine https://diligentgraphics.com/diligent-engine/ https://diligentgraphics.com/diligent-engine/ > and accept some batch breaks How do you solve Z order changes and similar runtime changes? The example is multiple layers with images. When first rendered they were Z ordered as ABCD, in a next frame reordered as DBCA. It's possible these images are grouped into 2 textures as AB and BC, this means after the reorder you need 1 draw call per image, which is less than ideal. Happens quite often on the web. Like a forum thread with avatars, as user scrolls, the rendering order of avatars changes randomly.

jamienicol 6y ago
I can't recall any issues with texture arrays on angle, though there may have been. certainly on macos and especially on mobile. We only have to break the batch if the avatars are in separate textures and they overlap, so it isn't a huge issue in practice. There are cases where it is, but it's much better than the issues we had "resizing" the texture arrays. edit: to clarify, yes if images are in separate textures we must use separate batches, but as long as they don't overlap we can still add more images to the old batch. so the total number doesn't grow too large
- Const-me 6y ago
  > certainly on macos AFAIK it’s same as on Windows, if you want a reliable GPU API you have to use the native one, Metal or Direct3D respectively. > and especially on mobile Right, these can be hit and miss. There’s hope though, new Android seems to be transitioning from GLES to Vulkan, things might improve eventually. > the issues we had "resizing" the texture arrays. I wonder did anyone tried to use D3D tiled resources, or Vulkan sparse images, for this problem?