LWN.net Logo

I hate Linux Graphics (Linux Hater's Blog)

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 1, 2008 20:10 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: I hate Linux Graphics (Linux Hater's Blog) by drag
Parent article: I hate Linux Graphics (Linux Hater's Blog)

Hmmm...

I can't agree about 10 years obsolete. 1998 was a long time ago. Back then it was still
considered completely reasonable for your 3D graphics solution to be a loopback overlay hack,
separate PCI card and everything. Certainly the "full circle" trick of executing OpenGL code
in a window, rendering that window onto the desktop, and then rendering the desktop as a GL
texture onto a moving surface couldn't be done, the hardware just didn't support that (not
talking about what SGI could do, although I don't remember ever seeing this trick done with
1998 era IRIX, but what PC hardware XFree86 was built for could do)

Part of the purpose of DRI is actually to /avoid/ "all these low-level separate drivers".
There's only one piece of code for managing the Radeon's microcode, one piece of code for
controlling its DMA transfers etc. The X server, and the GL application are sharing the
hardware through the DRI code, just as my web browser and my compiler are sharing the hard
disk through the VFS code. Whether the line was drawn in exactly the right places is up for
question. Evidently Microsoft didn't think they'd done a good job of drawing this line prior
to Vista either...

There's nothing you can do about the fact that "vertical sync" is useless outside of some
simple scenarios. In a video production environment you can decide, de facto that you are only
going to handle those scenarios and anything exceptional will be handled "out of house" by a
specialist agency. Home users can't send off the AVI they downloaded from Something Awful to
an agency to have it converted to their LCD panel's native frequency.

If you're content to do fullscreen playback to a single output, which is the same sort of
simple scenario I talked about, then yes, you can have vertical sync, but I won't guarantee
that the interaction between the output's native frequency and the video you're playing will
be acceptable, some people are more sensitive to the resulting "uneven" playback than others.

I can't say that I do just install the nVidia drivers BTW, they likely wouldn't work on this
Z60m anyway since it has no nVidia hardware, and my experience has been that I can actually
investigate and sometimes fix bugs in the Free drivers, whether that be the Radeon driver from
airlied and co or the Nouveau driver on my other machine.

There has historically been too much NIH syndrome around graphics. But not just on Linux. It's
everywhere. While people seem only too happy to re-use someone else's XML parsing code, or
even scanner drivers, something about graphics makes people want to design everything from
scratch and then, when they learn a few of the things X coders learned twenty years ago, they
design it again, and again, and we have probably twice as many people working on Free Software
graphics as would be needed for state of the art OpenGL support. But they'd rather die than
work together.

Even nVidia's history illustrates this. In its formative years nVidia desperately wanted to
use quads instead of triangles. Almost everybody else had long accepted that quads were
hopeless. No-one was writing software for quads. But NIH syndrome kicked in, nVidia committed
to quad rendering almost to spite people rather than out of expectation that it would actually
be better. And they produced the NV2 that no-one remembers or cares about any more.


(Log in to post comments)

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 1, 2008 23:08 UTC (Tue) by mmarq (guest, #2332) [Link]

"" There has historically been too much NIH syndrome around graphics. But not just on Linux.
It's everywhere. While people seem only too happy to re-use someone else's XML parsing code,
or even scanner drivers, something about graphics makes people want to design everything from
scratch and then, when they learn a few of the things X coders learned twenty years ago, they
design it again, and again, and we have probably twice as many people working on Free Software
graphics as would be needed for state of the art OpenGL support. But they'd rather die than
work together. ""

What a hell of an argument!?...

I believe that "maybe" a fact, because the graphic arena was already too fragmented to start
with, and there wasn't any real superior initiative, and so lot of people felt they had a
chance...

Do nothing and blame it on history... or even consider those that would die for their NIH
acute syndromes... well its just!...

When some of the perceived standards improve *A LOT* around the all graphic matter, not only
or exclusively mean F**k legacy for a while... but a very strong WILL for a perceived superior
system or model... that will provide miracle cures i'm sure...

But this will chock frontally with the major distros i'm afraid, always searching for
differential points worth of marketing value. IMO its not individuals, but the principal
distros that are more responsible ( if they had the "WILL" to came together on this issue, the
problem had been solved long ago ) for the caos... its a vicious cycle, that only breaks when
a superior Kernel GPGPU lair ( GPGPUs provide a great chance)... then a superior GPGPU
programing environment( like GGC org), of which MESA will be only a minor peripheric part...
then a superior theme extensible engine...

My main point is that only a clearly perceived superior system or model for graphics will
solve the problem( Gallium3D VectorLLVM). Political or administrative choices will only
aggravate the issue.So i believe GPGPUs will provide a great opportunity. 

For the GPGPUs, there is only this 3 things considering that X is maintained and cleaned of
***ALL*** needless driver bagage.
1- kernel lair
2- a prgramable environment
3- A COMMON extensible and superior theme engine 

Then the NIH will be pushed out for only the top of stack and peripheric issues. Matter of
fact some of that NIH and creativity will be well come.

Its the boldness of choice then, and the will to maintain it, that will make a lot of people
to converge. Its not that clearly the key of success of major FOSS projects, including the
Linux Kernel ?   

Huh?

Posted Jul 3, 2008 5:54 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

I read your post twice and for the life of me, I can't figure out what you're trying to say.

Huh?

Posted Jul 3, 2008 17:27 UTC (Thu) by lysse (guest, #3190) [Link]

Don't worry - that's pretty much par for the course with mmarq's posts.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 0:52 UTC (Wed) by paulj (subscriber, #341) [Link]

Hmm.. The O2 demo software included things like video mapped onto rotating cubes...

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 3:17 UTC (Wed) by jamesh (subscriber, #1159) [Link]

I think the parent poster was referring to rendering other application's pixels as textures
onto a 3D model, as you might see when running a media player and using Compiz's cube desktop
switcher.

Is that what the O2 demo was doing, or was it just a single application using frames of a
video as textures?

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 6, 2008 18:13 UTC (Sun) by kbob (guest, #1770) [Link]

Each of the O2 demos was a single process, as I recall.  Some of them were groups of earlier
demos glommed together, e.g., onto different cube faces, but they were recompiled into a
single executable.

They just demonstrated what the hardware could do.  That's why they were called demos.

1990s SGI

Posted Jul 6, 2008 18:08 UTC (Sun) by kbob (guest, #1770) [Link]

Yes, the O2 had a unified memory model.  2D, 3D, the video decompressor, and video inputs all
wrote to pbuffers, pbuffers were used as texture inputs, and one pbuffer was fed to each video
output DAC.  It allowed things to be plumbed any which way.

SGI's higher end graphics systems at the time, Impact and Reality Engine 2, were optimized to
render directly to the screen, but could also render to pbuffers.  They also didn't have the
video inputs by default.

Yes, I worked on O2, though not on the graphics subsystems.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds