Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Getting rid of the bits of architecture Intel didn't design

Posted Apr 25, 2009 23:23 UTC (Sat) by jensend (guest, #1385)
Parent article: Packard on the state of Linux graphics

I'm not on top of all the details, but it seems to me that Intel has dominated the decision-making, and in some of these areas I wonder whether the architecture is too specific to their needs (last year's GEM v TTM article discussed this a little). I wish other vendors could be brought on board in a more meaningful way- even the fglrx and nvidia closed driver teams could make some contributions to building a better infrastructure. I also wonder to what extent some of this is making other Unices into second-class citizens or worse.

(Log in to post comments)

Posted Apr 26, 2009 3:07 UTC (Sun) by drag (subscriber, #31333) [Link]

Well....

There are two areas that the 'next gen' driver model can be ported to other operating systems..

1. The other OS can choose to impliment support for the DRI2 protocol and do kernel-level memory management that provides support for GEM-like objects. Then take care of mode setting in some way that doesn't depend on X DDX drivers (since that is hopefully going away in the long-term. About 50% of the code for X.org drivers is just to deal with mode setting.)

2. The other OS can target Gallium directly and create their own 'winsys' portion of the driver. (or whatever they now call the bottom layer of the Gallium design stack)

The bonuses that come with the new unified driver design is better memory management and much simplier driver model. Also for security it makes it possible to allow Xfree-style X server to run as a regular user.

I think that FreeBSD already has some support for DRI2 somewere with their own memory management scheme and OpenBSD folks should be interested in allowing users to get hardware acceleration without compromising security.

Windows and OS X could be taken care of by porting Gallium to their native acceleration APIs and get compatibility with the Linux-style display stack.

-------

All in all this sort of thing is just a plain better design long-term.

Remember that with Windows Vista one of their big deals was to impliment a in-kernel video memory management system and shove the rest of the driver back into userspace.

Also according to ATI's proprietary drivers developers they have already moved to this sort of driver model, internal to the driver, some time ago. (For Windows and then later on for Linux) And, I expect, the same for Nvidia proprietary driver prior to ATI's.

In this way Linux open source graphics is just catching up with the rest of the world and this sort of model is going to be required to take better advantage of things like Intel Larrabee, the ATI GPGPU stuff, as well as OpenCT and manageable hardware acceleration for video decoding. (although I think that Linux's OSS graphics stack has such wonderful potentional since it's using a open and standardized approach.. were as with things like Nvidia's CUDA is very vendor, very hardware specific.)

Getting rid of the bits of architecture Intel didn't design

Posted Apr 26, 2009 16:59 UTC (Sun) by wilreichert (subscriber, #17680) [Link]

Intel is driving the decisions here because they're the ones paying salary to xorg developers. Sure AMD is releasing hardware specs, but how many full time open source xorg develpers have they hired to work on their hardware support? None that I'm aware of, its the distros like Redhat & SUSE doing it for them. That said, I think the Intel paid developers are considering the needs of the other video cards when these APIs are created, no one will benefit if this stuff only works on one brand of card.

Getting rid of the bits of architecture Intel didn't design

Posted Apr 27, 2009 4:01 UTC (Mon) by airlied (subscriber, #9104) [Link]

that would be 3 full-time AMD open source developers.

They are mainly concentrating on getting initial working 3D code for the current batch of chips at least useable before going ahead with getting the other bits.

Getting rid of the bits of architecture Intel didn't design

Posted Apr 27, 2009 4:36 UTC (Mon) by wilreichert (subscriber, #17680) [Link]

Excellent, I'm thrilled to be wrong here. Perhaps its a problem of perception then - one doesn't see too many @amd.com emails on the xorg / mesa mailing lists.