Mesa & Xorg Chat (uClibc mostly)

Kevin Day thekevinday at
Mon Jul 3 14:46:06 PDT 2006

I have had some success with getting Xorg + Mesa up and running under
So here is a list of the topics, in order, of which I will discuss my
3) TLS
4) Mesa 6.5
5) Mesa 6.4.2
6) Xorg Y.Z - Serious Issues
7) VIA & SIS Drivers
8) ASM in DRI
9) GCC's 3.4.6 / 4.1.1

===== NO TEXREL =====
The Mesa team has consitently faught against implimenting security in their
drivers due to the fact they they claim it will make things "slower".
So, After using the NO_TEXREL patch, which I believe I sent to hlfs, I was
able to test both case.
Either case, with and without the NO_TEXREL patch, mesa performed the exact
same way in both cases, not even the slightest difference in glxgears fps.
So, we can safely add NO_TEXREL's to Mesa, without any performance loss.
Afterall, I proved it, by doing it.

===== XGL / XGLX =====
I have both enabled/disabled XGLX and tested performance in both cases.
I have seen no apparent differneces in both performance feel nor in glxgears
So it seems rather safe to add when using Mesa 6.5.
However, you cannot add this in Mesa 6.4.2, so if you wish for Mesa
Stability in accordance to developmental status,  then don't enable XGL/XGLX
in xorg-server.
You must alsot have xorg-server 1.1.0 or higher for this to work.

===== TLS =====
I ran into a problem where I did not enable TLS in Mesa (which is default in
linux-dri/linux-dri-x86), but i did pass --enable-glx-tls to xorg-server.
Xorg server has a problem in  that it fails to check whether or not TLS is
actually available in xorg, so when TLS is disable, xorg still compiles and
install successfully.
This will reveal a problem discussed in (6: Xorg Y.Z - Serious Issues).

===== Mesa 6.5 =====
This is required for using XGL and XGLX
use of XEGL and XEGLX is currently risky and unsafe due to developmental
status. (you may get lucky however)
This is considered a developmental version, and may relate to some speed
problems I am having.
My Speed problems are as follows:
  glxgears (with 3d accel) performs 200fps faster than it did under glibc, I
have compared this to one of my ancient LFS 5.1.1 systems.  But to compare
it against something new i tried ubuntu.  Finish Report Here on Ubuntu FPS
  It is so much better that my video card seems to be used less often and
still perform well.
  Unforunately, the 3d accel is in fact broken under this system.
  When I create multiple xterms and move them around to generate more video
card usage, it begins to use more video card, in a recursive manner.
  This is extremely bad as the more I move the xterm around, the faster and
faster my FPS drops.  my Radeon 7500 goess from 1200fps to 600fps from
moving xterms around in a circular pattern with at least on other window on
the screen behind the xterm. (in this case another xterm and glxgears
running on it)
  For the second test, I ran a dvd.  Not good, my FPS dropped to 300fps.
  This happens irregardless of whether or not I have the NO_TEXREL patch.

===== Mesa 6.4.2 =====
I am currently working on this to see if any of the performance problems
noticed in the Mesa 6.5 compiled system vanish.
I will report on any findings as soon as I get them.

===== Xorg Y.Z - Serious Issues =====
Okay, so I have found the one and only (at least only one I have ever found)
reason why Xorg Locks your screen on startup.
Dynamic Linking.
There are two possible ways Xorg could fix problems as a result of this,
neither of which are used.
In fact, Xorg does absouletely nothing about it, and does even put it into
the Xorg.0.log, thus resulting in a blank screen without any logs
whatsoever.  The error gets put to the screen, the screen is unreadable and
the machine must be rebooted.
1) Load the shared objects prior to switching the screen.
2) Treat Dynamic Linker errors as critical instead of ignoring them, exit
the server, and return the screen back to the Linux OS (aka Frame Buffer)
However, both the Xorg team and Mesa team does not care about systems other
than their own (check out the buzilla and find out for yourself) (deviation
== ignored && hlfs == deviation).
As they are not likely to fix it, I have found a simple way to work around
the serious bug at hand.
We need a way to grab all things sent to stdout and stderr and save it
before Xorg butchers our monitor's ability to produce light.
"startx &> /log" with /log being some writeable location/file that you can
easily find later.
Once you reboot, read the last line on the log file, and figure out what
function, variable, or other symbol that failed to be found or loaded.
Once that happens, it is time to go into the source, grab a battle-axe, and
lay waste to their code.
But seriously I have a couple of patches attached that will go around a
couple of such issues.
P.S. The reason why I used Y.Z in their is that this seems to be around in
Xorg since my introduction to in which was 6.something

===== VIA & SIS Drivers =====
These two drivers suffer from an issue mentioned in (6: Xorg Y.Z - Serious
They do not seem to links with assert.
Which is far to common to NOT be included.
What is worse is that they donot even include the assert.h, but still
compiles. (quite an interesting task to accomplish)
So, I had two approaches
1) Do it the correct way, and add the #include <assert.h> to the via and sis
2) Do it the quick way and make assert go away.
#1 is by all means the secure one, but only relevant when debug is enabled.
#2 is the way I chose, as there might be more work to do, and at the time I
wanted to make sure that this was the only problem and was, in fact, the
actual problem.
So the patches I am going to supply contains the fix from #2, but should be
changed to #1.
-DNDEBUG can be added to the Makefiles to mimic the behavior of #2, while
using #1.
the files in question are: sis_dri.c and via_dri.c

WARNING: these patches are for modules, so you'll have to find those two
files for monolithic and repatch it yourself.

===== ASM in DRI =====
I compiled unmodified versions of linux-dri and linux-dri-x86.
In both cases, they performed at the same exact speeds. (and the
linux-dri-x86 was also tested with NO TEXREL as already mentioned).
So, using optimized ASM should probably be avoided given its unportability
(I believe linux-dri still uses ASM, but much fewer "optimizations" are
Under glibc, I have tested this and glibc is so bloated that the use of
optimized ASM is required to get performance boosts.

===== GCC's 3.4.6 / 4.1.1 =====
Okay, so my original system was 4.1.1. When I had problems and could not
identigfy them, I fell back to 3.4.6.
This helped me prove that the problems were not gcc.
However, as a quick note, here are the Pros/Cons of what I learned from the
two GCC's.

- Produces faster code (faster boot time, I use initng, which records the
numbers - possibly due to being smaller, and thus getting in/out of hardware
bottle-necks faster)
- Produces smaller code (8mb system bootup into framebuffer usage on minimal
system - identical system other than gcc in both cases)
- No ALSA floating-point exceptions & segfaults (I can use alsa again!)
- Serious -ffast-math regression. (causes floating-point & segfaults
exceptions all over the place)
- SSP implimentation my be broken (GCC's LIBSSP). (The floating point
exceptions do not seem to get Smash Attack error messages using the gcc ssp,
but then is a floating-point exception close enough to being a segfault to
consider SSP?)
- uClibc SSP is broken.

- No -ffast-math issues
- Working SSP support from the HLFS patches + uClibc.
- Produces Slower code
- Produces Larger Code (12 mb system bootup into framevuffer usage on
minimal system - identical system other than gcc in both cases)
- ALSA floating-point exceptions & segfaults (I have to revert to using the
crappy, but beautifully stable OSS)

These issues directly effect Mesa.
First Mesa include -ffast-math, disabling it under gcc-4.1.1 will be
My strange issues may also be GCC related, so I am going to have two
different systems compile Xorg, one with gcc-4.1.1 and the other with
Any findings will be reported.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-sis-0.9.1-no_assert-1.patch
Type: application/octet-stream
Size: 1053 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-via-0.2.1-no_assert-1.patch
Type: application/octet-stream
Size: 1030 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list