Getting to a GL based X server

[Adam Jackson]

On Thursday 26 May 2005 19:54, Jon Smirl wrote:
> On 5/26/05, Adam Jackson <ajax at nwnk.net> wrote:
> > On Thursday 26 May 2005 17:33, Jon Smirl wrote:
> > > No one is taking away your current server. You are free to continue
> > > using it.
> > But I'm not free to continue improving it?
>
> It's open source, you're free to print it on toilet paper if you feel
> so inclined.

So why are you excoriating anyone who suggests that maybe KAA is a good 
near-term strategy?

> > > I might point out that OpenGL-ES is a limited subset of OpenGL and it
> > > has been designed for embedded use from day one. There are several
> > > proprietary implementations including one that does not assume
> > > hardware acceleration or use floating point and fits in 100K of
> > > memory.
> >
> > And you assume this will be adequately performant for the desktop
> > because...
>
> Desktop would use current DRI drivers or proprietary stacks from
> NVidia/ATI. There can be many different OpenGL implementation running
> under the Xgl server.

You answered the wrong question.  You assume GLES will be adequately 
performant for building an X server because...

> > This is misleading; you have merely shifted the driver problem out of
> > programs/Xserver.  The drivers still need to get written.  And the list
> > of DRI drivers is far too short.
>
> It has shifted the driver driver problem onto something that is
> standardized and much more widely available than a KAA based system.
>
> It has also raised the API layer of the driver to a much higher level.
> This allows hardware to continue integrating functions. At the rate
> things are going we may have hardware that can execute all of OpenGL
> on the GPU in a few years.

Again, this is not the point.  My point is that the drivers do not exist.  
It's lovely that we have a framework in which to fill them in, but we already 
have one of those, it's called the XFree86 DDX.

> It also makes it easier on companies like Nvidia/ATI to share a common
> OpenGL code based between Windows and Linux.

Red herring.  It's already common code.

> > > Committing to the this driver model allows us to concentrate our
> > > resources instead of trying to build three or more competing models.
> >
> > I don't count three.  Do you count three?
>
> XAA, KAA, OpenGL

Okay, wrong.

Notice how you said "build" three competing models.  XAA is built.  It doesn't 
count.  KAA is basically already built, it's a matter of adding the hooks 
between the DIX and the driver in a loadable module.  And the GL model is 
also pretty much built, Xglx works, we just need to smooth the edges to make 
Xegl useful.

It's not some huge design effort, it's all corner case engineering now.  The 
only _exception_ to that is getting memory management that doesn't suck, 
which affects GL far more than it does the other two.  Again, perhaps you 
should be reaching out to new X talent.

People like Zack.

And the OEMs are not going to build four drivers.  They're going to build one.  
nVidia already ignores XAA, to their credit.  If they want to add EGL support 
it's twenty new entrypoints in their libGL and some mode setting code they 
already have.

I appreciate your concern for people producing tossing closed binary blobs 
over the wall, but they're not the ones you should be concerned about.  
They're not the ones advancing the shared core.  They're not the ones working 
on the open code everyone uses.  Those are the people that matter.

> > You've dodged the question.  Why are you even bringing up GLES in the
> > context of Xegl?
>
> Because you started off talking about chips with no acceleration
> support. Chips with no acceleration are primarily in the maket
> targeted by OpenGL-ES.

Cards with no 3D engine should not be trying to run their window system in 
terms of a software 3D engine, full stop.  So there's no question of these 
cards running Xegl.

Cards with a 3D engine but no 3D driver are the interesting case.  For these 
it's relatively easy to bootstrap KAA, but much harder to get DRI.  And once 
DRI is up, you basically get full GL for free, because that's what Mesa gives 
you.  So there's no question of these cards running GLES.

And the cards where we have drivers, have full GL.

So again.  GLES.  Is.  Not.  Relevant.

> > Let's take a concrete example.  Say I'm want to improve i128 support. 
> > Now, it has a 3D engine that's good enough for GL, so it can accelerate
> > Render no problem.  My options are:
> >
> > a) Spend a week or so on converting it to something KAA-like, then do
> > DRI; or b) Spend three months getting DRI working under XAA.
>
> You aren't thinking like a proprietary chip vendor. Chip vendors have
> to do two drivers: Windows D3D and Windows OpenGL. Everything else is
> optional.

Of course I'm not.  I don't sell chips, and I'm utterly uninterested in 
Windows.  I'm interested in making the best X servers as soon as possible, 
and I don't see how stalling everything else while Xegl bootstraps acheives 
that goal.

They're making X drivers _now_; why do you anticipate this will change?

> Nvidia already ignores DRI and simply ports their Windows OpenGL
> driver to Linux.

Actually nVidia's driver bears more resemblance to the Xsgi GL driver model 
than to anything Windows related.  The GL engine is shared code, of course.

> I'm trying to formalize this process.

It is not in X's best interests to make closed development easy.  20 years of 
history makes that lesson painfully obvious.

> The new model  
> should result in us getting more support from these vendors. It will
> be closed source but at least we will have fully functional drivers.

What in their current drivers is insufficiently functional for you?

> Don't cry about it not being open source. They aren't giving us the
> chip specs to write an open source driver anyway.

This is a major problem, that we as a community need to fix.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050526/65a4a93f/attachment.pgp>