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

[Adam Jackson]

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.

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

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

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

Even if a no-ictx server existed, we would still need to construct the
GLX visual list somehow. Right now we do that by poking into the DRI
driver manually. Longer term, I'd like to be able to do that by
mirroring EGL configs into GLX fbconfigs (and, more generally, to
eliminate the "dri" backends and just thunk through to EGL).

> The AIGLX references in glx/drisw (both directly and indirect via
> dricommon) makes for even more head scratching moments. Although in
> all honesty these are just typos.

Yeah, that's all just mistaken.

- ajax