Re: [Flightgear-devel] LibGL error

2005-11-12 Thread Ampere K. Hardraade
On November 11, 2005 07:26 pm, Ampere K. Hardraade wrote:
 I am also getting GLXUnsupportedPrivateRequest error.  This is so darn
 annoying!

 I used to be able to get around this problem by migrating back to XFree, or
 failing that, start XServer under 16-bit depth.  Now, I can't go with
 either option: Debian has moved onto Xorg, and SDL doesn't allow me to run
 OpenGL application under 16-bit depth.

 I am also using ATI card -- ATI 9200 SE to be precise.

 Ampere

Okay.  So far, I have tried:

Using the CVS version of Xorg -- no luck.

Using the CVS version of Mesa -- no luck.

Other OpenGL applications seem to run fine.  It's only FlightGear that crashed 
with the GLXUnsupportedPrivateRequest error during launch.  Any idea how I 
can get around the problem?

Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-11-11 Thread Ampere K. Hardraade
I am also getting GLXUnsupportedPrivateRequest error.  This is so darn 
annoying!

I used to be able to get around this problem by migrating back to XFree, or 
failing that, start XServer under 16-bit depth.  Now, I can't go with either 
option: Debian has moved onto Xorg, and SDL doesn't allow me to run OpenGL 
application under 16-bit depth.

I am also using ATI card -- ATI 9200 SE to be precise.

Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-11-07 Thread AJ MacLeod
On Sunday 06 November 2005 14:47, Mathias Fröhlich wrote:

 But looking at those problems with ATIs closed source drivers, I must say
 that NVidia seems to work better.
Certainly I've stuck with nvidia for all jobs involving graphics ever since 
Matrox fell behind, and I've not had reason to regret it so far...

 On the other hand, many people see massive performance hits with current
 NVidia drivers in presence of OpenGL points (all our lights are such
 points ...). The NVidia card at work does not show any problem with FG at
 night, but that one is a extremely expensive Quadro card certified for
 professional CAD use (often many points/lines).
AFAIK this bug disappeared a while ago - it only affected a particular driver 
release (or releases, I'm not certain).

Certainly I upgraded the nvidia drivers on an affected machine last week and 
framerates were back to normal.

 All together no 'better choice' ...
I really don't like closed source anything, and device drivers in particular, 
but IME nvidia's offerings are about as good as could be hoped for in the 
circumstances (although obviously not perfect.)

I'd switch allegiance in a flash if well performing, stable, open source 
drivers were available for some other reasonably priced cards though.

Cheers,

AJ

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-11-07 Thread Martin Spott
AJ MacLeod wrote:

 I really don't like closed source anything, and device drivers in particular, 
 but IME nvidia's offerings are about as good as could be hoped for in the 
 circumstances (although obviously not perfect.)
 
 I'd switch allegiance in a flash if well performing, stable, open source 
 drivers were available for some other reasonably priced cards though.

You should have a closer look at the upcoming XOrg-6.9/7.0 that'll
contain OpenSource drivers for the ATI Radeon X8x0 series.
This is why I typically buy ATI: There _is_ a chance that OpenSource
drivers appear after some time while you still have closed binary
drivers to fill the gap. With nVidia you can be certain that you'll
_never_ see OpenSource drivers. I think this makes an essential
difference.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-11-07 Thread AJ MacLeod
On Monday 07 November 2005 12:05, Martin Spott wrote:
 You should have a closer look at the upcoming XOrg-6.9/7.0 that'll
 contain OpenSource drivers for the ATI Radeon X8x0 series.
Good news indeed - I knew there were OS drivers for ATI cards in exisistance, 
but hadn't heard too much about their usability yet...

 This is why I typically buy ATI: There _is_ a chance that OpenSource
 drivers appear after some time while you still have closed binary
 drivers to fill the gap. With nVidia you can be certain that you'll
 _never_ see OpenSource drivers. I think this makes an essential
 difference.

I agree with you, of course; only if one is working on a project which needs 
solid graphics support _now_ then one doesn't have quite the same 
flexibility.  From what I see, the ATI binary drivers are a good bit behind 
nvidia in the fit and forget hassle-free stakes.

For my own (FG!) use, though, I'll be watching the progress of those open 
source drivers closely because my own nvidia card is nearing retirement age 
and I have an aversion to running any non-open source drivers.

Cheers,

AJ

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-11-06 Thread Mathias Fröhlich
On Donnerstag 03 November 2005 22:28, Josh Babcock wrote:
 Mathias Fröhlich wrote:
  Now using fglrx with a newer radeon on that machine. Since that it works
  fine ...

 Hmm, after much pain and suffering I have installed fglrx on my machine.
 Good news: all my OpenGL apps work fine. Bad news: except FlightGear.

 It just falls back to software rendering. What X system are you using?
 Xorg of XF86? can you send me your xorg.conf or XF86Config-4 file? I
 want to see if it's a configuration option that's causing the problem.

Hmm,
OpenGL on Linux is fun ...
:-/

I use a recent update of xorg from Fedora core 4 without local modifications, 
that is at the moment xorg-x11-6.8.2-37.FC4.49.2. I also use the fglrx from 
the livna yum repository. They often fix some bugs in the official ati fglrx 
code in their rpms. This version is currently ati-fglrx-8.18.6.1-0.lvn.1.4. 
For such fixes, look into their src rpms.
Attached is my xorg.conf from that machine.

But at the current state flightgear crashes on exit somewhere in GL, but only 
on the fglrx machine ...

At work, I work (at least partly) in a team doing OpenGL based 3D 
visualization of fluid dynamics. Some of the most strange problem reports 
originate from machines with ATI cards. All our development machines (except 
some machines used for testing and reproducing that strange problems) are 
equipped with NVidia cards.
I personally like the ATI cards much more since ATI ever released some specs 
about their cards to the open source community, so there was some hope that 
well doing drivers will appear.
But looking at those problems with ATIs closed source drivers, I must say that 
NVidia seems to work better.

On the other hand, many people see massive performance hits with current 
NVidia drivers in presence of OpenGL points (all our lights are such 
points ...). The NVidia card at work does not show any problem with FG at 
night, but that one is a extremely expensive Quadro card certified for 
professional CAD use (often many points/lines).
Since the performance hit with points seemed to have begun at a specific 
driver version, it comes in mind that NVidia might want people drawing lines 
and points not needed for most 3D games pay much for their professional 
cards?
You remember the driver limitation in the windows nvidia drivers not enabling 
sli with non nvidia mainboard chipsets, even when old drivers showed 
promising results with all chipsets ...

All together no 'better choice' ...

   Greetings

   Mathias

-- 
Mathias Fröhlich, email: [EMAIL PROTECTED]
# XFree86 4 configuration created by pyxf86config

Section ServerLayout
Identifier Default Layout
Screen  0  Screen0 0 0
InputDeviceMouse0 CorePointer
InputDeviceKeyboard0 CoreKeyboard
EndSection

Section Files
# RgbPath is the location of the RGB database.  Note, this is the name of the 
# file minus the extension (like .txt or .db).  There is normally
# no need to change the default.

# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.

RgbPath  /usr/X11R6/lib/X11/rgb
FontPath unix/:7100
EndSection

Section Module
Load  dbe
SubSection extmod
Option  omit xfree86-dga   # don't initialise the DGA 
extension
EndSubSection
#   Load  fbdevhw
Load  glx
Load  record
Load  freetype
Load  type1
Load  dri
EndSection


Section InputDevice
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
#   Option  Xleds 1 2 3

# To disable the XKEYBOARD extension, uncomment XkbDisable.
#   Option  XkbDisable

# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults).  For example, for a non-U.S.
# keyboard, you will probably want to use:
#   Option  XkbModel  pc102
# If you have a US Microsoft Natural keyboard, you can use:
#   Option  XkbModel  microsoft
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
#   Option  XkbLayout de
# or:
#   Option  XkbLayout de
#   Option  XkbVariantnodeadkeys
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
#   Option  XkbOptionsctrl:swapcaps
# Or if you just want both to be control, use:
#   Option  XkbOptionsctrl:nocaps
#
Identifier  Keyboard0
Driver  kbd
Option  XkbModel pc105
Option  XkbLayout de
Option  XkbVariant nodeadkeys
EndSection

Section InputDevice
Identifier  Mouse0
Driver  mouse
Option  Protocol IMPS/2
Option  Device /dev/input/mice
Option  ZAxisMapping 4 5
#   Option  Emulate3Buttons yes
EndSection

Section Monitor

Re: [Flightgear-devel] LibGL error

2005-11-03 Thread Josh Babcock
Mathias Fröhlich wrote:
 
 Now using fglrx with a newer radeon on that machine. Since that it works 
 fine ...
 

Hmm, after much pain and suffering I have installed fglrx on my machine.
Good news: all my OpenGL apps work fine. Bad news: except FlightGear.

It just falls back to software rendering. What X system are you using?
Xorg of XF86? can you send me your xorg.conf or XF86Config-4 file? I
want to see if it's a configuration option that's causing the problem.

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-10-30 Thread Mathias Fröhlich
On Freitag 28 Oktober 2005 22:32, Josh Babcock wrote:
 X Error of failed request:  GLXUnsupportedPrivateRequest
   Major opcode of failed request:  145 (GLX)
   Minor opcode of failed request:  16 (X_GLXVendorPrivate)
   Serial number of failed request:  31
   Current serial number in output stream:  32
 Do you still have that patch around? I would like to play with it. Using
 fglrx with Debian is extremely painful.
:)
It is, but it is the only option at the moment for me.
The r300 driver is far away from being usefull for fg ...
Anyway, the radeon one (don't know about the r200), has huge problems with 
Haralds shadows which look great in the fglrx case.

Attached is that ugly workaround for that error.
It effectively disables RenderTexture for drivers crashing on such requests.

   Greetings

   Mathias

-- 
Mathias Fröhlich, email: [EMAIL PROTECTED]
? simgear/math/linalg.h
? simgear/misc/swap_test
? simgear/scene/fgsg
Index: simgear/screen/RenderTexture.cpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/RenderTexture.cpp,v
retrieving revision 1.10
diff -u -r1.10 RenderTexture.cpp
--- simgear/screen/RenderTexture.cpp	5 Sep 2005 09:02:56 -	1.10
+++ simgear/screen/RenderTexture.cpp	31 Oct 2005 07:04:52 -
@@ -456,6 +456,11 @@
 
 #elif defined( __APPLE__ )
 #else // !_WIN32
+
+/// Ugly workaround for gl drivers not working correctly with pbuffers.
+return false;
+
+
 _pDisplay = glXGetCurrentDisplay();
 GLXContext context = glXGetCurrentContext();
 int screen = DefaultScreen(_pDisplay);
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] LibGL error

2005-10-28 Thread Mathias Fröhlich

Josh,

this is what I got with the r200 driver too.
I believe it is a problem either in the glx implementation or the dri 
equivatent of that.
May be a gl client lib not fitting exactly together with the server side 
implementation. Long standing bug. If you get that isolated you may report 
that at dri-devel.

It happens at the time RenderTexture queries visuals. At the time I used the 
r200, I just worked around by a early hard coded exit in the RenderTexture 
initialization.
Ugly, but worked ...

I later hoped that this was fixed by the switch to the standard glX 1.4 
pbuffer extensions, but that does not seem to be the case ...

Now using fglrx with a newer radeon on that machine. Since that it works 
fine ...

   Greetings

 Mathias

On Donnerstag 27 Oktober 2005 23:08, Josh Babcock wrote:
 OK, I got cvs to compile, but it won't run. Here's the output with
 export LIBGL_VERBOSE=1
 export LIBGL_DEBUG=verbose


 tower:~$ fgfs --aircraft=c172p
 libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
 libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so
 drmOpenByBusid: Searching for BusID pci::01:00.0
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 7, (OK)
 drmOpenByBusid: drmOpenMinor returns 7
 drmOpenByBusid: drmGetBusid reports pci::01:00.0
 Dent: .Dent: ..Dent: CVSDent: EHAMopening file:
 /usr/local/share/FlightGear/data/Navaids/carrier_nav.dat
 /usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat
 X Error of failed request:  GLXUnsupportedPrivateRequest
   Major opcode of failed request:  145 (GLX)
   Minor opcode of failed request:  16 (X_GLXVendorPrivate)
   Serial number of failed request:  31
   Current serial number in output stream:  32
 Vertex3f: 1


 This is using the debian xorg package with the open source radeon
 driver. glxgears, blender and a host of other OGL software works without
 a hitch. Any ideas?

 Josh

 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d

-- 
Mathias Fröhlich, email: [EMAIL PROTECTED]

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] LibGL error

2005-10-28 Thread Josh Babcock
Mathias Fröhlich wrote:
 Josh,
 
 this is what I got with the r200 driver too.
 I believe it is a problem either in the glx implementation or the dri 
 equivatent of that.
 May be a gl client lib not fitting exactly together with the server side 
 implementation. Long standing bug. If you get that isolated you may report 
 that at dri-devel.
 
 It happens at the time RenderTexture queries visuals. At the time I used the 
 r200, I just worked around by a early hard coded exit in the RenderTexture 
 initialization.
 Ugly, but worked ...
 
 I later hoped that this was fixed by the switch to the standard glX 1.4 
 pbuffer extensions, but that does not seem to be the case ...
 
 Now using fglrx with a newer radeon on that machine. Since that it works 
 fine ...
 
Greetings
 
  Mathias
 
 On Donnerstag 27 Oktober 2005 23:08, Josh Babcock wrote:
 
OK, I got cvs to compile, but it won't run. Here's the output with
export LIBGL_VERBOSE=1
export LIBGL_DEBUG=verbose


tower:~$ fgfs --aircraft=c172p
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci::01:00.0
Dent: .Dent: ..Dent: CVSDent: EHAMopening file:
/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat
/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  145 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  31
  Current serial number in output stream:  32
Vertex3f: 1


This is using the debian xorg package with the open source radeon
driver. glxgears, blender and a host of other OGL software works without
a hitch. Any ideas?

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
 
 

Do you still have that patch around? I would like to play with it. Using
fglrx with Debian is extremely painful.

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] LibGL error

2005-10-27 Thread Josh Babcock
OK, I got cvs to compile, but it won't run. Here's the output with
export LIBGL_VERBOSE=1
export LIBGL_DEBUG=verbose


tower:~$ fgfs --aircraft=c172p
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci::01:00.0
Dent: .Dent: ..Dent: CVSDent: EHAMopening file:
/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat
/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  145 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  31
  Current serial number in output stream:  32
Vertex3f: 1


This is using the debian xorg package with the open source radeon
driver. glxgears, blender and a host of other OGL software works without
a hitch. Any ideas?

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d