[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 23:40 --- This is most likely an issue with the OpenGL driver, or possibly the X driver. Please check the Mesa and xorg products at http://bugs.freedesktop.org and file a new bug there in the unlikely event that there is none about this yet. Attach full X config and log files there, and try running in depth 16 and not enabling Option "DynamicClocks" if you haven't yet. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5901] i915: libGL error: drmMap of framebuffer failed (Invalid argument)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5901 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 06:34 --- Using laptop dell inspiron i915 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5901] i915: libGL error: drmMap of framebuffer failed (Invalid argument)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5901 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 06:33 --- I have seen this message when start compiz. I am using packages for ubuntu and I followed steps to get it installed with this howto: http://www.ubuntuforums.org/showthread.php?t=145068 However when I start compiz maually this is what it shows. $compiz-start libGL error: drmMap of framebuffer failed (Invalid argument) libGL error: reverting to (slow) indirect rendering compiz.real: No stencil buffer. Clipping of transformed windows is not going to be correct when screen is transformed. I am using xorg-air I attached /var/log/Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5901] i915: libGL error: drmMap of framebuffer failed (Invalid argument)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5901 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 06:32 --- Created an attachment (id=5766) --> (https://bugs.freedesktop.org/attachment.cgi?id=5766&action=view) Xorg.0.log file -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 It helps on r300, I wonder why it isn't needed on mga. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][patch] retry when busy
Michel Dänzer wrote: > Indeed. The X server's GetTimeInMillis() might be more convenient > than gettimeofday() (and would also work with an elfloader X server > ;). Ah yes. That was just a quick hack :-). The question is, what should the timeout value be? >> For determining if the chip has locked up I just used the >> ZPASS_DATA reg (assuming that as long as the chip outputs fragments >> it has not locked up - of course you could hack up some gl test >> program where all fragments fail the z test, > > Will this still increase if the depth buffer/test is disabled? Yes. It may not be a good choice however, the reg might even be different on r300. >> but I'm not sure there's a better reg to monitor activity - ring >> ptr might be another possibility, but I think this can point at the >> same location for a long time too (for instance when drawing using >> the idx buf command). > > One of the performance counters might be better. Which one did you have in mind? Don't they need to be configured first? Sounds like a good idea though, or maybe that ring ptr would do too, I think chances aren't that great that it is really stuck at the same place for a long time. Roland -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Neverball reflections
I was running some test comparing the r200 vs the r300 driver this morning, and noticed a slight rendering issue with the r200 driver with reflections in the game neverball. http://68.44.156.246/neverball-9200.jpg As you can see, the reflections for the coins on the two bridges on the right are displayed even where there is no reflective surface. At first I thought this was a problem with the game, but when I tried with the drivers from XiG, this is what I saw: http://68.44.156.246/neverball-9200-xig.jpg The reflection is only visible on the reflective surface. For anyone interested, the r300 driver doesn't handle the refelective surfaces at all: http://68.44.156.246/neverball-9800.jpg You'll also be able to notice the framerate for the three drivers. Though the images only show a single frame, the difference in the framerate is pretty consistent. The XiG driver is generally at least 10-20 FPS higher than the r200 driver in neverball and Orbz. With other games (NWN, Q3A, for example) I've noticed that the difference is less (and in Q4, the XiG driver is a few FPS slower, probably due to hyperz support in the r200 driver since disabling that drops the FPS to roughly the same as the XiG driver). Aapo, I also tested the r200 driver after commenting out the ctx->Array.LockFirst = first; and ctx->Array.LockCount = count; lines as you suggested. I didn't see any real slowdown in NWN when I did that. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][patch] retry when busy
On Tue, 2006-05-30 at 14:33 +0200, Roland Scheidegger wrote: > Michel Dänzer wrote: > > On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote: > >> Looks like quite some more work is needed to detect real lockups but not > >> just randomly reseting the chip when there is none (which can itself > >> lead to lockups IME). > > > > Maybe, or maybe it's just a matter of sticking RADEONCP_STOP()s in the > > right places, ala https://bugs.freedesktop.org/show_bug.cgi?id=1889 . > Since the box is down, I assume this only refers to the lockups which > can be caused by reseting the engine? Yes. I think resetting the engine without at least trying to properly stop the CP is hazardous at any rate. > In any case, I can't see a good reason why you'd want to reset the chip > when it has, in fact, not locked up. > I've done some quick test hack (attached) which did fix the problem with > gltestperf for me (system was really unresponsive during the benchmark, > though), together with that EBUSY fix. > Apparently, on my box, the FIFO wait time is probably a bit short > (roughly 0.7 seconds), maybe something with a real timebase should be > used rather than just 2 million INREGS? Indeed. The X server's GetTimeInMillis() might be more convenient than gettimeofday() (and would also work with an elfloader X server ;). > For determining if the chip has locked up I just used the ZPASS_DATA reg > (assuming that as long as the chip outputs fragments it has not locked > up - of course you could hack up some gl test program where all > fragments fail the z test, Will this still increase if the depth buffer/test is disabled? > but I'm not sure there's a better reg to monitor activity - ring ptr might > be another possibility, but I think this can point at the same location for > a long time too (for instance when drawing using the idx buf command). One of the performance counters might be better. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 00:39 --- Dmesg is a bit late for the last freeze as the ring buffer has run out already. I still attach the output, but the first message is already after the restart of the system. I also attach /var/log/syslog and /var/log/messages and kern.log from the time of the crash. However, as I have written above, there is (at leat to my eyes) no relevant message in it. I always check syslog, messages and kern.log directly after such a crash and it always seems that the crash is instantaneous. No time for the kernel to write any relevant message. That´s why I asked if there is einer a method to increase kernel syslog messages (some kind of debug modus) or some other method to identify the culprit that freezes the system. According to syslog messages the last freeze occured yesterday between 13:48 and 13:58 (I was having lunch). When I came back, I saw the screensaver frozen with one dia (it´s an opengl dia show). My reboot was at 14:28. Such a freeze is typical. Sometimes I have this kind fo freeze in an opengl game. In this case the system sound very briefly stutters, then fails and the computer is frozen. (Don´t know if this helps...) Very grateful for any help to identify and finally remedy the problem. (It´s awful to always have these freezes and thus sometimes data loss!) Thanks, Michael P.S.: Next freeze, I will take a dmesg output directly, but 1.) I don´t know when this will be (in 1 hour or in a week) and 2.) I´m afraid there won´t be any more details in it than before. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 00:39 --- Created an attachment (id=8230) --> (http://bugzilla.kernel.org/attachment.cgi?id=8230&action=view) dmesg -s 100 (however, only starting after the last crash) --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 00:37 --- Created an attachment (id=8229) --> (http://bugzilla.kernel.org/attachment.cgi?id=8229&action=view) /var/log/messages from the time of the last crash --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 00:37 --- Created an attachment (id=8228) --> (http://bugzilla.kernel.org/attachment.cgi?id=8228&action=view) syslog from the time of the last crash --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Additional Comments From [EMAIL PROTECTED] 2006-05-31 00:36 --- Created an attachment (id=8227) --> (http://bugzilla.kernel.org/attachment.cgi?id=8227&action=view) kern.log from the time of the last crash --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
On 5/30/06, Pedro Maia <[EMAIL PROTECTED]> wrote: To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 In my case it works fine, with that trick , without it didn't work.But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. -- Free Software - find interesting programs and change themNetHack - meet interesting creatures, kill them and eat their bodiesUsenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] per-component negation for SWZ
Tilman Sauerbeck wrote: > Roland Scheidegger [2006-05-30 22:33]: >> Tilman Sauerbeck wrote: >>> I finally ran glean today, and noticed that SWZ wasn't implemented >>> properly for r300 ARB vertex programs. >>> >>> So far I didn't handle per-component negation flags, the attached patch >>> adds that. >>> >>> Question: is it okay to assume that "NegateBase" in >>> struct prog_src_register will always be filled the way it's filled >>> currently? ie that the sign for the x component is at bit 0 etc. >> I'd guess that's ok. Whoever wants to change it needs to make sure that >> the code wherever it's used still works. Such things can get forgotten >> though, but in that case someone will notice and fix it up then :-). > > Mmh, alright :) > >>> If it doesn't, the patch I attached obviously wouldn't work... >>> >>> If there are no objections, I'll commit this in a few days. >> Wouldn't it be simpler to just change t_src to always apply >> src->NegateBase? I can't see a need for that "src->NegateBase ? >> VSF_FLAG_ALL : VSF_FLAG_NONE", as the mesa parser sets all 4 bits anyway >> when "normal" instructions are parsed. The code would both be smaller >> and faster :-). (t_src_scalar OTOH cannot be changed.) > > That won't work for NV vertex programs. nvvertparse.c sets NegateBase to > either GL_TRUE or GL_FALSE. That's a bug, probably relating to (fairly) recent merge of vertex, fragment, NV and ARB programs all into a single representation. Feel free to fix it to match the other usages. Keith -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] per-component negation for SWZ
Tilman Sauerbeck wrote: > Roland Scheidegger [2006-05-30 22:33]: > >>Tilman Sauerbeck wrote: >> >>>I finally ran glean today, and noticed that SWZ wasn't implemented >>>properly for r300 ARB vertex programs. >>> >>>So far I didn't handle per-component negation flags, the attached patch >>>adds that. >>> >>>Question: is it okay to assume that "NegateBase" in >>>struct prog_src_register will always be filled the way it's filled >>>currently? ie that the sign for the x component is at bit 0 etc. >> >>I'd guess that's ok. Whoever wants to change it needs to make sure that >>the code wherever it's used still works. Such things can get forgotten >>though, but in that case someone will notice and fix it up then :-). > > > Mmh, alright :) > > >>>If it doesn't, the patch I attached obviously wouldn't work... >>> >>>If there are no objections, I'll commit this in a few days. >> >>Wouldn't it be simpler to just change t_src to always apply >>src->NegateBase? I can't see a need for that "src->NegateBase ? >>VSF_FLAG_ALL : VSF_FLAG_NONE", as the mesa parser sets all 4 bits anyway >>when "normal" instructions are parsed. The code would both be smaller >>and faster :-). (t_src_scalar OTOH cannot be changed.) > > > That won't work for NV vertex programs. nvvertparse.c sets NegateBase to > either GL_TRUE or GL_FALSE. > > If they'd use 0xf (== VSF_FLAG_ALL) and 0x0 as NV fp and ARB vp/fp do, > it would work indeed :) > Maybe nvvertparse.c should be changed? Setting a GLuint bitfield to > GL_TRUE seems a bit weird :) Good catch. The NegateBase field is meant to per-component. I'll fix the nvverparse.c code. The only instruction which can arbitrarily set individual bits of NegateBase is SWZ. For all other instructions, all four bits will either be set or cleared. -Brian -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] per-component negation for SWZ
Tilman Sauerbeck wrote: >>> If there are no objections, I'll commit this in a few days. >> Wouldn't it be simpler to just change t_src to always apply >> src->NegateBase? I can't see a need for that "src->NegateBase ? >> VSF_FLAG_ALL : VSF_FLAG_NONE", as the mesa parser sets all 4 bits anyway >> when "normal" instructions are parsed. The code would both be smaller >> and faster :-). (t_src_scalar OTOH cannot be changed.) > > That won't work for NV vertex programs. nvvertparse.c sets NegateBase to > either GL_TRUE or GL_FALSE. Ah right didn't think about support for NV_vertex_program. > If they'd use 0xf (== VSF_FLAG_ALL) and 0x0 as NV fp and ARB vp/fp do, > it would work indeed :) > Maybe nvvertparse.c should be changed? Setting a GLuint bitfield to > GL_TRUE seems a bit weird :) Yes a bit strange indeed. I think that's because NegateBase used to be a boolean once upon a time (nv_vp does not support extended swizzle). I think it should be ok to change. There are some references to NegateBase in nv_vp related files where that would make a difference, but I think that this is all unused code which tried to do arb_vp with the nv_vp code. Roland -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
The same libGL.so is being used in all cases, and I can't find any other on my system.1) line from glxinfo output:
OpenGL renderer string: Mesa DRI R300 20040924 AGP 1x x86/MMX+/3DNow!+/SSE TCL
2) line from ldd glxinfo:
libGL.so.1 => /usr/lib/libGL.so.1 (0xb7e6)
3) /usr/lib:
lrwxrwxrwx 1 root root 10 2006-05-30 23:35 /usr/lib/libGL.so -> libGL.so.1
4) line from strace quake2:
open("/usr/lib/libGL.so", O_RDONLY) = 8(that's the only libGL in strace log)PS. When I set "LIBGL_ALWAYS_INDIRECT" or unset "R300_FORCE_R300" I see Mesa version 6.4.2 (instead
6.5.1) in glxinfo-- Free Software - find interesting programs and change themNetHack - meet interesting creatures, kill them and eat their bodiesUsenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
On Tue, May 30, 2006 at 02:04:07PM -0700, Ian Romanick wrote: > Jacek Poplawski wrote: > >> It means that your r300_dri.so is *really* old. _glapi_add_dispatch was > >> removed from libGL months ago. > > > > But I just compiled it today... > > I've updated my Mesa CVS snapshot and used "make linux-dri-x86", then > > copied r300_dri.so. > > I have this symbol in 4 places: > > > > [EMAIL PROTECTED] ~/CVS/Mesa % grep -r _glapi_add_dispatch * > > src/mesa/glapi/glapi.c: * calls \c _glapi_add_dispatch we'll put in > > the proper offset. If that > > src/mesa/glapi/glapi.c:_glapi_add_dispatch( const char * const * > > function_names, > > src/mesa/glapi/glapi.h:_glapi_add_dispatch( const char * const * > > function_names, > > src/mesa/drivers/dri/common/utils.c:offset = > > _glapi_add_dispatch( functions, parameter_signature ); > > My mistake. _glapi_add_dispatch is the new function. The old function > was _glapi_add_entrypoint or something. It seems that the libGL that is > being used is too old. I seem to recall that Quake2 does a dlopen on > libGL, so you need to make sure that it's getting the right one. Either that, or the libGL is from fglrx. signature.asc Description: Digital signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
