On Wed 08 Apr 2015, Frank Henigman wrote:
On Wed, Apr 8, 2015 at 1:28 AM, Chad Versace <[email protected]> wrote:
On Tue 07 Apr 2015, Kristian Høgsberg wrote:
On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman <[email protected]>
wrote:
The name "surfaceless" suits me.
Does this platform need to provide a hint to the user about buffer
format?
Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
eglGetConfigAttrib(), returning a gbm format value. Unless we do the
same or similar here, how does the user robustly find the right format
for allocating buffers?
GBM provides
int gbm_device_is_format_supported(struct gbm_device *gbm, uint32_t
format, uint32_t usage);
and you can use that to find a format that works with
GBM_BO_USE_RENDERING.
I don't think it makes sense to use EGL_NATIVE_VISUAL_ID here, so
Kristian's suggestion sounds good to me. The EGL_NATIVE_VISUAL_ID, of
course, has the same type as the native format of
EGLNativeWindowSurface. But this platform has no EGLNativeWindowSurface,
so therefore it has no EGL_NATIVE_VISUAL_ID.
On first thought, it seems like re-purposing EGL_NATIVE_VISUAL_ID for
this platform setting it to a gbm format, might be a good idea. But
ultimately I think it's a bad idea because the platform isn't tied to
gbm in any way. Today we use gbm_bo_create() to create the dma_buf
storage, but tomorrow we might use a different API that doesn't
understand gbm formats.
That's why I said "or similar." It doesn't have to be a gbm format,
it could be a fourcc or something that the user translates to whatever
api they're using.
Am I correct in thinking the alternative is to sift through all the
gbm formats (if using gbm) to find one which satisfies
gbm_device_is_format_supported() and has the right number of alpha and
color bits? So eglChooseConfig() does nothing for us anymore? Will
we in fact have to be careful to find an egl config that exactly
matches the gbm format we choose? Or should I not be calling
eglChooseConfig() at all? I see an extension
EGL_MESA_configless_context...
Internally, this platform never uses the EGLConfig's color attributes.
So, two EGLConfigs which differ only in color attributes are effectively
identical. (It's possible that this platform never uses *any* of the
EGLConfig's attributes, but I'm not 100% sure).
Therefore it's not the EGLConfig that determines which gbm formats are
legal. Instead, it's the implementation details of the EGLImage code in
libEGL and i965_dri.so. So searching for a gbm format that matches the
EGLConfig is pointless. Instead, you need to search for gbm formats
supported by the gbm/KMS/EGLImage/GLRenderbuffer/GLTexture dance that the
gbm_bo will be used for. And I'm aware of no API to query for
those formats, unless you consider git-grep to be an API ;)
If I understand correctly, the user never needs to choose an EGLConfig
when using this platform. See lines 291 to 295 of my Chrome OS patch
[1] that ported dEQP to this platform.
[1]
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/649becd1761d377d9714af58f55ecc2b0d3821a2/media-gfx/deqp/files/targets-drm-Add-new-target-to-support-Chrome-OS-s-EGL-null-platform.patch
Surfaceless and configless - next step is egl-less. (^:
EGL-less is on its way with Vulkan and its cousins :)
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
