-
Notifications
You must be signed in to change notification settings - Fork 105
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
WIP: Add EXT_config_drm_format_query extension #161
Open
amshafer
wants to merge
1
commit into
KhronosGroup:main
Choose a base branch
from
amshafer:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,107 @@ | ||
Name | ||
|
||
EXT_config_drm_format_query | ||
|
||
Name Strings | ||
|
||
EGL_EXT_config_drm_format_query | ||
|
||
Contributors | ||
|
||
Contacts | ||
|
||
Austin Shafer, NVIDIA (ashafer 'at' nvidia.com) | ||
|
||
Status | ||
|
||
Complete. | ||
|
||
Version | ||
|
||
Version 1 - July 5th, 2022 | ||
|
||
Number | ||
|
||
EGL Extension #149 | ||
|
||
Extension Type | ||
|
||
EGL client extension | ||
|
||
Dependencies | ||
|
||
Written based on the wording of the EGL 1.5 specification. | ||
|
||
This extension inlcudes the enum EGL_LINUX_DRM_FOURCC_EXT as defined in | ||
EGL_EXT_image_dma_buf_import and requires the EGL_KHR_stream extension. | ||
|
||
Overview | ||
|
||
This extension adds an EGLConfig attribute for stream surface | ||
configurations that specifies a DRM format, as defined in drm_fourcc.h. If | ||
an application needs to share buffers with other libraries or processes | ||
that require specific formats, then this allows an application to select a | ||
matching EGLConfig accordingly. EGLStream applications may need to know | ||
what DRM format a surface is using so that they can pass the format and any | ||
modifiers to other APIs or other stream consumers. | ||
|
||
This extension allows passing EGL_LINUX_DRM_FOURCC_EXT to | ||
eglGetConfigAttrib, allowing the application to forward the format code | ||
as needed. This is only valid on EGLConfigs which have the EGL_STREAM_BIT_KHR | ||
appear in the EGL_SURFACE_TYPE attribute. | ||
|
||
New Types | ||
|
||
None | ||
|
||
New Functions | ||
|
||
None | ||
|
||
New Tokens | ||
|
||
Accepted as an attribute in the <attribute> parameter of | ||
eglGetConfigAttrib: | ||
|
||
EGL_LINUX_DRM_FOURCC_EXT 0x3271 | ||
|
||
Changes in section 3.4.3 "Querying Configuration Attributes" | ||
|
||
Add EGL_LINUX_DRM_FOURCC_EXT to the attributes accepted by | ||
eglGetConfigAttrib. EGL_LINUX_DRM_FOURCC_EXT specifices a DRM format code | ||
as declared in the Linux drm_fourcc.h header. This is only valid on | ||
EGLConfigs which have the EGL_STREAM_BIT_KHR appear in the EGL_SURFACE_TYPE | ||
attribute. | ||
|
||
If EGL_LINUX_DRM_FOURCC_EXT is the attribute being requested and the | ||
EGLConfig does not have a corresponding DRM format, then DRM_FORMAT_INVALID | ||
is returned. | ||
|
||
Changes in section 3.4.1 "Querying Configurations" | ||
|
||
If EGL_LINUX_DRM_FOURCC_EXT is specified as an attribute in the attrib_list | ||
argument of eglChooseConfig, then it will be ignored when choosing a | ||
config. | ||
|
||
Issues | ||
|
||
1. Should EGL_LINUX_DRM_FOURCC_EXT be usable as an attribute in eglChooseConfig? | ||
|
||
RESOLVED: No, eglChooseConfig should ignore EGL_LINUX_DRM_FOURCC_EXT. We can't | ||
appropriately handle EGL_DONT_CARE due to possible collisions with DRM format | ||
values. Currently there is no DRM format that aliases with EGL_DONT_CARE, but | ||
there is no guarantee that it cannot happen in the future. | ||
|
||
2. Should this be limited to stream surface configs? | ||
|
||
RESOLVED: Yes, considering the only use case for this right now is interactions | ||
with EGLStream applications it doesn't make sense to support it in all cases | ||
and open the door to unintended consequences. If more use cases for this | ||
query operation appear then this restriction can be lifted. | ||
|
||
|
||
Revision History | ||
|
||
#1 (July 5th, 2022) Austin Shafer | ||
|
||
- Initial draft |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
If this is the only concern causing it to not be usable with
eglChooseConfig()
, we can simply reserve it upstream and ensure that it never gets used. (Practically speaking it is of zero concern since the upstream FourCC codes are defined in terms of ASCII character codes, and ASCII 255 is not going to pass review, but we can also explicitly reserve it if it would make you more comfortable.)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.
I figured that the chance of 0xFFFFFFFF being a real format is pretty much zero, but unless it's explicitly reserved, I wouldn't want to count on it never being used for some special meaning.
If we do reserve it upstream, though, then selecting a format with eglChooseConfig should work fine.
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.
Agreed, explicitly reserving 0xFFFFFFFF as a special format token in drm_fourcc.h is probably the cleanest way to resolve this. I was a bit disappointed with the prior resolution.
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.
Since the consensus is to limit this to EGLStreams, should we still consider going ahead with reserving this upstream? Or should we not bother and stick with the current "reduced/streams-focused" behavior of this extension which doesn't worry about specifying this in
eglChooseConfig()
? It seems like the later, but I figure we should explicitly decide that.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.
I still think it'd still be best to explicitly reserve 0xFFFFFFFF in drm_fourcc.h. Probably best to propose that upstream before merging this. I don't know why anyone would object, but you never know.