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

[Kristian Høgsberg]

On Mon, Aug 30, 2010 at 4:35 PM, nobled <nobled at dreamwidth.org> wrote:
> 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?)

Doesn't segfault here.  Taking the address of config->modes doesn't
segfault when config is NULL, but it may have segfaulted in a DRI
driver that wasn't prepared to handle a NULL config.  It is confusing,
of course, and I'll apply the part of 0003 that changes it and fixes
the API type mismatch.

>>> 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.

Those drivers only advertise API_OPENGL, so the loader shouldn't be
trying to create any other context, and if it does, we catch first
thing it in dri2CreateNewContextForAPI.

> 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.

I understand, and that would be a fine solution too.  I just decided
to roll up a few features in a dri2 extension version bump so that
it's easier to check for and we avoid introducing a new extension.
Multi-api and surfaceless are both easy to add support for, they're
basically API tweaks, and adding extensions for those is too much
typing to be worth it.  The OpenGL API is evolved the same way; when a
new version comes out, it typically assimilates a number of
(unrelated) extensions into the core spec, to provide a new base level
of functionality.  That was my intention here as well, on a somewhat
smaller scale, of course.

>> __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.)

The driver needs to be able to set a different read drawable than the
draw drawable.  All DRI2 drivers can do that, swrast can do it afaik,
as for DRI1 drivers, you'll have to check them individually to see if
they support it.

Kristian