--- Brian Paul <[EMAIL PROTECTED]> wrote:
Any application which depends upon the root window having particular GLX attributes is in error.
It's a screensaver. Using the root window would seem to be a requirement here. So what you're really saying is "Who cares if you can't perform OpenGL / direct rendering on the root window?". And the answer is "Everyone who runs xscreensaver, for a start!".
I'm not trying to marginalize the problem you found. It's just that OpenGL drivers for Linux can come from many sources (XFree86/DRI, NVIDIA, ATI, Xi, etc) and there's no guarantee that any of them will give you a root window with particular GLX attributes. Sometimes you might get lucky.
[I've lost count of how many times this has come up over the years, BTW.]
If you'd have changed cards in your system and found this problem would you be as upset? Or, suppose you started running your X server at a different default resolution and the GLX visuals changed.
Do other graphics cards have this problem?
Probably. I use NVIDIA's cards/drivers for a project that I work on and it's not unusual to see that the list of GLX visuals changes from one driver release to the next.
You have just killed OpenGL screensavers with the G400, for example, and goodness knows what else.
*I* did? Give me a break.
That's "you" as in "DRI developers". Not "you" personally. (Not to my knowledge, anyway.)
You can play semantics and say it isn't a bug, but it is definitely a regression that will be very unpopular with a lot of Matrox users.
I wouldn't call it a regression either.
Did work before, doesn't work now. That's the very *definition* of a regression.
If something changes, but the new behaviour is still within specificied operational parameters, I guess I don't consider that a regression.
A concrete example of a similar user experience happened a while back when I changed the default maximum 3D texture size in Mesa. It was unrealistically large (I don't remember the value, maybe 1024x1024x1024) and I reduced it to a reasonable size (128x128x128 now). A user complained that his app stopped working. It turned out he wasn't querying GL_MAX_3D_TEXTURE_SIZE or using a proxy texture to be sure what he was trying to do was legal. I'm sure that if he'd have tried other GL drivers he'd have eventually found the same problem. Is that a regression?
b) The screensavers don't segfault because there's no suitable visual available. They seem to do so while trying to activate the indirect rendering instead. This is presumably why the rest of the OpenGL hacks flash the "libGL error: InitDriver failed" message on the screen and then run very slowly. And segfaults are always bugs.
It sounds like there might be a broader issue here. What does 'glxinfo' report? Does glxgears run with
hardware acceleration?
$ glxgears -info GL_RENDERER = Mesa DRI G400 20020221 AGP 4x x86/MMX/SSE GL_VERSION = 1.2 Mesa 4.0.4 GL_VENDOR = VA Linux Systems Inc. GL_EXTENSIONS = GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_compression GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_object GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_MESA_window_pos GL_NV_texgen_reflection GL_SGIS_generate_mipmap 4155 frames in 5.0 seconds = 831.000 FPS 4122 frames in 5.0 seconds = 824.400 FPS 4116 frames in 5.0 seconds = 823.200 FPS 4099 frames in 5.0 seconds = 819.800 FPS
I'm guessing "yes", but then, why wouldn't it? It's not running on the root window.
I have already posted the output from glxinfo to this list,
OK, I went and found your other post.
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 16 tc 1 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 1 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x25 16 tc 1 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
Looks like the only difference between visual 0x23 (the root visual) and 0x25 (what xscreensaver wants) is the addition of a stencil buffer in the later. I wonder if the GL screensavers really need stencil. Also note that visual 0x25 is flagged as 'Slow'. This is because the stencil buffer is implemented in software. So if a GL screensaver really does use stencil, it's going to be using software rendering (while GL_STENCIL_TEST is enabled anyway).
> together with a back-trace from one of the
SIGSEGV cores and the DEBUG output from the mga.o kernel module while running the "atlantis" hack. (Atlantis is one that seems to switch to indirect rendering rather than crashing.)
Unfortunately, my G400 card died a while back and I can't test. Maybe someone else can.
-Brian
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
