-
Notifications
You must be signed in to change notification settings - Fork 361
imageHeight -> imagePitch #519
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
Conversation
spec/index.bs
Outdated
| GPUBufferSize offset = 0; | ||
| required unsigned long rowPitch; | ||
| required unsigned long imageHeight; | ||
| required unsigned long zPitch; // in units of rowPitch bytes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically imagePitchInBytes is zPitch * rowPitch? I think imageHeight is more clear, but maybe because I'm more used to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. My problem is 'imageHeight' sounds like the height of some image, and it really isn't at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could be more to the point, like rowsPerDepthSlice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a little imprecise because not all of those rows are necessarily in the depth slice. But it does use "depth" instead of "z" which matches elsewhere (copySize.depth) better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... to go in the opposite direction, maybe it would be better to have copySize have z and layer be separate concepts (and either "depth" or "layerCount" must be 1).
I don't have any clue whether 3d array textures would ever be a thing, but maybe we should design the api to allow them and totally separate those two "depth" concepts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most APIs have features to convert 2D array layers to 3D texture views and vice-versa so I think it is safe to assume that depth and layers are the same thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kainino0x
3d array textures might sound unreal, but there definitely are cube arrays
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How should cubemaps be specified? Does the 6 go into layer count or depth?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, it's the layer count.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see also #520.
|
Alternate proposal from #148 that I'd be happy to use: |
|
The "image" naming links it better to the way other APIs name this concept. |
|
This was discussed in the 2020-01-06 meeting |
|
I've updated to imagePitch in hopes it's something people can agree on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pitch: TECHNICAL
"the distance between successive corresponding points or lines, e.g., between the teeth of a cogwheel."
Especially if we are already using "rowPitch", "imagePitch" makes sense to me. I was under the impression the underlying APIs shared some terminology, but nope.
|
We'll talk about this at the F2F. I think we're fairly happy with the names. However, we'd like to figure out what the units should be:
We should be sure to understand how this works with compressed textures. |
|
Discussed at F2F. To be resolved by spec editors based on the input there. |
|
new preference: "bytesPerRow" and "rowsPerImage" |
|
And, per F2F decisions, the field becomes optional / used only for 3d. I think I'll open a new PR for all of it together. |
* depth related tests * fix comments
Fixes #148
Preview | Diff