[Mesa-dev] [PATCHES] surfaceless EGL: new DRI extension

[nobled]

Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Sun, Aug 29, 2010 at 1:54 PM, nobled <nobled at dreamwidth.org> wrote:
>> The current egl_dri2 code for enabling the EGL_KHR_surfaceless_*
>> extensions is a bit broken right now. First, the code in dri_util.c
>> and drisw_util.c doesn't check if it gets passed a NULL __DRIconfig*,
>> leading to segfaults when egl_dri2 does exactly that when creating a
>> surfaceless context.
>
> Which entrypoints don't check for NULL?  The DRI1 (legacy) isn't
> supposed to work with surfaceless, it just doesn't make sense.
The DRI2 one; aka the one I fixed in patch 3 "(fixes the segfaults)".
(I didn't know too much about the legacy entrypoint, so yeah, never
mind patch 4. What about the surfaceless swrast driver patches
though?)


>> But the dri2 extension's version 2 doesn't actually mean "this driver
>> can create and bind contexts without drawables"--and right now only
>> the intel drivers can.
>
> No, that is actually one of the implied features of version 2 of the
> DRI2 extension: it gives you multi-api support and surfaceless
> contexts.  We may be advertising that more than we should, and it
> looks like we should add a driDRI2v1Extension to dri_util.c for
> drivers that can't advertise v2 yet.  Of course, I should have
> documented this in dri_interface.h.
Yeah, we'd definitely need that even if surfaceless wasn't a silently
implied feature--not all the drivers even pay attention to the gl_api
parameter at all and just create an OpenGL context anyway.

Thing is, surfaceless and multi-api functionality are completely
orthogonal though--IMO it makes more sense to have them split, because
then they can be implemented separately without unnecessary
entanglement-- a) surfaceless support can be added to swrast drivers
too, and b) all the drivers that currently implement
createContextForAPI right now can still do that, even if they don't
have surfaceless support.

>> There should be a new extension to advertise
>> that capability, like the __DRI_READ_DRAWABLE extension.*
>>
>> This patch series a) adds an extension for just that:
>> __DRI_NO_DRAWABLE, b) advertises it in the intel driver, and c)
>> implements it in swrast and all gallium drivers through st/dri.
>>
>> http://github.com/nobled/mesa/commits/surfaceless
>> 1. dri_interface.h: Add __DRI_NO_DRAWABLE extension
>> 2. egl_dri2: Require __DRI_NO_DRAWABLE extension for surfaceless EGL
>> 3. dri: Really enable EGL_KHR_surfaceless_* extensions in dri2 (fixes
>> the segfaults)
>> 4. dri: Enable surfaceless extensions on DRI legacy
>> 5. dri: Provide __DRI_NO_DRAWABLE extension in dri_util
>> 6. intel: Advertise __DRI_NO_DRAWABLE extension
>> 7. dri: Allow EGL_KHR_surfaceless_* in software drivers
>> 8. dri: Provide __DRI_NO_DRAWABLE extension in drisw_util
>> 9. swrast: Implement __DRI_NO_DRAWABLE extension (this patch I'm least
>> sure of; review?)
>> 10. st/dri: Implement __DRI_NO_DRAWABLE extension (builds on Chia-I
>> Wu's 41c095bf31cedf4f463e315e8dbad8a007985464 patch)
>>
>> *BTW, what exactly does __DRI_READ_DRAWABLE require/do? Only GLX's
>> dri1 code checks it, to enable "GLX_SGI_make_current_read" (which
>> dri2_glx enables unconditionally), and it's in all the hardware
>> drivers but not in the swrast driver for some reason.
>
> __DRI_READ_DRAWALBE is only useful for DRI1 drivers, where support for
> GLX_SGI_make_current_read is optional.  If you're a DRI2 driver,
> support for __DRI_READ_DRAWABLE is implied (similar to how
> __DRI_NO_DRAWABLE is implied for DRI2v2).
But what does the driver need to do in order to advertise it? IE can
it be added to the swrast drivers as-is, and would it make sense for
GLX to start enabling make_current_read in software rendering based on
that? (I'm kind of curious if this is part of what's keeping Compiz
from working.)