Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Advice about ati-drivers? [50% SOLVED]
Date: Wed, 04 Apr 2012 21:27:01
Message-Id: 20120404232346.760fe910@khamul.example.com
In Reply to: Re: [gentoo-user] Re: Advice about ati-drivers? [50% SOLVED] by Michael Hampicke
1 On Tue, 03 Apr 2012 18:37:32 +0200
2 Michael Hampicke <gentoo-user@××××.biz> wrote:
3
4 >
5 >
6 > Am 03.04.2012 17:37, schrieb Michael Mol:
7 > > On Tue, Apr 3, 2012 at 9:54 AM, Michael Hampicke
8 > > <gentoo-user@××××.biz> wrote:
9 > >>
10 > >>
11 > >> Am 03.04.2012 13:28, schrieb Nikos Chantziaras:
12 > >>> On 03/04/12 03:16, Michael Hampicke wrote:
13 > >>>>> However, now that the firmware loading problem is fixed, my
14 > >>>>> screen still goes
15 > >>>>> black on bootup. But now it's instantaneous instead of 60
16 > >>>>> seconds delayed :(
17 > >>>>>
18 > >>>>> I'm back to functioning vesa mode if I boot with
19 > >>>>> radeon.memset=0, but that's
20 > >>>>> not really my goal...yet :p
21 > >>>>
22 > >>>> Last time I reinstalled gentoo, I tried kms too (with my Radeon
23 > >>>> HD2600 card). And I had lots of problems with it - in
24 > >>>> combination with ati-drivers fglrx module (blank on boot, freeze
25 > >>>> while starting X, generell crashes and kernel panics, low
26 > >>>> performence...,...). So I finally decided not to use kms disable
27 > >>>> everything related to kms. Since then everything is running
28 > >>>> smoothly. Two weeks ago, I purchased an new video card (Radeon
29 > >>>> HD7770) and gave kms another shot. And again, everything went
30 > >>>> down the crapper. So disabled it. I can live without it for the
31 > >>>> time being. But still, I would be interested in the "why?".
32 > >>>
33 > >>> You cannot use two drivers at once. Either use the kernel driver
34 > >>> (which does KMS), or ati-drivers. You cannot mix drivers. Not
35 > >>> in Linux, and not in any other OS I'm aware of.
36 > >>>
37 > >>>
38 > >>
39 > >> Seems like there have been some changes on that subject in
40 > >> time. Keep in mind, up until a few months ago I was running
41 > >> Windows7 on my workstation. I'm not new to linux, as I've been
42 > >> using linux on servers since a very long time, but the whole X
43 > >> stuff is kinda new for me.
44 > >>
45 > >> In the past I always experimented with linux in dual boot, and I
46 > >> vaguely recall that there were (or are?) different kinds of video
47 > >> drivers on linux. You had the drivers provided by the kernel, the
48 > >> drivers of Xorg - like xf86-video-ati - and third party drivers
49 > >> like ati-drivers fglrx. And now there's kms too, which I
50 > >> understand is not a driver, but a means for the kernel to setup
51 > >> the driver itself (resolution, color depth).
52 > >>
53 > >> So, if I now use the kernels radeon driver, i could use kms, but
54 > >> cannot use xf86-video-ati or fglrx, if I use xf86-video-ati or
55 > >> fglrx, I cannot use kms?
56 > >>
57 > >> It would be great if someone could link me to some reading
58 > >> material on that subject. Something that explains, the difference
59 > >> between kernel video drivers, framebuffer console, Xorg video
60 > >> drivers and 3rd party drivers.
61 > >>
62 > >
63 > > Just noticed this, and thought of you and this thread:
64 > >
65 > > https://www.osadl.org/Single-View.111+M5afc75f7e68.0.html
66 > >
67 > > Also, if you really want to be able to dig in and do interesting
68 > > things without the aid of GNOME, KDE or XFCE, I highly recommend X
69 > > Power Tools. The book predates KMS, but then so will anything
70 > > resembling a thorough treatment.
71 > >
72 > > http://shop.oreilly.com/product/9780596101954.do
73 > >
74 > > But a quick rundown regarding the difference between kernel video
75 > > drivers, framebuffer, Xorg and 3rd-party drivers:
76 > >
77 > > There are two halves to the story. The kernel and userland. Both
78 > > sides have their own halves of drivers for whatever functionality
79 > > you need.
80 > >
81 > > Kernel:
82 > >
83 > > 1) Console drivers. These typically access the video adapter's
84 > > built-in text display mode. They don't provide for graphics outside
85 > > the glyphs built into the video cards. These are typically
86 > > *incredibly* fast for text-mode usage, in comparison to framebuffer
87 > > drivers. Enough that if you don't silence build output, you can
88 > > measure differences in compile times of a large program that come
89 > > from the compiler waiting to flush its stdout stream buffer.
90 > >
91 > > 2) Framebuffer drivers. These are simple drivers taking advantage of
92 > > basic raster graphics capabilities in the video adapter. The kernel
93 > > framebuffer drivers treat the display as a giant image, and draw
94 > > text glyphs and other graphics onto them.
95 > >
96 > > 3) Direct Rendering Management (DRM) drivers. These have
97 > > traditionally been how X has been allowed low-level access to 3D
98 > > graphics accelerators. (I'm simplifying here a bit). The DRM
99 > > subsystem has undergone at least two major revisions. It's also
100 > > specific to Linux, and isn't available (AFAIK) on other systems
101 > > which can run X. DRM in this context has nothing to do with
102 > > 'Digital Rights Management'.
103 > >
104 > > 4) Kernel Mode Setting (KMS). Historically, once X launched, X used
105 > > its own hardware drivers (unless you had it talk to a kernel
106 > > framebuffer driver) to talk to video devices. Once X started, the
107 > > kernel gave control over graphics hardware to X, and depended on X
108 > > to hand it back if you wanted to switch to a virtual terminal for a
109 > > plain console. That meant that if X crashed, your video setup was
110 > > left pretty much in complete disarray, and you had to use a SysRq
111 > > sequence to get it back. (I swear, I'll need to add that to my
112 > > email signature before I'll remember it...) KMS is supposed to keep
113 > > that responsibility with the kernel, with the kernel telling the
114 > > video adapter which display modes to use.
115 > >
116 > > 3rd-party drivers from AMD and NVidia have generally hung out in the
117 > > DRM area. I don't know if either AMD or NVidia have been adding
118 > > support for KMS to their drivers.
119 > >
120 > > And that's just the kernel side of the story. The userland side
121 > > mostly involves extensions to the X protocol. The big ones you
122 > > should care about are the Xv extension and the GLX extension.
123 > >
124 > > The Xv extension is used for basic acceleration of 2D operations,
125 > > especially blitting and stretching of images. That's particularly
126 > > useful in video playback. The Xv extension needs to be implemented
127 > > by the X11 half of the video drivers.
128 > >
129 > > The GLX extension implements OpenGL (more correctly,
130 > > OpenGL-like...there's a trademark thing going on there, but it's
131 > > more a legal thing than a technical thing.) for X11, giving X
132 > > applications access to standard definitions and methods for
133 > > manipulating 3D primitives like textures, meshes, polygons,
134 > > viewpoints, lighting. Some time in the last decase, on-GPU programs
135 > > called pixel shaders and vertex shaders also became available.
136 > > (This have more recently been generalized, which is what's driving
137 > > the whole thing behind CUDA and OpenCL.)
138 > >
139 >
140 > Thank you for your little tour around the kernel- and userspace-side
141 > of video drivers and protocols. I think now I have a general idea on
142 > what's going on, and what does what. But I'm gonna investigate this
143 > further the next time a have a bit freetime. I guess there are some
144 > pretty interesting storries in this area.
145 >
146
147 Here's a tip for when you go down that rabbit hole (and yes, there
148 really is a wonderland at the other end):
149
150 Don't let your prior knowledge of Windows stuff taint your headspace
151 about graphics systems. Windows and X11 on Linux are so vastly different
152 there's almost no common knowledge that they share. True, the hardware
153 is the same and you still put the same data in it to light up pixels,
154 but that's about where the similarity ends.
155
156
157 --
158 Alan McKinnnon
159 alan.mckinnon@×××××.com