Content-Type: multipart/alternative; boundary="------------010706010602020003050100" --------------010706010602020003050100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I have recently rewritten the Mesa CPU detection code and would like someone else to give it a try. Basically, the highlights are: - added _mesa_x86_has_cpuid - added _mesa_x86_cpuid - added _mesa_x86_cpuid_eax - added _mesa_x86_cpuid_ebx - added _mesa_x86_cpuid_ecx - added _mesa_x86_cpuid_edx - removed _mesa_identify_x86_cpu_features - differentiated extended cpu features (in ..x86_features.h) from the std ones - changed the X86_FEATURE semantics a little bit with these tools, I am trying to parse the cpu feature while making distinction between the normal and extended cpu feature sets - no need to query the cpu vendor string, while making the code highly readable for people not familiar with the assembly langugage. Please consider applying... -petrs Bernhard Kaindl wrote: > Hi, > I'd like to report a finding on my Satellite 1110-z16 with > Mobile Celeron 1500 and Radeon LY under SuSE 8.1 and Mandrake 9 > using the installed XFree86-4.2 based X11/Mesa. > > Both show a problem with many 3D Linux apps arborting with SIGILL, > MESA_DEBUG showed that the apps were thinking that the Celeron > supported 3DNow(message 3dnow supported was printed) which it at > least does not when checking /proc/cpuinfo. > > After I disabled the use of 3dnow by exporting MESA_NO_3DNOW, > everything works but it's a not good needing to export it and it's > only a workaround. > > So it looks like as if the Mesa CPUID asm gets the 3dnow feature > bit set, so the feature is enabled and depending what the app does > it gets the sigill or not(glxgears and fgfs do not but show no > rendering in a part of the window if I move another window into the > middle of the 3d window. > > Both distributions use Free 4.2 code, but I've started > downloading the 4.3.99 rpms do test with it. > > Just guessing(maybe fixed already, just could not get the newest > XF86 4.3/Mesa Source over the slow modem I'm using atm yet, but > working on it): > > I've checked the 2.4.19 x86 feature/CPUID code in > arch/i386/kernel/setup.c and found a place where it > does something to the 3dnow flag. > > Maybe the CPUID regs set on stepping 7 of the Mobile > Celeron 1500 are a bit different and the kernel handles > this by the special 3dnow lines I've seen. > > Bernd --------------010706010602020003050100 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have recently rewritten the Mesa CPU detection code and
would like someone else to give it a try.

Basically, the highlights are:

- added _mesa_x86_has_cpuid
- added _mesa_x86_cpuid
- added _mesa_x86_cpuid_eax
- added _mesa_x86_cpuid_ebx
- added _mesa_x86_cpuid_ecx
- added _mesa_x86_cpuid_edx
- removed _mesa_identify_x86_cpu_features
- differentiated extended cpu features (in ..x86_features.h)
  from the std ones
- changed the X86_FEATURE semantics a little bit

with these tools, I am trying to parse the cpu feature while
making distinction between the normal and extended cpu
feature sets - no need to query the cpu vendor string, while
making the code highly readable for people not familiar with
the assembly langugage.

Please consider applying...

-petrs


Bernhard Kaindl wrote:
Hi,
   I'd like to report a finding on my Satellite 1110-z16 with
Mobile Celeron 1500 and Radeon LY under SuSE 8.1 and Mandrake 9
using the installed XFree86-4.2 based X11/Mesa.
 
Both show a problem with many 3D Linux apps arborting with SIGILL,
MESA_DEBUG showed that the apps were thinking that the Celeron
supported 3DNow(message 3dnow supported was printed) which it at
least does not when checking /proc/cpuinfo.
 
After I disabled the use of 3dnow by exporting MESA_NO_3DNOW,
everything works but it's a not good needing to export it and it's
only a workaround.
 
So it looks like as if the Mesa CPUID asm gets the 3dnow feature
bit set, so the feature is enabled and depending what the app does
it gets the sigill or not(glxgears and fgfs do not but show no
rendering in a part of the window if I move another window into the
middle of the 3d window.
 
Both distributions use Free 4.2 code, but I've started
downloading the 4.3.99 rpms do test with it.
 
Just guessing(maybe fixed already, just could not get the newest
XF86 4.3/Mesa Source over the slow modem I'm using atm yet, but
working on it):
 
I've checked the 2.4.19 x86 feature/CPUID code in
arch/i386/kernel/setup.c and found a place where it
does something to the 3dnow flag.
 
Maybe the CPUID regs set on stepping 7 of the Mobile
Celeron 1500 are a bit different and the kernel handles
this by the special 3dnow lines I've seen.
 
Bernd


--------------010706010602020003050100--