So here is a list of the topics, in order, of which I will discuss my findings
1) NO TEXREL
2) XGL / XGLX
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 fps.
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 tests.
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 Issues).
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 drivers.
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 nature.
(I believe linux-dri still uses ASM, but much fewer "optimizations" are used).
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.
gcc-4.1.1
Pros:
- 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!)
Cons:
- 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.
gcc-3.4.6
Pros:
- No -ffast-math issues
- Working SSP support from the HLFS patches + uClibc.
Const:
- 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 necessary.
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 gcc-3.4.6.
Any findings will be reported.
xf86-video-sis-0.9.1-no_assert-1.patch
Description: Binary data
xf86-video-via-0.2.1-no_assert-1.patch
Description: Binary data
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
