DRI For 2D Graphics?

Dan Farrell asks: "I know that we have DRI working good for 3D direct rendering. But DRI is quite a good infrastructure, why aren't we using it for 2D graphics as well? It seems to me that all of the complaints about X would disapprear if we got the Render extention finished, and used DRI to directly render everything(and maybe made X multithreaded and had it automatically re-nice itself... but that is me being greedy). I guess what I want to know is why we aren't using DRI for 2D graphics and video?"

Comments

An interesting statement about priorities

[Mossfoot]

After all, what do most people appear to demand in the computer market? Top notch 3D graphics. State-of-the-art this-and-that. So something that is old school, like, say, television on the PC, is not addressed.

Is this because it's concidered somehow 'passe', or could it simply be that people assume there isn't anything to fix?

It seems that we keep pushing to expand the bounderies of technology, without concidering that there is older stuff that can use a tweek now and then. So who's fault is that?

DRI is only for local use.

[ooze]

You need a fitting kernel module for your xserver driver, so it will be hard to export DISPLAY to another xserver. With 3D applications as Q3 this is not that important as only few people would like to redirect the screen with all implied fps hit. But being able to export DISPLAY is one of the best and most integrated features of X and shouldn't be dumped.

Re:DRI is only for local use.

[ksheff]

Not necessarily. X is smart enough to know what tricks to enable when the display is on the local machine. For example, for a local display, all the X protocol traffic is being done via shared memory instead of the TCP/IP protocol stack. Several years ago this wasn't the case and one had to explicitly set the $DISPLAY variable to enable it.

I don't know much about the specifics of DRI, but if it's like what SGI did w/ GLX, they you should still be able to export the display to another machine and get some hardware assisted rendering. IIRC, the GLX extension would send the 3D information over the network to an X server capable of handling it. The server would pass it off the the gl layer that SGI built whether it was totally in software for the lowend machines or one of their massive multicard 3D units (or at least that how I remember it from the gl class I took at SGI several years ago). Yet another X extension that the server has to advertise. If an application needs this capability, it will have to query the server when it starts up and fall back to another rendering method or just complain to the user and exit. Sure it's not going to be as fast since it has to go over the network, but it is better than trying to do 3D w/ the plain X protocol.

Re:DRI is only for local use.

[ooze]

11.2. GLX
The GLX 1.3 API is exported but none of the new 1.3 functions are operational.
The new glXGetProcAddressARB function is fully supported.
GLXPixmap rendering is only supported for indirect rendering contexts. This is a common OpenGL limitation. Attempting to use a direct rendering context with a GLXPixmap will result in an X protocol error.
p> From the XFree86 Documentation The DRI is to circumvent the X protocol for higher performance and glx does the same up to an certain degree.
It would need changes to the X well defined X-protocol to implement this. And I'm not that firm with this, but I think the X-protocol opcode has only 8bit. A 3D implementation definitely will need more operations.

Re:DRI is only for local use.

[ksheff]

It would need changes to the X well defined X-protocol to implement this

But isn't that what an extension is? I'm not that worried about it right now. Let the XFree people get any of the kinks out of DRI for local use first and then remote displays sometime later.

the problem is in the implementation

[pixel fairy]

outside of irix very few gl drivers are fast at all with 2d, and this includes "workstations" (the HP visualize comes to mind). there are a few cards available for windows that accelerate 2d GL calls like the firegl but for most part GL 2d is much slower than the usuall X11 or whatever windowing systems calls.

we need to get more card manufactureres/driver writers to pay attention to 2d stuff, especially since none of the high end hardware available for linux has open source drivers. sgi,hp,firegl etc all closed source. atis radeon seems to be the best bet we have for source.

Not necessary

[drix]

I'm not sure exactly why you would want to do that. I know some people have quibbled about the fullscreen-only nature of XFree86-DGA and hence looked to DRI, but in most every case there is no point. There isn't any throughput bottleneck for 2D graphics assuming you're using an accelerated driver. Any good video card on the market today approaches the theoretical maximum for 2D performance anyways; that's why OEMs actually marketed their 2D performance 5-6 years ago whereas today it's ignored in favor of 3D acceleration marketese... they all perform the same. The one possible 2D bottleneck is obviously video (especially fullscreen) however that is now handled nicely via through the XVideo extension. Driver support for Xv is not universal but fairly widespread. I'm able to play fullscreen video from a realtime-decompressed DivX stream on my Celeron 400 with no frame drops and .8 processor load using YUV overlays and hardware scaling. There's not much more you can do to make it go faster. I don't think there's really a need for further 2D acceleration.

--

Re:Not necessary

[mbyte]

NO !

I have a P3-500 and a Matrox G400 with Xfree 4.0.2, one of the fastest combinations for 2-D around. (see the X11 xstones benchmark page)

Ok. raw FVWM speed is great, but who want's that ?

If you ever use some X11 apps that are a bit more graphics intensive you would know that those apps are quite slow in X.
I.e. Why can't I have 4 different hi-res backgrounds .. vid-card has 32 megs of ram, enough to store them all .. but regardless of the software you use, when you switch desktops, its slow !

For the record just try the X11 version of mozilla and compare it to the same win32 version ... you will notice that the win32 one will run MUCH smoother !

Re:Not necessary

[RossyB]

Mozilla being slower in X has nothing to do with drivers... it's Mozilla. In fact it was only recently (M17? M18?) that a fix was checked in to the tree for Linux which speeded up Mozilla no end. The bug was that the caches in X were being cleared for every drawing operation...

There is still lots of work to do on Mozilla, and 0.8 was visibly faster than 0.7.