Slashdot Mirror

Please note that I do agree that X is too slow. But analysis of keithp and others have shown that this problem is caused by the inefficient implementation that doesn't care enough for latency, and not by the networking code.

Does the Direct Rendering Manager support help this issue? APIs such as drmGetInterruptFromBusID seem to be a good sign.

Writing pixels directly to a frame-buffer is slow. You lose all of the acceleration features of your video card. Keeping as much of the protocol at a high level as possible is good. The only things that benefit from direct frame-buffer access are programs that do all their own rendering. (Think video decoders.)

Still, if you think about it, the basic gist of your idea is to get rid of the network channel from the communication protocol, and instead have the app talk directly to the X server, say, in shared memory. If so, then how does your idea compare to MITSHM and Shared-Memory Transport? Or the Direct Rendering Interface for that matter? And for 2-D stuff, let's not forget the Direct Graphics Architecture extension. Nothing stops GTK, Qt and friends from using any one of these technologies if they'd improve performance and latency.

Compare these 2 web pages:

Precision Insight Team
Tungsten Graphics Team

Aaah yes, the old shared memory transport thing in X. It's not the panacea you make it out to be - far from being inefficient, unix domain sockets are actually not significantly slower than a shared memory transport in a modern PC system. In Linux at least, the unix domain socket code is some of the most heavily hand-optimized code there is - it just doesn't get any faster.

As for an SHM transport never having been implemented in XFree86, no, it has, but the improvement in speed was so negligible that it is not compiled in by default.

Check out Precision Insight's paper on a shared-memory transport in XFree86 and please would everybody stop moaning about how crap XFree86 is - it isn't. BTW your alpha channels and font anti-aliasing are coming soon :p

There was a press release that Precision Insight will do DRI drivers for G400 (most probably under the GPL), and they promised them for this summer.
Wonder what happened to them.

I really hate to point this out but there was a benchmark at Linux Games that shows Windows beating Linux in 3d accelaration with several different cards. Personally I think this has a lot to do with X.

You're absolutely right - it has a lot to do with X. MS Windows programs running on local windows machines have direct access to the graphics hardware. DirectX / OpenGL libraries have direct memory mapped interfaces with your graphics card.

When a traditional (indirect) OpenGL 3D game runs on X (via the GLX extensions) it undergoes translation to X window calls, X protocol encode and gets queued to the X server at which point (in a very basic not-at-all-aware-of-what-happens program) we block - stall completely. We wait for a context switch to the X server before doing a protocol decode and finally transferring the graphics request to hardware. Lastly we have to wait for another context switch before we can carry on with whatever processing we were gonna do. At the minute GLX is (almost) entirely based on this scheme.

Perhaps the largest XFree86 development project at the minute is Precision Insight's Direct Rendering Infrastructure. This will give X a similar mechanism to Windows for accessing 3D hardware. See Precision Insight's Design Docs or SGI's take on how graphics hardware should be accessed. Youll see that for the particular case that people whinge about (why can't local programs just have local hardware access?) this is precisely what is needed.

Even more remarkable is that the DRI retains all the network transparency assosciated with X for indirect rendering; using direct rendering when available on the local machine. Im not to sure of the framerate you'd get if you ran 3D games over PCAnywhere; or whether itd be worthy of the title 'framerate'.

Book PC's Intel 810i Video support under Linux or XFCom Intel 810i drivers

BookPC's Davicom LAN support under Linux

Here is someone selling it with RedHat:

TWINSON COMPUTER SERVICES - Book PC

I can't find anything on the PCNet Winmodem... not that drivers are likely outside of Win9x.

Hidden Methods: The Good and the Bad

3D vendors believe that if they were to release all of their intellectual property in open source form that a new competitor would immediately use that IP as the basis of its own future products, without having to have incurred the high cost of development. The underlying technology does not become obsolete as it does with so many other computer technologies. This belief is the primary reason 3D vendors, from the application level down to the device driver level, reject requests to open the source code or specifications to their products. Each vendor has developed its own unique approach and long term plan for its own ongoing 3D development. The unique longevity of 3D technology and the high cost of entry requires a different approach by 3D vendors in the open source market.

To solve the problem you must understand the problem.

theron

I Have the G400 MAX, its run really nicely under Debian 2.1 for a while now. Xfree4.0 will support it, as soon as Precision Insight release their drivers for it RSN. There are Linux clocking utils for these and all the info you need is on matroxusers.com I'm a satisfied user! :)

and

Precision Insight has expressed its intent to release source. I think we should give them a chance to make good on their promise.

I'm the primary author for the 3dfx drivers. I'd love to have more people help with them. That's why we setup dri.sourceforge.net. That's got the current 3dfx drivers, and will include all the drivers from Precision Insight including the Matrox and ATI drivers.

- |Daryll

Hell, I think the X video driver that whoever wrote for the Neomagic...

I think we can thank Frank LaMonica (and others) from Precision Insight

PI's web site. Here's a rundown from one of their graphics It lists several different paths through the X system that can be programmed for.

3D Direct Rendering

-Raw OpenGL compat Rendering Library -> Hardware
-GLX/DRI -> Kernel Module -> Hardware
-XLib -> X Transport -> X Server -> Hardware

X11 2D (Normal X)

-XLib -> X Transport -> X Server -> Hardware

3D Indirect Rendering

GXLib -> X Transport -> X server -> Hardware
XLib -> X Transport -> X Server -> Hardware

So while, yes 2D is done the same old way, There are many new 3D options available, including bare wire access to the hardware.

Two items on the NT video subsystem:

Note that one of NT's major sources of instabilities is in its video drivers. Any wrong call inside the driver can and does blue screen the box. With X's user-space model, this can't happen easily. There is a trade off on performance, but with X you get stability, multiple screens, and native network windowing, with the tradeoff being in having to use an asynchronous display instead of a synchronous display. (Displaying graphics synchronously gives faster graphics at the expense of CPU)

Also note that DRI is essentially an improved version of SGI's GLX implementation on Irix (SGI's version of Unix), which ABSOLUTELY SMOKES 3D rendering on NT, on neo-equivalent boxes. If you've never seen 3D done on a SGI O2 or better, you haven't seen good 3D. X isn't such a dog then... :)

jf

You are right, the buzzword to watch for in case of X is DRI.

See this diagramm for what to expect. (There is also a less detailed and a poster sized version in the parent directory).

XFree86 4.0 will have Precision Insight's Direct Rendering Interface which will bring Linux 3D framerates on par with Windows. Precision Insight has even hired Mesa's Brian Paul to bring his experience to the project. The day is coming when Linux will achieve gaming parity with Windows...

Experience has shown us that once a hardware manufacturer sees the positive response they receive from the Linux community when support for their hardware is available, they will ultimately agree to allow the release of the driver source code.

> Let's, um, NOT go to their website.
>
> Let's call them and bug the hell out of them. My feeling is that if, by the end of the day, this
> poor woman (I'm sorry!) hears about a couple thousand anguished but polite pleas for Linux
> drivers, her superiors are going to hear about it.

NO! Get a clue, people. This is not the right way to influence vendors - and I speak as an engineer who does OpenGL driver work at a major graphics vendor.

Read Frank LaMonica's paper on this exact topic. Do what it says. And stop harassing innocent people who are telling you the right channels to make your interest known.

GLX is not a replacement for Mesa; GLX is what connects OpenGL (or Mesa) with the X server. In the near future, GLX and Mesa will be hooked up into XFree86, giving a full software renderer.

Precision Insight is also working on enhancements to GLX which will be the
basis for a hardware driver kit that can be used to build drivers for specific boards.