I hate Linux Graphics (Linux Hater's Blog) [LWN.net]

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 1, 2008 19:05 UTC (Tue) by drag (subscriber, #31333) [Link]

Well he is right.

Full OpenGL support is missing from the Open source drivers. The architecture of DRI is about
10 years obsolete. The idea of having all these low-level separate drivers from separate
products acting on the same piece of hardware is just fundamentally flawed. It make things
much more difficult and much more complicated then they have to be.

For example there is no way to have vertical sync work with video playback in Linux. That is
you can't have the media player refresh along with the video display. So, depending on the
display, you'll get image tearing and other artifacts. With the current design there is
nothing you can do about it. _can't_be_fixed_ End of story.

With current DRI drivers you can run compiz and a 3D application at the same time. Can't do
it. You can do it in Nvidia's X stuff all day long, no problem. Can't do it with DRI, bad
design, can't be fixed.

And Nvidia does pretty much rip your X server out and replace it with it's own mixture of
'Nvidia drivers' and some unknown amount of X.org code.

The guy is insulting, but he knows what he is talking about.

People know what needs to be done. We have DRI2, we have open specs, we have Gallium3D, and
plans designed to make drivers simplier to make, faster, and follow the modern programming
models.

DRI itself was designed when essentially hardware was 'OpenGL state machine' of sorts. Now
it's all software. The GPU is just another CPU. All new video graphics cards are going be like
that. This starting changing back when Nvidia released their Geforce 256 stuff. The DRI design
is, literally, at least 9 years obsolete and it's still being worked on.

---

This is one of those things with "Linux" that is kinda silly. The pragmatic attitude of "I'll
prefer OSS, but I will use the best tools" also means "I won't bother to improve OSS if closed
source is good enough".

Since we have closed source nvidia drivers that have worked 'good enough' nobody has really
bothered trying, until recently, to move Linux graphics out of the stone age. The X.org
license allows Nvidia to do what it does, so it does it, and customers that require 3D
graphics on Linux just pay Nvidia to do it for them.

And guess what? When people try to actually improve things and try to release fundamental
improvements they get bitched at for breaking Nvidia's frankenstein. Instead of following the
Linux kernel method of 'god damn the API, full speed ahead' when it comes to developing
drivers (and hence actually get work done).. X.org has a strong policy of backward
compatability and API/ABI stability that means that: 1. Improvements are much more difficult
then they need to be. 2. They get chewed out when they actually release those improvements.

Ironically if they actually were able to get the improvements done that need to be done nobody
in their right mind will ever, _EVER_, give a flying crap about backward compatibility when it
comes to drivers. The new stuff would actually be desirable.

Same thing with Flash. We would have very good open source flash support if it wasn't for the
fact that we have 'good enough' closed source flash support. So nothing gets done. People try
out open source flash for 2 websites, then uninstall it and install proprietary flash.

So instead of getting things fixed we all collectively deal with the PITA of installing Nvidia
and Flash, and deal with the instabilities and insecurities that come along with both of them.

-----

That's not to say that these sort of things happen without reason. There are very good reasons
why Linux has a schizophrenic driver model. All sorts of history; lack of hardware specs, lack
of workforce, the whole XFree86 organizational melt down...

I don't blame anybody or think anybody is lazy or incompetent. It's just how things are.
That's all. Stuff happens.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 1, 2008 20:10 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

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.

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 (subscriber, #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 (subscriber, #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 (subscriber, #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.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 1, 2008 20:56 UTC (Tue) by dberkholz (subscriber, #23346) [Link]

X.org has a strong policy of backward compatability and API/ABI stability that means that: 1. Improvements are much more difficult then they need to be. 2. They get chewed out when they actually release those improvements.

Sure, with the X11 protocol backwards compat is important. But the driver-server ABI has been broken with the majority of server releases since modularizing, and that's where driver improvements are relevant.

I hate Linux Graphics (Linux Hater's Blog)

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

Yes i agree with you, its a rant but that guy is mostly correct...

""" This is one of those things with "Linux" that is kinda silly. The pragmatic attitude of
"I'll prefer OSS, but I will use the best tools" also means "I won't bother to improve OSS if
closed source is good enough". """

Silly !?... notice the quoted parts!?... its a contradiction to say the least!... to be
correct it would be incredibly stupid, because it supposes that the best tools are always
open source but it would be glad to stick with an inferior but enough "closed" one if there is
no alternative!... is that what is happening ??....

So in here after almost 10 years of using Linux on the "DESKTOP" is not "Closed vs Open" that
is the matter, but "Server vs Desktop". And in here is not only the code, but a system that
could be a real superior driver model... and the will to work the best approach. GKH has done
a great job, but is strange when is the Linux "guts" that prevents the best when all the
documentation necessary are already there(at least on AMD side), and in the most important of
drivers issues... the graphic/video driver!...

Who or What is to blame after all ?

Linux started on a 386 desktop , but the Ma$ters have all been posed that it would not replace
the crap that the world is using mostly today....

First there was FUD,... then SCO... then infiltration ( i cant forget the ULTRA WINDOWS
EVANGELIST (rob enderle) on a Linux desktop conference saying: "its not ready, don't use
it")...and even more FUD after... now blame it on the "Open" metaphor!!??...

In a much more correct rant i would say: *its by design*; the Ma$ters want everybody falling
to the "carnivores" and the "echelons"... Digital Rights Fascism (DRM-to avoid Internet
propagated search of the truth)... or something much worst... so Linux had to be "fixed" and
be sticked on server land mostly... to avoid...

DRI started has a a cumbersome hack... when it started to be used it was already "obsolete" .
So i can't understand this "Closed vs Open" excuse... its misplaced, excessive... matter of
fact i'm so tired of it !... turning a good think into a weapon against itself!... it should
be "the best vs the worst"... being open or close is only peripheric to the real issue...

What is laking is *THE WILL* to pursue *the best on the Desktop*... the corporate stronghold
is not strange to this situation, but if Linux still has a lot of strength out of corporate
politics, it should go for the obvious "the best" solutions... and open a new development
project specially for GPGPUs (2.7 development tree?)... because the GPU is dead. Its going to
be all GPGPUs from now on (are already), and what makes the most sense is something like
Gallium3D or VectorLLVM.... integrated full memory management for the VRAM... other stuff!?...

BUT most probably there will be again RH saying no to Linux Desktop, and after many rants
there will a DR!2 LITE on 2.6... and the Desktop users that damn themselves!...

So that guy, the one in this thread rant, he doesn't know yet, but he doesn't Hate Linux
Graphics... what he hates are the politics that keep it forgotten and inferior and the
corporations and individuals that promote those politics... otherwise we could have been in
awe by now...

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 1, 2008 23:35 UTC (Tue) by nix (subscriber, #2304) [Link]

If 'the will' is lacking as you say, it's odd that people are working on 
Gallium3D and DRI2. It's odd that X development is zooming along as fast 
as it ever has, far faster than at any time since the late 1980s. They've 
just got a lot of historical crud to fix before the sort of massive 
changes you're suggesting can be implemented.

I mean, the ATI docs came out, what, a couple of months ago, and you want 
a working driver already? Changes are flowing into git repos, but you 
can't expect working code (and infrastructural layers! gallium and DRI2 
have been changing too) for something as complex as this in only a couple 
of months. You're hugely underestimating the complexity of the problem.

There is no conspiracy of evil devs holding back The Secret: the closest 
you had was the conspiracy of blunders in the 1990s that pushed X down the 
pathway that led to rubbish like PEX rather than anything anyone actually 
might want to use.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 15:30 UTC (Wed) by mmarq (guest, #2332) [Link]

"" If 'the will' is lacking as you say, it's odd that people are working on 
Gallium3D and DRI2. ""

Its not the will to code, but...

Where does Gallium3D and DRI2 will lead ??... how can they interoperate ??... what is the
mission statement ?? ... the possible goals ??

(making a driver that minimal works just can't be it, it must be more, because a driver is not
the goal, its only a mean to a goal )

That is the kind of *will* i mentioned... pursue the best, say no if must to a lot of
things... the *will* must have a target, even if its a flexible target and not entirely
concrete and objective( avoiding over engineering).

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 16:52 UTC (Wed) by Sutoka (guest, #43890) [Link]

Gallium3D will lead to a much better driver model for 3D graphics that actually resembles
modern graphics cards, and should make writing drivers much simplier, and not require
card-specific implementations of various APIs (like OpenGL 1/2/3, OpenVG, GPGPU, etc).

Gallium3D, DRI2, memory managers, kernel mode settings, XRANDR 1.2, Xorg auto/dynamic
configuration, XCB, etc. None of those will solve the problem on their own, none of them are
trying to. The thing is, when combined they solve a LOT of the problem of X being woefully
behind. Theres been a lot of writing by people from each of the projects about the problems
each one is trying to solve and often how they interact with each other, each of those
projects aren't being done in a vacuum completely unaware of the others.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 18:22 UTC (Wed) by drag (subscriber, #31333) [Link]

[quote]Where does Gallium3D and DRI2 will lead ??... how can they interoperate ??... what is
the
mission statement ?? ... the possible goals ??[/quote]

Well...

Gallium3D and/or DRI2 will match modern hardware design. Modern GPU and OpenGL 'acceleration'
really is just a software OpenGL stack optimized so that portions of it gets executed on your
CPU and other portions get executed on your GPU. They are also programmable, with dynamic
pipelines, dynamic memory management, and their own programming languages (aka shader
languages).

All three biggies.. Intel, ATI, and Nvidia are moving towards a 'hybrid' GPU/CPU design were
they are even more open to programming. (although with different directions... Nvidia seems to
be aiming at a proprietary software shim to separate hardware changes from software, Intel
seems to want to extend the x86 ISA to include graphics, ATI/AMD probably want to keep both
the GPU and CPU seperate and just get a standardized graphics ISA.. Not sure, I am not a
expert on this stuff) Possibly this is one of the reasons why ATI and Intel are starting to be
much more open then they have in the past. Basically, in the distant future, when you compile
a application then the GCC would be able to optimize it so that it can take advantage of the
GPU as another processor core, as a extension to the x86 ISA. Like Altivac for PPC, or how the
IBM/Sony Cell processor works, and MMX or whatever. Extra core, extra registers you can take
advantage of. Ultimately how all this works out, I don't know.

Once Linux graphics gets caught up in the driver design department it will allow X/Linux to be
competitive. Once it's competitive people will start to be able to take more advantage of it,
it will get more commercial attention, more money, more developers being paid to devote more
time to X, more help from graphic card manufacturers.

Just like the Linux kernel itself was ignored by large vendors until it got the capability of
actually being useful for heavier workloads. Then with commercial backing (think: 2.4 to 2.6
transition) they were able to match, and often surpass, any contemporary OS in terms of
flexibility and performance.

-------------------------------------------------

As far as X and normal people are concerned one of big rewards of moving to a Gallium or other
3D based acceleration API, as well as kernel level mode setting and memory management, is that
we can move X off the hardware.

You know how OpenBSD spent so much effort with privilege separation to improve security, and
all the sacrifices that went along with it? How about eliminating the need for root access at
all and still be able to keep all the graphical goodness?

... well once we get good driver model done then we can eliminate the DDX portion of X.org.
That is move X off the hardware, get it out of the business of setting up PCI devices... Once
we get X using regular generic graphic APIs, just like any other application, then that will
lead to have X running entirely under the user's user account. No need for root access. No
need for anything like that.

Imagine the usability, stability, and security improvements that we can get from Linux by
making it so that X is just another application. That we can run a GUI with no need for root
permissions. Multiple users, safer networking, easier time running and developing with
multiple versions of X. Easier virtualization etc etc etc.

When X crashes or some application takes over the display and fails, eliminating the user's
ability to interact with the machine, we won't have to worry about that screwing up any
hardware drivers and requiring the entire machine to shutdown.

Instead of having to coordinate between VGA/framebuffer drivers, DRM drivers, DDX drivers, DRI
drivers.. we can eliminate all that complexity and go with just a DRI2/Gallium3D based system
and kernel-level DRM interface. Simpler, more portable, better performing, easier to get
improvements.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 21:10 UTC (Wed) by Sutoka (guest, #43890) [Link]

Another advantage of moving the drivers out of the X server is that it'd be far easier to
completely replace Xorg. Currently if you want to write your own complete windowing system
you'd also have to deal with the very low level stuff of writing a video driver (or porting
one from X), with Gallium3D and friends you'd be able to target a generic API like OpenGL 3
(or another low level API that specializes in this sort of thing) and not have to spend close
to as much time on that hardware-specific stuff.

We probably wouldn't be saying goodbye to Xorg (or X11) anytime soon after Gallium is ready,
but just like Xegl/Xgl and other like-projects, the ideas and gained knowledge could always be
used to imporve Xorg. I'm personally quite excited about what Gallium means for the future of
the Linux desktop, it seems like the current bottleneck is Xorg, with both the Linux kernel
being quite kick ass (wrt non-graphics) and everything above X in dire need of more room to
expand.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 14:43 UTC (Wed) by renox (guest, #23785) [Link]

Content free?

No! He says that current free software driver for OpenGL sucks, which is true apparently.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 15:14 UTC (Wed) by niner (subscriber, #26151) [Link]

Just out of interest: have you tried SuSE's SaX?

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 18:42 UTC (Wed) by karlmag (subscriber, #4415) [Link]

No I haven't.
Given that the computers I admin are running Fedora it is not that likely 
I will in that context, but I probably should look a bit into it anyway.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 16:34 UTC (Wed) by drag (subscriber, #31333) [Link]

This is another one of those things that people are working on fixing. Like Gallium3D or DRI2
and moving mode setting into the kernel and such things.

The Linux kernel itself, and all the userspace daemons, have all sorts of hot-plug goodness.
If a driver is present in the Linux kernel it will:

detect the hardware
load the module
configure the hardware
create any dev files on the fly. (and this is configurable.. most of the time they use
traditional files like /dev/sda, but it can be /dev/puppykitties if you want, no symbolic
links needs)
set permissions on the fly.

It will provide notifications to userspace.
provide easy way to access hardware configurations.

We have a system bus that we can use to have 'helper' programs running with root permissions
perform tasks on behalf of users without the need for setuid root processes or gtksudo
anything like that. I should be now completely possible to avoid the whole:
"Hey everybody! We need a way to update the OS without a root account enabled... hrm... I got
a idea! Lets use gtksudo and require that users are given root permissions to thousands and
thousands of lines of C code (aka synaptic)! In their GUI! (because X protocol is sooooo
secure) Pulling in most of GTK and Gnome as dependencies, too! (more thousands of lines of C
code) With root permissions! That'll be secure!"

All of this is done on the fly. Any program can take advantage of it. Things are starting to
become sane, as far as Linux desktop usage is concerned. All the video cards, all your input
devices.. everything. All configured, and reconfigurable, on the fly.

And guess what? Until very recently X couldn't use any of it. It was in it's own little world.

Not requiring a Xorg.conf is just the first step. So that X can configure itself automatically
on start up.

Next step is allowing X to be reconfigured without having it to be restarted. Requiring that
users need to log out of X, and restart X, in order to get all their mouse buttons, or
whenever they plugin a wacom tablet or anything like that, is poo-poo. It's only one level
above Windows 98-era usability. In fact on modern machine it will probably be faster to
restart Win9x then it is to restart Gnome.

It doesn't really matter, at that point, what sort of GUI applications you have for
configuring stuff. It needs to be dynamically reconfigurable. _Then_ we can actually make
useful GUI configuration tools.

I don't know how far along they are. Everything is much easier then it used to be. For
example:

I love xrandr! That program is fantastic and it allows me to have better display hotplug
characteristics then what is possible with XP. Hopefully everything will be like that.

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 2, 2008 19:26 UTC (Wed) by karlmag (subscriber, #4415) [Link]

I am glad (and I do know) the world goes forward. At least generally.
But I also do believe this is one of the big problems for Linux vs random 
users. It is much better now than it was just a couple of years ago.
The 'simple' standard setup with monitor, keyboard and mouse works out of 
the box in most cases now. When it comes to a bit more 'exotic' setups it 
is not so easy. One would think setting up dual monitors isn't too 
difficult. It is harder than it should be, and - in my experience - it 
needs some level of manual configuration to get it right.
That doesn't scale too well when there are about 3+ dozen Linux client 
machines (out of about 400-450) with two monitors. The machines are 
usually not identical, they have different graphics cards (few 
manufacturers, but many models) and many different monitor types and 
models.
So believe me, X that configures itself is one of my wet dreams. And I 
also believe it will get there, or nearly there in time.
But I need something in the mean while.
Command line tools, so it is possible to script things. :-)

I hate Linux Graphics (Linux Hater's Blog)

Posted Jul 3, 2008 3:55 UTC (Thu) by drag (subscriber, #31333) [Link]

If you think it's complicated now, just image when you have people connecting their phones or
their notebooks to displays wirelessly. 

It's not to far into the future were when you want to watch a video or whatever on your cell
phone, you sit it on top of your television and press 'connect'.