| OpenGL + Linux crashes [message #38360] |
Tue, 02 March 2004 18:06  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
If you're a user of a recent Linux (like Fedora), and you've experienced
crashes of the type:
Floating exception
~
when attempting to use any of IDL's OpenGL 3D stuff (like the Demo ->
Itools, for example), you might try the following:
setenv MESA_NO_ASM 1
which disables some specific ASM code in the Mesa library which was
causing these types of crashes for me. I use an ATI Radeon 7500 +
XFree86 4.3.0's radeon drivers. With this fix in place, it seems
stable, and is definitely much faster than software rendering. Give a
a try.
JD
|
|
|
|
| Re: OpenGL + Linux crashes [message #38493 is a reply to message #38360] |
Wed, 10 March 2004 17:22  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Tue, 09 Mar 2004 13:27:32 -0700, Karl Schultz wrote:
>
> "Michael Wallace" <mwallace.removethismunge@swri.edu.invalid> wrote in
> message news:104s3g1s2kg8vf1@corp.supernews.com...
>>> when attempting to use any of IDL's OpenGL 3D stuff (like the Demo ->
>>> Itools, for example), you might try the following:
>>>
>>> setenv MESA_NO_ASM 1
>>>
>>> which disables some specific ASM code in the Mesa library which was
>>> causing these types of crashes for me. I use an ATI Radeon 7500 +
>>> XFree86 4.3.0's radeon drivers. With this fix in place, it seems
>>> stable, and is definitely much faster than software rendering. Give a
>>> a try.
>>
>> This is awesome! I also have a Fedora box with an ATI Radeon 7500 and
>> it works great. I'm just curious what assembly language optimizations
>> are conflicting with IDL's OpenGL stuff. Oh, well. At least it works
>> better than using software rendering everywhere.
>
> On recent Linux/XFree86 installations, there are actually two instances of
> the Mesa library in play when you run IDL. One is the Mesa that is linked
> directly to IDL that IDL uses to perform software rendering and really isn't
> involved any further in this discussion. The other instance is over in the
> X server where it implements OpenGL (via GLX) in software if there is no
> hardware acceleration support. For systems with the hardware and software
> support for hardware acceleration, Mesa still serves as the OpenGL
> implemention and it uses various driver modules to interface with the
> specific hardware.
<snip>
Thanks Karl:
It's great to know someone at RSI is staying on top of these issues.
Not only do we get an IDL which works with standard drivers, but the
3D support in XFree86 gets improved too! Keep up the good work.
JD
|
|
|
|
|
|
| Re: OpenGL + Linux crashes [message #38514 is a reply to message #38360] |
Tue, 09 March 2004 12:27 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Michael Wallace" <mwallace.removethismunge@swri.edu.invalid> wrote in
message news:104s3g1s2kg8vf1@corp.supernews.com...
>> when attempting to use any of IDL's OpenGL 3D stuff (like the Demo ->
>> Itools, for example), you might try the following:
>>
>> setenv MESA_NO_ASM 1
>>
>> which disables some specific ASM code in the Mesa library which was
>> causing these types of crashes for me. I use an ATI Radeon 7500 +
>> XFree86 4.3.0's radeon drivers. With this fix in place, it seems
>> stable, and is definitely much faster than software rendering. Give a
>> a try.
>
> This is awesome! I also have a Fedora box with an ATI Radeon 7500 and
> it works great. I'm just curious what assembly language optimizations
> are conflicting with IDL's OpenGL stuff. Oh, well. At least it works
> better than using software rendering everywhere.
On recent Linux/XFree86 installations, there are actually two instances of
the Mesa library in play when you run IDL. One is the Mesa that is linked
directly to IDL that IDL uses to perform software rendering and really isn't
involved any further in this discussion. The other instance is over in the
X server where it implements OpenGL (via GLX) in software if there is no
hardware acceleration support. For systems with the hardware and software
support for hardware acceleration, Mesa still serves as the OpenGL
implemention and it uses various driver modules to interface with the
specific hardware.
When a client (like IDL) connects to an X server with the hardware
acceleration support, it is really slow to send the GL commands through the
X server via X/GLX protocol. So, there is a module called DRI (Direct
Rendering Infrastructure) that is used to connect the client application
"directly" to the hardware, or more accurately, to the Mesa interface layer
that implements OpenGL for the device.
When this Mesa module starts up, it attempts to see if the SSE (Streaming
SIMD (Single Instruction Multiple Data) Extensions) instructions are
available on the CPU. Unfortunately, one of the steps that must be taken in
order to do this reliably on Linux is to force an exception and poke around
in the CPU status registers to see if it did what it was supposed to if the
SSE instructions are present. The code that does this installs its own
exception handler and then removes it when finished. Apparently there is
something wrong with this particular code sequence that causes an exception
to occur anyway. After reading the code, my *guess* is that the exception
handler code isn't clearing the exception state out of the CPU and then IDL
is tripping over it later. It turns out that another application (SDL) has
the same problem. I'll be installing Fedora Core 1 soon to investigate
further and try to get it fixed in Mesa.
Because it is so tricky to detect and use SSE, the Mesa developers wisely
made it possible to avoid it all by setting the env var mentioned above.
Anyway, the SSE instructions are used to speed up common math operations in
Mesa, like coordinate transforms and matrix multiplies. These would be more
important if Mesa was doing most of the rendering work in software. If you
have a good graphics card that does transforms and lighting in hardware,
much of this math would occur on the graphics card and so turning off SSE
won't hurt performance as much.
If I learn anything more, I'll post it.
Karl
|
|
|
|
|
|
| Re: OpenGL + Linux crashes [message #38552 is a reply to message #38360] |
Tue, 16 March 2004 07:54 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"JD Smith" <jdsmith@as.arizona.edu> wrote in message
news:pan.2004.03.15.20.50.11.321172@as.arizona.edu...
> On Mon, 15 Mar 2004 08:50:17 -0700, Karl Schultz wrote:
>
>>
>> "JD Smith" <jdsmith@as.arizona.edu> wrote in message
>> news:pan.2004.03.11.01.22.05.612878@as.arizona.edu...
>>>
>>> On Tue, 09 Mar 2004 13:27:32 -0700, Karl Schultz wrote:
>>>
>>>>
>>>> "Michael Wallace" <mwallace.removethismunge@swri.edu.invalid> wrote
in
>>>> message news:104s3g1s2kg8vf1@corp.supernews.com...
>>>> > > when attempting to use any of IDL's OpenGL 3D stuff (like the
Demo ->
>>>> > > Itools, for example), you might try the following:
>>>> > >
>>>> > > setenv MESA_NO_ASM 1
>>>> > >
>>>> > > which disables some specific ASM code in the Mesa library which
was
>>>> > > causing these types of crashes for me. I use an ATI Radeon 7500 +
>>>> > > XFree86 4.3.0's radeon drivers. With this fix in place, it seems
>>>> > > stable, and is definitely much faster than software rendering.
Give
>> a
>>>> > > a try.
>>>> >
>>>> > This is awesome! I also have a Fedora box with an ATI Radeon 7500
and
>>>> > it works great. I'm just curious what assembly language
optimizations
>>>> > are conflicting with IDL's OpenGL stuff. Oh, well. At least it
works
>>>> > better than using software rendering everywhere.
>>>>
>>>> On recent Linux/XFree86 installations, there are actually two
instances
>> of
>>>> the Mesa library in play when you run IDL. One is the Mesa that is
>> linked
>>>> directly to IDL that IDL uses to perform software rendering and
really
>> isn't
>>>> involved any further in this discussion. The other instance is over
in
>> the
>>>> X server where it implements OpenGL (via GLX) in software if there is
no
>>>> hardware acceleration support. For systems with the hardware and
>> software
>>>> support for hardware acceleration, Mesa still serves as the OpenGL
>>>> implemention and it uses various driver modules to interface with the
>>>> specific hardware.
>>>
>>> <snip>
>>>
>>> Thanks Karl:
>>>
>>> It's great to know someone at RSI is staying on top of these issues.
>>> Not only do we get an IDL which works with standard drivers, but the
>>> 3D support in XFree86 gets improved too! Keep up the good work.
>>
>> I installed Fedora Core 1 (FC1) on a system with a Radeon 9700 and IDL
>> worked OK right out of the box. But the XFree86 log (in /var/log) said
that
>> the X server disabled DRI because the support wasn't there (yet). The
word
>> "yet" encourages me a great deal, but it would be nice to get this card
>> flying now. glxgears ran at about 1000 fps but I had it running at over
>> 3000 fps with ATI drivers on rh8. So, I grab the XFree86 4.3
9000-series
>> "fglrx" drivers from the ATI website. They install with no trouble and
>> there is no sign of the FPE problem, probably because ATI used a
different
>> code base. glxgears is back to 3000+ and IDL runs so fast that I nearly
>> missed seeing the objworld demo in the demo tour because I blinked for
too
>> long. As Ferris once said, "I highly recommend picking one up, if you
have
>> the means".
>>
>> Then I scrounge a Radeon 7000 and am able to reproduce the FPE problem.
I'm
>> back to using the stock FC1 drivers at this point. I've been digging
into
>> the problem since, but haven't nailed it yet. I did learn that two
other
>> applications are experiencing the same problem. I'm fairly convinced
that
>> the problem is related to signal handling.
>
> Thanks again Karl. ATI's linux drivers are well regarded, though
> widely decried for being very late compared to their Windows
> counterparts, and closed source. The 7xxx era of Radeons also isn't
> supported, so we're stuck with the DRI project's drivers (fine, but
> slow, and clearly still containing a few glitches).
Yes. I'll probably end up filing a bug report on XFree86 DRI for the FPE
problem. I have gdb'd myself to death in the machine code in the area of
interest and I didn't see anything wrong. There must be something going on
in a place that I can't see. Some of the code came from Mesa, which I do
have the source for, but the rest is proprietary ATI stuff. Without the
source code, I can't do much more. The DRI guys have NDA's with ATI for the
Radeon code, so maybe they can see the problem.
In the meantime, a tip of the hat to the Mesa guys for providing the env var
to skip around the problem.
> Do you also test
> under Linux with the proprietary NVidia drivers?
When I made the changes to IDL for 6.0 to let it work better with the DRI
architecture, I tested on a rh9 system with the NVidia drivers.
Karl
|
|
|
|
| Re: OpenGL + Linux crashes [message #38558 is a reply to message #38360] |
Mon, 15 March 2004 12:50 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Mon, 15 Mar 2004 08:50:17 -0700, Karl Schultz wrote:
>
> "JD Smith" <jdsmith@as.arizona.edu> wrote in message
> news:pan.2004.03.11.01.22.05.612878@as.arizona.edu...
>>
>> On Tue, 09 Mar 2004 13:27:32 -0700, Karl Schultz wrote:
>>
>>>
>>> "Michael Wallace" <mwallace.removethismunge@swri.edu.invalid> wrote in
>>> message news:104s3g1s2kg8vf1@corp.supernews.com...
>>>> > when attempting to use any of IDL's OpenGL 3D stuff (like the Demo ->
>>>> > Itools, for example), you might try the following:
>>>> >
>>>> > setenv MESA_NO_ASM 1
>>>> >
>>>> > which disables some specific ASM code in the Mesa library which was
>>>> > causing these types of crashes for me. I use an ATI Radeon 7500 +
>>>> > XFree86 4.3.0's radeon drivers. With this fix in place, it seems
>>>> > stable, and is definitely much faster than software rendering. Give
> a
>>>> > a try.
>>>>
>>>> This is awesome! I also have a Fedora box with an ATI Radeon 7500 and
>>>> it works great. I'm just curious what assembly language optimizations
>>>> are conflicting with IDL's OpenGL stuff. Oh, well. At least it works
>>>> better than using software rendering everywhere.
>>>
>>> On recent Linux/XFree86 installations, there are actually two instances
> of
>>> the Mesa library in play when you run IDL. One is the Mesa that is
> linked
>>> directly to IDL that IDL uses to perform software rendering and really
> isn't
>>> involved any further in this discussion. The other instance is over in
> the
>>> X server where it implements OpenGL (via GLX) in software if there is no
>>> hardware acceleration support. For systems with the hardware and
> software
>>> support for hardware acceleration, Mesa still serves as the OpenGL
>>> implemention and it uses various driver modules to interface with the
>>> specific hardware.
>>
>> <snip>
>>
>> Thanks Karl:
>>
>> It's great to know someone at RSI is staying on top of these issues.
>> Not only do we get an IDL which works with standard drivers, but the
>> 3D support in XFree86 gets improved too! Keep up the good work.
>
> I installed Fedora Core 1 (FC1) on a system with a Radeon 9700 and IDL
> worked OK right out of the box. But the XFree86 log (in /var/log) said that
> the X server disabled DRI because the support wasn't there (yet). The word
> "yet" encourages me a great deal, but it would be nice to get this card
> flying now. glxgears ran at about 1000 fps but I had it running at over
> 3000 fps with ATI drivers on rh8. So, I grab the XFree86 4.3 9000-series
> "fglrx" drivers from the ATI website. They install with no trouble and
> there is no sign of the FPE problem, probably because ATI used a different
> code base. glxgears is back to 3000+ and IDL runs so fast that I nearly
> missed seeing the objworld demo in the demo tour because I blinked for too
> long. As Ferris once said, "I highly recommend picking one up, if you have
> the means".
>
> Then I scrounge a Radeon 7000 and am able to reproduce the FPE problem. I'm
> back to using the stock FC1 drivers at this point. I've been digging into
> the problem since, but haven't nailed it yet. I did learn that two other
> applications are experiencing the same problem. I'm fairly convinced that
> the problem is related to signal handling.
Thanks again Karl. ATI's linux drivers are well regarded, though
widely decried for being very late compared to their Windows
counterparts, and closed source. The 7xxx era of Radeons also isn't
supported, so we're stuck with the DRI project's drivers (fine, but
slow, and clearly still containing a few glitches). Do you also test
under Linux with the proprietary NVidia drivers?
JD
|
|
|
|
| Re: OpenGL + Linux crashes [message #38561 is a reply to message #38493] |
Mon, 15 March 2004 07:50 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"JD Smith" <jdsmith@as.arizona.edu> wrote in message
news:pan.2004.03.11.01.22.05.612878@as.arizona.edu...
>
> On Tue, 09 Mar 2004 13:27:32 -0700, Karl Schultz wrote:
>
>>
>> "Michael Wallace" <mwallace.removethismunge@swri.edu.invalid> wrote in
>> message news:104s3g1s2kg8vf1@corp.supernews.com...
>>>> when attempting to use any of IDL's OpenGL 3D stuff (like the Demo ->
>>>> Itools, for example), you might try the following:
>>>>
>>>> setenv MESA_NO_ASM 1
>>>>
>>>> which disables some specific ASM code in the Mesa library which was
>>>> causing these types of crashes for me. I use an ATI Radeon 7500 +
>>>> XFree86 4.3.0's radeon drivers. With this fix in place, it seems
>>>> stable, and is definitely much faster than software rendering. Give
a
>>>> a try.
>>>
>>> This is awesome! I also have a Fedora box with an ATI Radeon 7500 and
>>> it works great. I'm just curious what assembly language optimizations
>>> are conflicting with IDL's OpenGL stuff. Oh, well. At least it works
>>> better than using software rendering everywhere.
>>
>> On recent Linux/XFree86 installations, there are actually two instances
of
>> the Mesa library in play when you run IDL. One is the Mesa that is
linked
>> directly to IDL that IDL uses to perform software rendering and really
isn't
>> involved any further in this discussion. The other instance is over in
the
>> X server where it implements OpenGL (via GLX) in software if there is no
>> hardware acceleration support. For systems with the hardware and
software
>> support for hardware acceleration, Mesa still serves as the OpenGL
>> implemention and it uses various driver modules to interface with the
>> specific hardware.
>
> <snip>
>
> Thanks Karl:
>
> It's great to know someone at RSI is staying on top of these issues.
> Not only do we get an IDL which works with standard drivers, but the
> 3D support in XFree86 gets improved too! Keep up the good work.
I installed Fedora Core 1 (FC1) on a system with a Radeon 9700 and IDL
worked OK right out of the box. But the XFree86 log (in /var/log) said that
the X server disabled DRI because the support wasn't there (yet). The word
"yet" encourages me a great deal, but it would be nice to get this card
flying now. glxgears ran at about 1000 fps but I had it running at over
3000 fps with ATI drivers on rh8. So, I grab the XFree86 4.3 9000-series
"fglrx" drivers from the ATI website. They install with no trouble and
there is no sign of the FPE problem, probably because ATI used a different
code base. glxgears is back to 3000+ and IDL runs so fast that I nearly
missed seeing the objworld demo in the demo tour because I blinked for too
long. As Ferris once said, "I highly recommend picking one up, if you have
the means".
Then I scrounge a Radeon 7000 and am able to reproduce the FPE problem. I'm
back to using the stock FC1 drivers at this point. I've been digging into
the problem since, but haven't nailed it yet. I did learn that two other
applications are experiencing the same problem. I'm fairly convinced that
the problem is related to signal handling.
Karl
|
|
|
|
| Re: OpenGL + Linux crashes [message #38562 is a reply to message #38513] |
Mon, 15 March 2004 07:28 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"F�ldy Lajos" <foldy@rmki.kfki.hu> wrote in message
news:Pine.LNX.4.58.0403092159240.29572@bifur.rmki.kfki.hu...
>
> On Tue, 9 Mar 2004, Karl Schultz wrote:
>
>> ...
>> When this Mesa module starts up, it attempts to see if the SSE
(Streaming
>> SIMD (Single Instruction Multiple Data) Extensions) instructions are
>> available on the CPU. ...
>
>
> a stupid (?) question: Mesa knows that it is running on linux. Why not
> does it read /proc/cpuinfo first to learn about CPU features? And go the
> tricky way if /proc/cpuinfo does not exist.
This is a very interesting suggestion. Unfortunately, the situation is not
that simple.
Intel explains why in
http://www.intel.com/cd/ids/developer/asmo-na/eng/microproce ssors/ia32/pentium4/resources/appnotes/sse/19065.htm
If you prefer to look at source code, see the files in Mesa (Sourceforge) or
XFree86 4.3 (mesa/src/x86).
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
