You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unify GPUQueue.writeTexture() and GPUQueue.copyExternalImageToTexture() #4206
They appear to do the same conceptual thing, just with different types of inputs. I don't really see any reason why these need to be different entry points.
I'm not saying the two shouldn't be unified but...
One possible reason, copyExternalImageToTexture takes parameters that are irrelevant to non-images and via versa
writeTexture takes a source stride, copyExternalImageToTexture does not and can not, the user doesn't know the source stride.
writeTexture copies data into compressed textures. You arguably can not copy data from an image/video/canvas into a compressed texture in a meaningful way unless you compress on the fly and texture compression algos are generally slow and have quality/time tradeoffs.
copyExternalImageToTexture takes various options like flipY, colorSpace, premultipliedAlpha which are only relevant to images. writeTexture does not. This was an issue in WebGL where, to be consistent, flipY was honored, even when it was user data and not an image/canvas/video but other options were ignored.
We have four functions to copy data to a texture. They all do different things and I think it's fine for them to be different:
copyBufferToTexture - copy raw bytes from a GPU buffer to a GPU texture
writeTexture - copy raw bytes from a CPU buffer to a GPU texture
copyTextureToTexture - copy a portion of another GPU texture to a GPU texture
copyExternalImageToTexture - copy an "opaque image" to a GPU texture. You do not know if the transfer is originating from the CPU, GPU, or both, it is opaque to you. For some images, it might be the former, for others, it might be the latter.
I do not think these four should be unified. writeTexture takes a data layout that specifies things like "rowPitch" which do not apply for an ExternalImage. If I was to make an argument, unifying copyExternalImageToTexture and copyTextureToTexture might make sense, but I think keeping them separate is better API design.
Reacted by Teodor Tanasoaia, Corentin Wallez and Kai Ninomiya
writeTexture and copyExternalImageToTexture do not do the same thing. Others have already gone into detail about this but I'll add some bits.
writeTexture is like copyBufferToTexture, it copies bytes (as best it can). As someone said yesterday you could also accurately call it copyExternalBufferToTexture, or something. In particular, the concept of color does not make an appearance here. It can copy into non-color textures (depth and stencil). writeTexture is a not an interop point with other Web APIs, only with JavaScript.
copyExternalImageToTexture is a much higher-level API, semantically based on colors, not bytes. As Gregg points out, this means colorSpace and premultipliedAlpha are here, and only make sense here. It can be used to copy non-graphical data if you want, but it puts at the forefront the fact that you're corralling non-image data through an image interface, and that's important. copyExternalImageToTexture is exclusively an interop point with other Web APIs.
Calling them the same would IMO be misleading and very confusing - it's fundamentally not possible without some very weird carve-outs, because of the bytes vs colors thing. Would byte sources be tagged with color metadata (this is covered be copyExternalImageToTexture from ImageData in #3430)? Or would the destination's color parameters be ignored when the source is bytes? Or would we require the destination color parameters to be null when the source is bytes, and require them to be non-null when the source is not bytes?
Activity
greggman commentedon Jun 28, 2023
I'm not saying the two shouldn't be unified but...
One possible reason,
copyExternalImageToTexturetakes parameters that are irrelevant to non-images and via versawriteTexturetakes a source stride,copyExternalImageToTexturedoes not and can not, the user doesn't know the source stride.writeTexturecopies data into compressed textures. You arguably can not copy data from an image/video/canvas into a compressed texture in a meaningful way unless you compress on the fly and texture compression algos are generally slow and have quality/time tradeoffs.copyExternalImageToTexturetakes various options likeflipY,colorSpace,premultipliedAlphawhich are only relevant to images.writeTexturedoes not. This was an issue in WebGL where, to be consistent, flipY was honored, even when it was user data and not an image/canvas/video but other options were ignored.emidoots commentedon Jun 29, 2023
suggestion: use the same prefix for legibility, e.g.
writeTextureandwriteTextureExternalImageor suchmagcius commentedon Jun 29, 2023
We have four functions to copy data to a texture. They all do different things and I think it's fine for them to be different:
copyBufferToTexture- copy raw bytes from a GPU buffer to a GPU texturewriteTexture- copy raw bytes from a CPU buffer to a GPU texturecopyTextureToTexture- copy a portion of another GPU texture to a GPU texturecopyExternalImageToTexture- copy an "opaque image" to a GPU texture. You do not know if the transfer is originating from the CPU, GPU, or both, it is opaque to you. For some images, it might be the former, for others, it might be the latter.I do not think these four should be unified.
writeTexturetakes a data layout that specifies things like "rowPitch" which do not apply for an ExternalImage. If I was to make an argument, unifying copyExternalImageToTexture and copyTextureToTexture might make sense, but I think keeping them separate is better API design.kainino0x commentedon Jun 29, 2023
writeTexture and copyExternalImageToTexture do not do the same thing. Others have already gone into detail about this but I'll add some bits.
Calling them the same would IMO be misleading and very confusing - it's fundamentally not possible without some very weird carve-outs, because of the bytes vs colors thing. Would byte sources be tagged with color metadata (this is covered be copyExternalImageToTexture from ImageData in #3430)? Or would the destination's color parameters be ignored when the source is bytes? Or would we require the destination color parameters to be null when the source is bytes, and require them to be non-null when the source is not bytes?
kainino0x commentedon Jun 29, 2023
edit: remembered the term used yesterday was "copyExternalBufferToTexture".
litherum commentedon Jul 26, 2023
Ok, happy to close this as no change