4 ms·

Texture arrays aren't available on GLES 2.0, which I believe WebRender targets. > It’s possible to append new layers into an array without moving data across P

Texture arrays aren't available on GLES 2.0, which I believe WebRender targets. > It’s possible to append new layers into an array without moving data across PCIe and back. ? As far as I know, texture layer dimensions have to be specified up-front. Unless, I suppose, you're OpenGL and the driver lies to you about that with mutable textures, but it's really creating a new texture under and doing a full copy for you behind the scenes.

Const-me 6y ago
> which I believe WebRender targets OpenGL 3.0 and OpenGL ES 3.0: https://pcwalton.github.io/slides/201808-webrender/ https://pcwalton.github.io/slides/201808-webrender/ They both support texture arrays. > texture layer dimensions have to be specified up-front Indeed, but it's possible to create another larger one, and copy layers between arrays within GPU. It's the same idea as std::vector on CPUs, most heaps can't resize memory either, they instead allocate new blocks and copy. There're two wins with texture arrays. 1. Removes area limitation. 2D textures are often limited to rather small size, like 2k^2 pixels. Same limitation applies to arrays, but with multiple layers their total area is only limited by VRAM size. That 2D library I've linked above renders arbitrarily complex 2D graphics with only 2 draw calls, regardless on how many sprites or font glyphs are used in the scene. Two because front-to-back opaque followed by back-to-front translucent. 2. These packing algorithms often scale worse than linearly with available area or count of sprites on the atlas. Using multiple layers of the array takes care of that, new sprites are only packed into the last layer, and layer size is never too large.
- jamienicol 6y ago
  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

> which I believe WebRender targets OpenGL 3.0 and OpenGL ES 3.0: https://pcwalton.github.io/slides/201808-webrender/ https://pcwalton.github.io/slides/201808-webrender/ They both support texture arrays. > texture layer dimensions have to be specified up-front Indeed, but it's possible to create another larger one, and copy layers between arrays within GPU. It's the same idea as std::vector on CPUs, most heaps can't resize memory either, they instead allocate new blocks and copy. There're two wins with texture arrays. 1. Removes area limitation. 2D textures are often limited to rather small size, like 2k^2 pixels. Same limitation applies to arrays, but with multiple layers their total area is only limited by VRAM size. That 2D library I've linked above renders arbitrarily complex 2D graphics with only 2 draw calls, regardless on how many sprites or font glyphs are used in the scene. Two because front-to-back opaque followed by back-to-front translucent. 2. These packing algorithms often scale worse than linearly with available area or count of sprites on the atlas. Using multiple layers of the array takes care of that, new sprites are only packed into the last layer, and layer size is never too large.

jamienicol 6y ago
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?