-
Notifications
You must be signed in to change notification settings - Fork 107
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
QueryDmaBufModifiersEXT
does not guarantee obtained modifiers are actually usable
#201
Comments
Reference: https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt We need original authors or from the dmabuf community to comment and provide feedback. If I recall documentation, its possible the size of the buffer is too small and a fault will happen (MESA or Weston). So I guess the original authors realized the "size" could be a lie. Either its the right size or there is a fault. Although size checks are nice check to add. As for max texture size, you can query GL_MAX_TEXTURE_SIZE |
|
That's Vulkan API. And if you have Vulkan and EGL/GL these are likely the same - maximum the GPU can handle. |
This is a useful piece of information, can we add this to EGL as well? |
You can query max rendering surface from the EGL Configs, that will match up with Max renderer able image of Vulkan. EGL_MAX_PBUFFER_HEIGHT EGL_MAX_PBUFFER_PIXELS |
That is not what I want though. What I want to query is the maximum possible image size for a given DRM format modifier, or whether a given image dimension is supported by a DRM format modifier. |
EGL Images created from textures, and textures from EGL Images would be limited to that GL_MAX_TEXTURE_SIZE. |
Yes, that's what the spec says. But in practice drivers will impose size limits, and that information is exposed nowhere in the API, and that is the problem. Using Vulkan you will be able to query this information, and this is missing from EGL. |
I understand what you are saying. EGL could have an EGLImage that is not used with OpenGL/ES. So there may not be a GPU limit - if say used with OpenCL or such. So the limit is only imposed when the importing to a texture - that has a GPU limit. |
I don't understand what you are saying. There are limits when creating an EGLImage with DRM format modifier. |
You'll have to point that out, I don't see what modifiers you are referring to, |
What do you mean? Now I am confused. We are talking about DRM format modifiers, right?
Yes! And that is the problem I've been trying to raise this whole time. Drivers in practice impose size limit based on modifiers used, but EGL API does not expose that. |
My apologies, I have several concurrent tasks, some related. |
So the thing to do would be copy https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt Put that in a pull request and we get as many of the linux participants to review as possible for feedback - needed to justify making this a EXT extension. |
@linyaa-kiwi add for participant/monitor |
Thank you. |
QueryDmaBufModifiersEXT
lets me query which modifiers are supported for a given format, but the information I provide to this API (i.e. format) is not sufficient to determine whether a modifier will actually work. For example, at allocation time, mesa AMDGPU will also check if the size of the buffer is within supported range (see: https://gitlab.freedesktop.org/mesa/mesa/-/blob/2487a875527f636565a7b39036690fbf7c5d46db/src/gallium/drivers/radeonsi/si_texture.c#L1564), and will fail if I try to allocate a texture that's too large.Can
QueryDmaBufModifiersEXT
be extended to incorporate size info into the query as well? This will make it "complete" w.r.t, e.g.gbm_bo_create_with_modifiers
.The text was updated successfully, but these errors were encountered: