Direct GLX, IGLX, AIGLX, DRI2 and DRISW. Which is/can do what ?

Emil Velikov emil.l.velikov at gmail.com
Fri Sep 2 16:08:44 UTC 2016


On 2 September 2016 at 16:03, Adam Jackson <ajax at nwnk.net> wrote:
> On Fri, 2016-09-02 at 11:08 +0100, Emil Velikov wrote:
>> > On 2 September 2016 at 00:10, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> > Had a feeling that the question will be confusing. Let's try dropping
>> > DRISW all together for a second.
>> >
>> > Now a silly question:
>> > IGLX encapsulates AIGLX, correct ?
>
> Indirect rendering can be either accelerated or not, correct.
>
>> > Currently the glx/dri2 code is only used when AIGLX is enabled.
>
> It's more accurate to say that only when the dri2 code is used do we
> call it accelerated.
>
>> > In your earlier work you went through the dri2 code and factored out
>> > large part of the code with ifdef IGLX.
>> >
>> > Thus in the case of having glx/dri2 without IGLX (therefore without
>> > AIGLX, right ?), there will still be some code around. When/under what
>> > conditions will that code get executed ?
>
> That series (let's call it the No Indirect Context series, or no-ictx)
> was to see what code goes away when you remove the ability to create
> indirect contexts. However, even if you can only create direct
> contexts, there is still some GLX protocol you have to handle. You need
> to be able to list visuals and fbconfigs, you need to bind to X
> drawables, etc.
>
Ack. precisely my line of thinking as well. The server-side of direct GLX.

>> glx/dri2 code contains both the direct GLX and indirect (be that
>> accelerated or not) GLX parts needed, correct ?
>> At the same time the code is compiled only when AIGLX is selected at
>> configure time.
>
> If you don't build dri2 support then only the drisw render will be used
> to back indirect contexts, yes.
>
> Now, the build system _is_ wrong.  This bit of glx/Makefile.am:
>
> ---
> if DRI2_AIGLX
> libglxdri_la_SOURCES += glxdri2.c
> endif
> ---
> ... should really be "if DRI2", and --disable-aiglx should only control
> whether an indirect context will have an accelerated renderer behind
> it. Up to now, nobody has cared much about the distinction, because you
> never don't build indirect context support (which is what the no-ictx
> series started addressing).
>
Great, so I'm not loosing it ;-)

>> Similarly at run-time - the direct GLX code cannot be reached if AIGLX
>> is disabled.
>
> It's more accurate to say: the direct GLX code cannot be reached if the
> glx core can't load a DRI driver, query its properties, and configure
> visuals and extensions to match.
>
One not that familiar with the code could assume (yet falsely) that
these (loading DRI driver, query the props) should be a separate code,
which has nothing to do with AIGLX.
Which doesn't seem to be the case, thus the current behaviour*.

>> "The direct GLX can only work when AIGLX is enabled" ... which as we
>> recall what they mean causes a FTW moment.
>
> False, for a couple of reasons.
>
> One: DRI1 drivers still exist. When you use them, you get working
> direct rendering (fsvo working), but indirect contexts are backed by
> drisw, and thus you do not have AIGLX, because you do not have A.
>
> Two, as above: that glxdri2.c is only built when --enable-aiglx is
> given is something of an error, which the no-ictx series was a start at
> fixing.
>
>> So I'm either loosing it and (accelerated) indirect GLX somehow is a
>> requirement for direct GLX to operate or there's been a bug (set of
>> bugs) for a loong time that nobody has noticed.
>
> It's a requirement, but only by accident.
>
> It _happens_ to be true that "AIGLX is enabled" implies "direct GLX is
> enabled", but only because "DRI2 is available" currently implies both.
> That's an accident of implementation. Were it possible to build a
> server that couldn't create indirect contexts but was otherwise the
> same, you would have direct GLX, but not AIGLX, because you would not
> have I.
>
Staring at the code a bit more I can see how/why things are as-is.
Although let's admit it if one does not know the particulars of the
current implementation things are quite confusing ;-)

Thanks again
Emil

* Toggle AIGLX in your conf.conf and all the sudden you loose direct GLX.


More information about the xorg-devel mailing list