Re: [Dri-devel] os-support/*/drm/kernel/drm.h
Philip Brown wrote:
How about moving
os-support/{linux,bsd}/drm/kernel/drm.h
into
os-support/shared/drm/kernel/drm.h
After all, it defines the core drm IOCTLS and data structures. It should be
common, not in OS-specific directories.
There are trivial differences between the two versions right now, that
could easily be merged. Right now, it seems as though the linux version
has a few extra structs, that arent being used in the BSD version. but that
should be no barrier for merging it.
Once that is done I can then submit a patch I have to make the header file
usable under solaris as well.
Does just moving the merged file work (ie will the users of the file pick it
up in it's new location), or is there a patch required to get this to work?
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Trunk-to-texmem merge
I suspect that will fix the texture problems. Somebody (that actually has Rage128 hardware!) should go through and eliminate the new_state field from r128_context altogether. I will make similar changes to the MGA driver. It would be nice to have fundamental things, like tracking state changes, as similar as possible across the various drivers. It makes it easier to move from driver-to-driver to fix bugs and make enhancements. This dates from Mesa 3.x where the mesa state tracking mechanism was designed around the software rasterizer useless for anything else. Keith --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
Brian Paul wrote: Felix Kühling wrote: On Mon, 2 Dec 2002 18:43:25 -0800 Allen Akin [EMAIL PROTECTED] wrote: On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote: | So if we agree on this, I would make this | controlled by an environment variable. ... The intent of the spec is that drivers should support whichever texture internal formats they wish to support, and apps should choose between them (or use the default only if they truly don't care). Environment variables aren't very portable, and work around the intent of the spec. Is there some compelling reason to use them, rather than just having the driver do what was intended? There was previously a dependency on the screen color depth when choosing the texture format in the radeon driver. I think that may have been a carry-over from the r128 (or tdfx?) driver which may not have allowed 32bpp textures when the screen was 16bpp (but I could be wrong). The environment variable I'm going to add would enable the user to override the bpp dependent default. I'm with Allen in preferring that we don't add yet another environment variable - especially for something which other OpenGL drivers haven't needed. Hmm. Windows drivers tend to have a GUI setup utility, which often has this sort of choice in it. That's the closest equivalent I can think of. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
I'm not sure that statement is accurate. On SGI, AIX, and Windows there are various tools to tune the operation of the OpenGL driver. On Linux we don't have any of that. Instead we've been using an ad-hoc collection of environment variables to control debug output, HW TCL operation, page flipping, refresh synchronization, and a ton of other stuff. Perhaps it's time we thought about doing something better? That would be a worthwhile project. Brian's chromium configuration tools highlight some 'clean' ways to do this: Basically make the drivers report their own configuration options, and build a single tool that can talk to the drivers and build a sensible gui to allow users to tweak the options. You'll need a config file somewhere, of course. Keith --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon: DMA buffer allocation leak
Felix Kühling wrote: On Mon, 2 Dec 2002 00:59:34 +0100 Felix Kühling [EMAIL PROTECTED] wrote: Hi, I reported a DMA buffer allocation problem earlier today with glean. It terminated with Error: Could not get dma buffer ... exiting. I looked into it a bit more now. I made a glean run with RADEON_DEBUG_DMA and wrote a small TCL script to analyse the output. It revealed a leak of DMA buffers. It might be a bug with my script, but I'm pretty sure it's ok. It is obvious that towards the end of the log only a subset of the available DMA buffers is used. [snip] I tracked it down to radeonDestroyContext. There radeonReleaseDmaRegion is called but after that the CmdBuf is never flushed. So when the context is destroyed any record of the last DMA buffer still being allocated is lost in the client. As glean destroys and recreates contexts quite often, all DMA buffers were lost like this. I think we introduced this problem when we moved the RADEON_FIRE_VERTICES further up in radeonDestroyContext. Before that RADEON_FIRE_VERTICES implicitly flushed the CmdBuf. Here is a patch that fixes the problem. I hope is doesn't introduce any new ones ;-) I've committed this... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon TCL global ambient problem solved
Felix Kühling wrote: Hi, my digging is starting to pay off ;) I had reported that weird problem, that the global ambient light is not correct using hardware TCL if I specify anything other than 1.0 as alpha component. Now I found out that the trigger for this problem is actually to specify the default of (0.2, 0.2, 0.2, 1.0). In that case Mesa is clever enough to not call the driver's LightModelfv functions as the value doesn't change. So the real error is that the global ambient is not set to the correct default value in the TCL state after turning on the ambient light. I fixed it by adding a call to update_global_ambient in radeonColorMaterial. Here is the one-line patch for completeness ;) --- radeon_state.c.~1.24.~ 2002-11-26 02:57:38.0 +0100 +++ radeon_state.c 2002-12-01 02:43:42.0 +0100 @@ -887,6 +887,7 @@ for (p = 0 ; p MAX_LIGHTS; p++) update_light_colors( ctx, p ); +update_global_ambient( ctx ); } } Committed this too. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
Felix Kühling wrote: Hi, I made two small modifications to the radeon driver to make OpenGL look much nicer with 16bpp. The first thing is to enable dithering, the second is to use 32bpp textures even in 16bpp mode, if the application requests them. A patch is attached. I've turned it on unilaterally, for 16 and 32 bit. This is consistent with the enable/disable code in radeon_state.c Maybe the texture color depth should be handled more intelligently in 16bpp mode, based on the amount of graphics memory or controlled by an environment variable? I think I'd want to see this sort of thing put in place, rather than the patch you posted which would increase the amount of texture memory required for some apps without giving the user a chance to counter that. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonFlushVertices restores the neutral vtxfmt wrapper
Felix Kühling wrote: Hi, while I was trying to understand the vtxfmt mesa code and poking around with gdb I noticed that the neutral vtxfmt wrapper gets restored quite often. I tracked it to radeonFlushVertices where _mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt ) is called if the FLUSH_UPDATE_CURRENT flag is set. _mesa_install_exec_vtxfmt in turn sets ctx-TnlModule.Current to the new exec vertex format and calls _mesa_restore_exec_vtxfmt( ctx ) which restores the neutral wrapper. Is this really what was intended here? The only place I could find where the FLUSH_UPDATE_CURRENT flag is set in the radeon driver is in radeon_vtxfmt_c.c and there the Exec dispatch table is modified directly. So there should be no need for reinstalling the vertex format. It is necessary to do that there. I can't bring an example off the top of my head, but feel free to remove the call play with the mesa demos. Something should break before too long... I guess I should have left a comment there to explain/remind myself why. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
Felix Kühling wrote:
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp mode, if the application
requests them. A patch is attached.
Maybe the texture color depth should be handled more intelligently in
16bpp mode, based on the amount of graphics memory or controlled by an
environment variable?
Regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
Index: radeon_state_init.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state_init.c,v
retrieving revision 1.6
diff -u -r1.6 radeon_state_init.c
--- radeon_state_init.c 25 Nov 2002 19:58:28 - 1.6
+++ radeon_state_init.c 1 Dec 2002 12:49:17 -
@@ -337,6 +337,8 @@
rmesa-hw.ctx.cmd[CTX_RB3D_CNTL] = (RADEON_PLANE_MASK_ENABLE |
color_fmt |
(115));
+ if (color_fmt == RADEON_COLOR_FORMAT_RGB565)
+ rmesa-hw.ctx.cmd[CTX_RB3D_CNTL] |= RADEON_DITHER_ENABLE;
I'm pretty sure this is OK, but can you check what happens to conform and/or
glean after doing this?
Glean is a sourceforge project, I'm not sure where you can download conform
from. If you can't find it, I'll do the conform check.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problems with new motherboard...
Adam K Kirchhoff wrote: Hello all, I recently upraded from an SMP VIA PIII motherboard to a UP Intel I845 P4 motherboard. So far, things have gone pretty smoothly (I've needed to upgrade to 2.4.20 to support the new ICH4 IDE controller). There are a few remaining issues I'm facing, and one of them has to do with the DRI: it locks up this machine solid. I have a Radeon 8500 which worked beautifully on the VIA motherboard. I have, of course, compiled agpgart with support for the i845, and it loads fine: agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected Intel i845 chipset agpgart: AGP aperture is 64M @ 0xd000 This afternoon I rebuilt and installed the entire DRI to see if that would solve the problem. It did not. Basically, if I run 'startx', the machine completely locks up. It no longer responds to pings, and the terminal I have from another machine (through kermit) is completely unresponsive. In fact, if I start 'tail -f /var/log/XFree86.0.log' from the terminal before I startx, *nothing* is printed out before the computer locks up. Interestingly, though, the FireGL drivers from ATI run just fine on this new motherboard. AGP Fast writes are a problem with the 845 - try turning them off if you've got them on. Similarly for other agp stuff. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
Felix Kühling wrote: On Fri, 29 Nov 2002 07:55:52 -0700 Brian Paul [EMAIL PROTECTED] wrote: [snip] Implementing a true threaded pipeline could be very compilicated. State changes are the big issue. If you stall/flush the pipeline for every state change you wouldn't gain anything. The alternative is to associate the GL state with each chunk of vertex data as it passes through the pipeline AND reconfigure the pipeline in the midst of state changes. Again, I think this would be very complicated. I see the problem. On many state changes, a corresponding driver function is called. In a parallel pipeline implementation, if there is still vertex data (with associated state) pending in the pipeline, it will be rendered by the driver with the wrong state. A proper solution would be to call the state-changing driver functions (or only UpdateState?) from within the pipeline, just before a driver stage is run. The required amount of modifications to mesas driver state management seems not too big. A quick recursive grep in xc/xc/extras/Mesa for ctx-Driver\.[[:alnum:]]*[[:space:]]*( finds 63 lines in 23 files. I found many state changing callbacks in dd.h which don't seem to be used. Are they left-overs from earlier Mesa versions or did my grep miss something? Which ones? Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk (Mesa-5.0): Some preliminary results on topof 2.5.49-mm1
Michel Dänzer wrote: On Mit, 2002-11-27 at 08:32, Dieter Nützel wrote: TaskParallelismWithPorts The colors of the polyhedron in the middle are missing. With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. Some small screenshots could be find in the archive. Sounds like a problem I'm seeing with the amoeba demo, some faces of a spinning cube (with the observer inside) are missing. RADEON_TCL_FORCE_DISABLE=1 fixes it, which wasn't necessary before the Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was already the case before the merge. These aren't the only reasons to check out amoeba, some parts of it are pushing quite hard performance wise, and it's simply fun to watch. :) I can't reproduce your other problems (they seem to be x86 assembler specific?), but I do see some problems with the Mesa demos (though it seems they were already there before the merge): fire: the fog seems to be much too dense around the initial direction, everything is almost white This is normal for per vertex fog. The ground plane is too big for the linear interpolation of fog coordinates across the polygon to give good looking results. gloss: artifacts with the initial highlight, goes away with SW TCL, seems to be the same problem as the ice in tuxracer This is a result of slight differences between geometry generated by software tl and hardware tl. The gloss cylendar is drawn in two passes, and the crawling you see is a result of differences between the passes. Some work could be done tweaking the vertices (z values?) emitted by swtcl to get a closer alignemnt. Otherwise, this isn't strictly a bug. GL doesn't require invarience at this level. pointblast: the points are always pixel sized Again, GL allows us to specify a maximum point size. For the radeon, thats set to 1.0 pixels as that's the largest size that the radeon can draw conformantly without sw fallbacks. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Ian Romanick wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/r128/
Changes by: idr@sc8-pr-cvs1. 02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
hardware. I will post to dri-devel to beg for help.
I fixed one trivial problem with turning on extensions (is that *strictly* a
texmem change, Ian?)
Now I've got this:
Program received signal SIGSEGV, Segmentation fault.
0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
802 move_to_tail( swapped, (driTextureObject *) texObj-DriverData );
(gdb) print swapped
$1 = (driTextureObject *) 0x8054e00
(gdb) print *swapped
$2 = {next = 0x8054e00, prev = 0x8054e00, heap = 0x0, tObj = 0x0,
memBlock = 0x0, bound = 0, totalSize = 0, dirty_images = {0, 0, 0, 0, 0, 0}}
(gdb) print texObj-DriverData
$3 = (void *) 0x0
It seems to be during initialization:
(gdb) bt
#0 0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
#1 0x4047ae70 in r128DDInitTextureFuncs (ctx=0x8056b18) at r128_tex.c:608
#2 0x404729b1 in r128CreateContext (dpy=0x80527f0, glVisual=0xb880,
driContextPriv=0x8054ca8, sharedContextPrivate=0x0) at r128_context.c:215
#3 0x40347fcc in driCreateContext (dpy=0x80527f0, vis=0x8053c28,
sharedPrivate=0x0, pctx=0x80562e4) at dri_util.c:849
#4 0x4010839a in CreateContext (dpy=0x80527f0, vis=0x8053c28, shareList=0x0,
allowDirect=1, contextID=0) at glxcmds.c:175
#5 0x4010849d in glXCreateContext (dpy=0x80527f0, vis=0x8053c28,
shareList=0x0, allowDirect=1) at glxcmds.c:212
#6 0x4002e72a in __glutCreateWindow () from /home/XF4/lib/libglut.so.3
#7 0x4002e9d6 in glutCreateWindow () from /home/XF4/lib/libglut.so.3
#8 0x0804b397 in main ()
#9 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
I'll have a look find out more.
Keith
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository:xc/xc/lib/GL/mesa/src/drv/r128/
Changes by:idr@sc8-pr-cvs1.02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
hardware. I will post to dri-devel to beg for help.
I fixed one trivial problem with turning on extensions (is that
*strictly* a texmem change, Ian?)
Now I've got this:
Program received signal SIGSEGV, Segmentation fault.
0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
802 move_to_tail( swapped, (driTextureObject *)
texObj-DriverData );
(gdb) print swapped
$1 = (driTextureObject *) 0x8054e00
(gdb) print *swapped
$2 = {next = 0x8054e00, prev = 0x8054e00, heap = 0x0, tObj = 0x0,
memBlock = 0x0, bound = 0, totalSize = 0, dirty_images = {0, 0, 0, 0,
0, 0}}
(gdb) print texObj-DriverData
$3 = (void *) 0x0
Well, there's nothing in r128BindTexture that tries to allocate
tObj-DriverData, so I'm either going to just put a guard in front of each of
those move_to_tail's, or perhaps not call the init function at all, since it
looks like a noop overall.
Keith
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk (Mesa-5.0): Some preliminary results on topof 2.5.49-mm1
Michel Dänzer wrote: First of all, thanks Keith for sharing your insights ( and Jens for the URL about locking ). On Don, 2002-11-28 at 13:31, Keith Whitwell wrote: gloss: artifacts with the initial highlight, goes away with SW TCL, seems to be the same problem as the ice in tuxracer This is a result of slight differences between geometry generated by software tl and hardware tl. The gloss cylendar is drawn in two passes, and the crawling you see is a result of differences between the passes. Some work could be done tweaking the vertices (z values?) emitted by swtcl to get a closer alignemnt. Otherwise, this isn't strictly a bug. GL doesn't require invarience at this level. I see. Do you have an idea on how to go about tweaking the vertices? There are a bunch of ways - tweak the zscale and zoffset viewport parameters but *ONLY* when hardware tcl is disabled (probably the best option?) - turn off _radeon_render_stage, and tweak the vertices as they are emitted in radeon_draw_triangle() and radeon_draw_quad(). These functions are now generated ty t_dd_triemit.c, so you'll have to dig a little. (might be the easiest for debugging). - Modify the vertices as they are generated by t_dd_vbtmp.h. There is facility in there for an additional viewport transformation, for instance. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk (Mesa-5.0): Some preliminary results on topof 2.5.49-mm1
Brian Paul wrote: Michel Dänzer wrote: First of all, thanks Keith for sharing your insights ( and Jens for the URL about locking ). On Don, 2002-11-28 at 13:31, Keith Whitwell wrote: gloss: artifacts with the initial highlight, goes away with SW TCL, seems to be the same problem as the ice in tuxracer This is a result of slight differences between geometry generated by software tl and hardware tl. The gloss cylendar is drawn in two passes, and the crawling you see is a result of differences between the passes. Some work could be done tweaking the vertices (z values?) emitted by swtcl to get a closer alignemnt. Otherwise, this isn't strictly a bug. GL doesn't require invarience at this level. I see. Do you have an idea on how to go about tweaking the vertices? I think this might be a red herring. Firstly, I doubt we'd ever get the h/w and s/w vertices to be identical in all situations. Secondly, any OpenGL implementation may display this artifact. I've personally seen this problem using a card which did both passes fully in hardware. The real answer is to use a polygon offset in the gloss demo. I'll look into fixing this. If tuxracer is drawing coplaner geometry with substantialy different state, it should also be using polygon offset. It is. However I wouldn't mind bringing things as close together as possible. It may be easier than we think. The three things I would investigate are: - small positive and negative offsets to Z - stripping out least significant bits from Z (this might be a requirement of the spec, in fact), by addding and then subtracting a large number to force the little bits off the end. - floating point Z buffers (more work). Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote: Ian Romanick wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/r128/ Changes by:idr@sc8-pr-cvs1.02/11/27 12:47:44 Log message: Initial pass at adding texmem support to Rage128 driver. These changes have not yet been tested as I don't have access to Rage128 hardware. I will post to dri-devel to beg for help. I fixed one trivial problem with turning on extensions (is that *strictly* a texmem change, Ian?) Now I've got this: Program received signal SIGSEGV, Segmentation fault. 0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00, targets=3) at texmem.c:802 802 move_to_tail( swapped, (driTextureObject *) texObj-DriverData ); Ian, OK, fixing that, there's more of the same stuff later. It seems there's an assumption that tObj-DriverData is always non-null, but that isn't actually the case. I'm not sure which way you want to fix this. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Anyone ever tried to rrmod radeon.o and then restartX, again?
Dieter Nützel wrote: 1. start X or system start (init 5) 2. rcxdm stop 3. rrmod radeon 4. restart X (rcxdm start) What happens: * Screen corruption in several upper lines (the KDE panel) * a copy of the graphical screen on console 1, 2, 3, etc. but without mouse or anything else but the command line works (!) without seeing it * Alt+F7 first graphics screen with mouse but nothing else working All branches so far. Initialization problem? I do this all the time and have never seen anything. I guess I insmod it again afterwards, but I doubt that makes much difference (compared to letting the X server do it) Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Software TNL line clipping doesn't work
Felix Kühling wrote: Hi, clipping of lines at the edges of the viewing volume doesn't seem to work. The problem occurs both with RADEON_TCL_FORCE_DISABLE and with LIBGL_ALWAYS_INDIRECT. If I use a glOrtho (-1.0, 1.0, -1.0, 1.0, -1.0, 1.0) projection this works: glBegin(GL_LINES); glColor3f(1.0, 0.0, 0.0); glVertex2f(0.0, 0.0); glVertex2f(0.5, 0.5); glEnd(); but this does not: glBegin(GL_LINES); glColor3f(1.0, 0.0, 0.0); glVertex2f(0.0, 0.0); glVertex2f(1.5, 0.5); glEnd(); With Radeon HW TCL both work. I've tried to dig into the mesa code. In the debugger I could see where the clipping And and Or masks are set, correctly as it seems (clip_test2 called from run_vertex_stage). But I couldn't find the place where the actual clipping is supposed to occur :( Have a look at #define RENDER_LINE in extras/Mesa/src/tnl/t_vb_render.c. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] full box lockup.
but... heres something that shows info about the error from yesterday: (please also see attached file, this is only an extract:) Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR* radeon_irq_emit called without lock held Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds heavyweight lock Can you remember how this happened? This is a real bug I'd like to track it down if possible. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] full box lockup.
Michel Dänzer wrote: On Son, 2002-11-24 at 18:39, Andreas Stenglein wrote: Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR* radeon_irq_emit called without lock held Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds heavyweight lock A friend of mine reported something like this (haven't seen it myself). For him, killing the DRI client(s) resumes normal operation. Can you confirm that? If so, that's not an actual lockup. I still can't really imagine what a 'heavyweight lock' is, can one of the traditional developers explain? It's really just the lock. The locking process is two stage, with a cmpxcg in userspace which can handle the trivial case (if the same context wants to get a lock and it was the last context to hold it) without kernel intervention. If that fails, the process has to do an ioctl to get the lock. This is where this message comes from -- maybe saying that '6' already has the lock it is asking for. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merge of mesa-41 branch to trunk
I think I found the problem. usleep() gets defined as a macro to xf86usleep() in xf86_ansi.h (via radeon_regs.h) and needs to be #undefined. Do we know why xf86_ansi.h is getting included in the client-side module? It's only intended for X server modules. It'd be better to not include it in the first place. I think because there is some sharing of source (radeon_regs.h is from the 2d driver). It should be protected with a #ifdef, I guess. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] full box lockup.
Roman Stepanov wrote: On 24 Nov 2002 18:19, you wrote: The meaning of this post, just a simple bug report. Sure it could be a leocad bug, but since the r200 drivers are highly in development i figured this is the place that's mostly interested. The r200 driver is basically done; it's not highly in development. -Brian I suggest using Loki's Rune demo for testing r200 driver. I have serious perfomance problems with Rune demo while playing Quake 3 is very smooth. My system is Athlon XP 1800+, 256 Mb RAM, XFree 4.2 + r200-20021117 driver, SuSE kernel 2.4.19-4G, glxgears shows about 2000 fps. A link, please? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] full box lockup.
Brian Paul wrote:
Andreas Stenglein wrote:
Here is a backtrace from gdb, its almost the same for the
app is dieing and xserver freezes.
when running xmms in gdb, the xserver doesnt freeze, only
the app. If you continue, one thread is dead, the other
keeps going!
But I had another thing: after restoring the xserver
with killall -KILL X and then init 3, init 5, a
switch to vt 1 for example locked up the whole machine
- reboot
app dieing:
[New Thread 4101 (LWP 4692)]
Delayed SIGSTOP caught for LWP 4692.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.
Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0 0x4032e861 in kill () from /lib/libc.so.6
#1 0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2 0x40033fd6 in raise () from /lib/libpthread.so.0
#3 0x4032fc81 in abort () from /lib/libc.so.6
#4 0x40328a52 in Letext () from /lib/libc.so.6
#5 0x41c1e6a9 in copy_dma_verts (rmesa=0x84505c0, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6 0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7 0x40f4f675 in _ts_Vertex3f (x=-0.328125, y=0, z=0.34375) at
../../../extras/Mesa/src/glapitemp.h:733
#8 0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9 0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit
xserver freeze:
[New Thread 4101 (LWP 4710)]
Delayed SIGSTOP caught for LWP 4710.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.
Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0 0x4032e861 in kill () from /lib/libc.so.6
#1 0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2 0x40033fd6 in raise () from /lib/libpthread.so.0
#3 0x4032fc81 in abort () from /lib/libc.so.6
#4 0x40328a52 in Letext () from /lib/libc.so.6
#5 0x41c1e6a9 in copy_dma_verts (rmesa=0x842d810, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6 0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7 0x40f4f675 in _ts_Vertex3f (x=-0.296875, y=0, z=-0.015625) at
../../../extras/Mesa/src/glapitemp.h:733
#8 0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9 0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit
The program is running. Exit anyway? (y or n) y
Could you try editing xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c
and remove or comment-out the assertion at line 325?
It looks like the problem is occuring when the buffer wraps on a vertex
emitted outside a begin/end pair.
I've attached a patch that deals with a couple of problems when this happens.
Can you give that a go?
Keith
Warning: Remote host denied X11 forwarding.
Index: radeon_vtxfmt.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c,v
retrieving revision 1.5
diff -u -r1.5 radeon_vtxfmt.c
--- radeon_vtxfmt.c 5 Nov 2002 21:19:52 - 1.5
+++ radeon_vtxfmt.c 26 Nov 2002 00:01:00 -
@@ -485,15 +485,21 @@
/* Copy vertices out of dma:
*/
- nrverts = copy_dma_verts( rmesa, tmp );
+ if (rmesa-vb.prim[0] == GL_POLYGON+1)
+ nrverts = 0;
+ else {
+ nrverts = copy_dma_verts( rmesa, tmp );
- if (RADEON_DEBUG DEBUG_VFMT)
- fprintf(stderr, %d vertices to copy\n, nrverts);
+ if (RADEON_DEBUG DEBUG_VFMT)
+fprintf(stderr, %d vertices to copy\n, nrverts);
+ /* Finish the prim at this point:
+ */
+ note_last_prim( rmesa, 0 );
+ }
- /* Finish the prim at this point:
+ /* Fire any buffered primitives
*/
- note_last_prim( rmesa, 0 );
flush_prims( rmesa );
/* Get new buffer
@@ -510,8 +516,11 @@
vb.notify = wrap_buffer;
rmesa-dma.flush = flush_prims;
- start_prim( rmesa, rmesa-vb.prim[0] );
+ /* Restart wrapped primitive:
+*/
+ if (rmesa-vb.prim[0] != GL_POLYGON+1)
+ start_prim( rmesa, rmesa-vb.prim[0] );
/* Reemit saved vertices
*/
Re: [Dri-devel] radeon_ioctl.c: INREG() usage
Brian Paul wrote: Michel Dänzer wrote: On Mon, 2002-11-25 at 23:21, Brian Paul wrote: There are two places in radeon_ioctl.c where the INREG() macro is used to read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG). It looks like these have been superceeded by drmCommandWriteRead() calls (since the 11 July check-in of Tim Smith's changes). INREG is probably only used if the kernel module is too old to support the RADEON_LAST_- CLEAR/FRAME queries. It would be nice if those two instances of INREG() could be removed. I suppose we need to keep them for the sake of users of older radeon.o kernel modules. Is there more to it than that? I don't see any other reason, the registers are only read directly if there's a problem with the ioctl. I know Eric used to frown at the idea of using an ioctl to get a register value though. :) This is (apparently) the only place in the whole driver where we directly access a hardware register. It's the only reason we need to drag in the (new) radeon_macros.h file, which in turn pulls in a number of other server-side XFree86 headers. It would be nice to eliminate that. The only way you can eliminate it is if you opt to forgo client-side throttling on old kernel modules. At the moment the radeon driver is broken with old kernel modules anyway, but that should be fixed presently. In the r200 driver we print an error and exit if the drmCommandWriteRead() fails. I think that should never happen if the kernel module is new enough to support the query. I don't know the radeon.o version number which corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query. The query was added *before* r200 support was added to the kernel, so there's never a case where an r200 can be running with a kernel module that doesn't support the query. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon_ioctl.c: INREG() usage
Michel Dänzer wrote: On Mon, 2002-11-25 at 23:21, Brian Paul wrote: There are two places in radeon_ioctl.c where the INREG() macro is used to read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG). It looks like these have been superceeded by drmCommandWriteRead() calls (since the 11 July check-in of Tim Smith's changes). INREG is probably only used if the kernel module is too old to support the RADEON_LAST_- CLEAR/FRAME queries. It would be nice if those two instances of INREG() could be removed. I suppose we need to keep them for the sake of users of older radeon.o kernel modules. Is there more to it than that? I don't see any other reason, the registers are only read directly if there's a problem with the ioctl. I know Eric used to frown at the idea of using an ioctl to get a register value though. :) It's not even that: We're using an ioctl to read a value *in main memory*... If we were smart it would be in a shared page accessible from userspace... Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
Its a known issue for me, thats why i do prefer the GLUT demos. I made it to bring the Mesa demos to life on DRI by just editing the libGL and other references to the systems defaults rather than to the libs in the project. As far as i do remember, it all turned out to be rather static in linking. To my knowledge there is no simple way with this project build system for getting what we both do think of. Hmm. Howabout 'make -f Makefile.X11 linux' from the demos directory? May need to 'make -f Makefile.X11 realclean' first to clean up. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mesa-4-1-branch)
Brian Paul wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/ Changes by: brianp@usw-pr-cvs1. 02/11/15 16:13:59 Log message: Modified functions in __DriverAPIRec to remove unneeded Display * parameters, etc. Generally try to reduce number of X dependencies within the driver code. Added driMajor/Minor/Patch fields to __DRIscreenPrivateRec and call XF86DRIQueryVersion in dri_util.c instead of in all the drivers. Lots of #include clean-ups. Brian, Are there any forward/backward compatibility issues raised by this change? We currently don't distribute libGL.so in the snapshots. However, I'm not averse to doing so, as long as new libGL.so's can be made to work with old driver.so's. Keith --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
Ian Molton wrote: On Fri, 15 Nov 2002 11:39:55 +0100 (CET) Martin Spott [EMAIL PROTECTED] wrote: Im awaiting a PCI Voodoo3 at the moment... Sorry, I didn't make it this week. It will get shipped on monday, No rush - I wasnt criticising, just making the statement so people would know I intend to have a crack at Voodoo3 support and not drop any code on the floor. The tdfx driver's texture code is pretty different to the other drivers, so it may not fit as well in the texmem model as the rest. I don't know, but just a heads up. One major difference is that glide seems to keep it's own copy of the texture, so we don't need to. I don't think that you can tell it not to, either. Keith --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
If I do that, in glxinfo it only shows up in the 'client glx extensions', which makes sense given the way I'm doing it. In the Nvidia driver, it shows up in both 'client glx extnesions' and 'GLX extensions'. Evidently, NVIDIA supports the extension for indirect rendering too. NVIDIA's indirect renderer is the same as their client renderer - ie they're both hw accelerated and both (afaik) the same piece of code. Keith --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Clamp or wrap with scale?
Ian Romanick wrote: On Tue, Nov 12, 2002 at 09:34:38AM -0800, Ian Romanick wrote: I was monkeying around with DOT3 bumpmapping in SW Mesa and in the Radeon driver. In both cases, when a scale (either 2x or 4x) is applied, the resulting colors wrap. However, I noticed that in the Nvidia driver (for Linux) clamps in the same situation. Which is correct? Both? I see that the Radeon has a bit to enable clamping, and the R200 has two different clamp modes (CLAMP_0_1 CLAMP_8_8). If clamping is correct, it should be trivial to enable in the two drivers that support DOT3 bumpmapping. As usual, I answered my own question. From second paragraph of page 153 (page 166 of the PDF) of the 1.4 spec: If the value of TEXTURE_ENV_MODE is COMBINE, the form of the texture function depends on the values of COMBINE_RGB and COMBINE_ALPHA, according to table 3.24. The RGB and ALPHA results of the texture function are then multiplied by the values of RGB_SCALE and ALPHA_SCALE, respectively. The results are clamped to [0,1]. Therefore, the R100, R200, and software fallback is wrong. I will make the change to the R100 driver. I'm guessing that I'll just set the clamp bit and be done with it. I'll have to read the rest of the spec to see if the clamp bit should always be set or just for COMBINE. I think it will probably always be clamped. I've never seen anything about colors wrapping in the spec. Keith --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Glaxium...
Ian Romanick wrote:
On Thu, Nov 07, 2002 at 09:09:06AM -0800, Ian Romanick wrote:
On Thu, Nov 07, 2002 at 07:48:55AM -0800, Ian Romanick wrote:
On Wed, Nov 06, 2002 at 11:41:00PM +0100, Dieter Nützel wrote:
Am Mittwoch, 6. November 2002 23:23 schrieb Adam K Kirchhoff:
Hello all,
These two links show screenshots of glaxium on two separate
machines, one with an r100 (original 64 Meg Radeon) and one with an r200
(Radeon 8500).
http://memory.visualtech.com/glaxium-r100.png
http://memory.visualtech.com/glaxium-r200.png
You may notice that, quite frankly, the floor looks much nicer on
the r100 than on the r200. Can anyone explain why this would be the case?
Shouldn't the r200 support all the same extensions as the r100?
Broken textures in the r200 branch?
Have you tried with TCL disabled?
Please try both with parsec. I see some texture corruption with the r200
there, too.
I know that glaxium is, but is parsec using DOT3? If so, I believe that may
be the problem. I know that the R200 driver doesn't handle the scale factor
correctly for ARB_texture_env_dot3 (it always uses a 1x scale). However, I
don't think /that/ by itself would cause that problem. If that were the
case, then it would run unbearably slow on R100 (using a non-1x scale causes
a sw fallback on R100).
Actually, I found the bug. The R200 driver exports EXT_texture_env_dot3,
but the GL_COMBINE case in r200UpdateTextureEnv (r200_texstate.c) doesn't
have cases for the GL_DOT3_{RGB,RGBA}_EXT enums. The _EXT version *IS*
different (and has different enums) than the ARB/OpenGL 1.3 version.
Adding case-statements for the _EXT enums everywhere there's a non-EXT enum
should fix the problem, modulo the incorrect implmentation of the non-EXT
version mentioned above. There was some discussion of this a couple months
ago WRT the R100 driver.
Okay. I'm going to fix this in the texmem branch. I need somebody to
verify that the R200 has a 16x scale factor. It should be:
#define R200_TXC_SCALE_16X (48)
In the spec it lists this value as 'reserved'. Try it anyway...
Keith
---
This sf.net email is sponsored by:
To learn the basics of securing your web site with SSL,
click here to get a FREE TRIAL of a Thawte Server Certificate:
http://www.gothawte.com/rd522.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon M9 DRI patch (Was: Radeon 900 Trials and Tribulations)
D. Hageman wrote: I have a solution to why I was running into problems with getting my Radeon 9000 in my laptop working. One of those things that when you realize what is going on - you feel really silly ;-) The issue was that it wasn't using the r200 driver, but rather the standard radeon driver - which will *not* work. The r200 driver seems to work fairly well. I haven't done any major benchmark or testing, but it does render to the screen and most importantly - it doesn't hard lock my laptop. Attached is an addition to Scott Harrison's patch for the Radeon 9000 that will add CHIP_FAMILY_M9 to the list of chipsets that can use the r200 driver. Note: This diff is from the most recent unified ATI driver in the main XFree86 trunk, so the line numbers may be off a couple of lines for the DRI tree. OK, I've committed this. Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Michel Dänzer wrote: On Die, 2002-11-05 at 09:41, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-11-04 at 21:11, Ian Romanick wrote: On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote: http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png [...] It's definitely the depth buffer running amok. If I move the texture region about 10 scanlines further away from it, no corruption occurs. Any ideas as to why this could happen appreciated, and why it doesn't happen on the x86 box at work, where the texture region is adjacent to the depth buffer. Access to the depth buffer is tiled, which means that pixel (x,y) isn't necessarily at (x,y), but could be some distance up or down from there. It may be that the region we're allocating for the depth buffer which would be large enough if it were all layed out linearly, but isn't large enough for the tiles. It's worth investigating as we've seen similar problems elsewhere. Ah, tiling. I couldn't find any juicy info about it in the docs, but reading the depth buffer access functions in radeon_span.c, it seems that it basically partitions the buffer into blocks of 16 lines, which are scrambled somehow? Correct me if I'm wrong, otherwise I'll commit http://penguinppc.org/~daenzer/DRI/radeon-depth-size.diff , which Works For Me (TM). Looks good. Can you also cast an eye over the r200_span.c equivalents to make sure 16 is the number for r200 as well? Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Michel Dänzer wrote: On Mon, 2002-11-04 at 21:11, Ian Romanick wrote: On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote: Just tried it for the first time because I hoped it would help with the texture problems seen in http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png Well, it does seem to change the behaviour, but not only for the good. While the problems occur randomly with the trunk code, mostly on the first runs after the server was started, with the texmem code they never seem to happen with tuxracer, but always with bzflag and quake2. Also, I don't think I've seen this on x86, anyone? Any idea what's up? Could you try this with the environment variable RADEON_AGPTEXTURING_FORCE_DISABLE set? One of the changes for the R100 in the texmem branch is that AGP texturing is enabled. This env. var. will disable it. Doesn't make a difference; if it did, I wouldn't see the problem on the trunk (but I've tried anyway for you :). The texmem branch hasn't introduced the problem but made it 100% reproducible, which is good. It's definitely the depth buffer running amok. If I move the texture region about 10 scanlines further away from it, no corruption occurs. Any ideas as to why this could happen appreciated, and why it doesn't happen on the x86 box at work, where the texture region is adjacent to the depth buffer. Access to the depth buffer is tiled, which means that pixel (x,y) isn't necessarily at (x,y), but could be some distance up or down from there. It may be that the region we're allocating for the depth buffer which would be large enough if it were all layed out linearly, but isn't large enough for the tiles. It's worth investigating as we've seen similar problems elsewhere. Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] doh...
Missed the meeting last night. Can anyone summarize or post a log? Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Michel Dänzer wrote: On Son, 2002-11-03 at 17:06, Keith Whitwell wrote: Michel Dänzer wrote: Just tried it for the first time because I hoped it would help with the texture problems seen in http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png Well, it does seem to change the behaviour, but not only for the good. While the problems occur randomly with the trunk code, mostly on the first runs after the server was started, with the texmem code they never seem to happen with tuxracer, but always with bzflag and quake2. Also, I don't think I've seen this on x86, anyone? Any idea what's up? BTW, would it be feasible to do all texture uploads via blits from AGP instead of the clumsy method we're using? Might improve upload performance and even make swapping out to AGP a nop in some cases... Yes, providing the kernel version is able to support the cmdbuf ioctl. Brian's actually done a bit of work on the Mesa-4.1 branch to clean up the code behind the actual upload (yes, sorry another branch...) that probably goes a long way to addressing your complaints. Seems to be about the same as the trunk, what has changed? In r200_texmem.c, Brian's cleaned up the *usage* of the old ioctl to be a bit cleaner easier to understand (as well as being able to cope with compressed textures). I guess this is only partway to what you'd like, but it makes it easier to see how to take the next step. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Michel Dänzer wrote: On Mon, 2002-11-04 at 13:06, Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2002-11-03 at 17:06, Keith Whitwell wrote: Michel Dänzer wrote: Just tried it for the first time because I hoped it would help with the texture problems seen in http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png Well, it does seem to change the behaviour, but not only for the good. While the problems occur randomly with the trunk code, mostly on the first runs after the server was started, with the texmem code they never seem to happen with tuxracer, but always with bzflag and quake2. Also, I don't think I've seen this on x86, anyone? Any idea what's up? BTW, would it be feasible to do all texture uploads via blits from AGP instead of the clumsy method we're using? Might improve upload performance and even make swapping out to AGP a nop in some cases... Yes, providing the kernel version is able to support the cmdbuf ioctl. Brian's actually done a bit of work on the Mesa-4.1 branch to clean up the code behind the actual upload (yes, sorry another branch...) that probably goes a long way to addressing your complaints. Seems to be about the same as the trunk, what has changed? In r200_texmem.c, Brian's cleaned up the *usage* of the old ioctl to be a bit cleaner easier to understand (as well as being able to cope with compressed textures). I guess this is only partway to what you'd like, but it makes it easier to see how to take the next step. Ah, so the r100 driver is unchanged there? I'll look into moving the changes over, but it would probably be easier for Brian or you... Meanwhile, I've made some funny experiments. The bzflag problem happens reproducibly on the first run after the X server was started, and then seemingly randomly. Or maybe not so: I kept starting bzflag and exiting immediately, and it seems to happen exactly every 21 times! Perhaps to do with the global lru? I'm not sure how many big 'chunks' there are in there (depends on your card size, resolution, blah blah), but 21 is conceivable, and it's quite possible that allocation cycles through each one in turn. Maybe there's some correlation there, like maybe upload always overdraws and 1/21 times you get the end chunk and the overdraw maybe scribbles the ring, or some other fairy tale with a similar ending. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon M9 DRI patch (Was: Radeon 900 Trials and Tribulations)
D. Hageman wrote: I have a solution to why I was running into problems with getting my Radeon 9000 in my laptop working. One of those things that when you realize what is going on - you feel really silly ;-) The issue was that it wasn't using the r200 driver, but rather the standard radeon driver - which will *not* work. The r200 driver seems to work fairly well. I haven't done any major benchmark or testing, but it does render to the screen and most importantly - it doesn't hard lock my laptop. Attached is an addition to Scott Harrison's patch for the Radeon 9000 that will add CHIP_FAMILY_M9 to the list of chipsets that can use the r200 driver. Can you forward Scott's patch as well, I can't seem to find it. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Ian Romanick wrote: On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote: Just tried it for the first time because I hoped it would help with the texture problems seen in http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png Well, it does seem to change the behaviour, but not only for the good. While the problems occur randomly with the trunk code, mostly on the first runs after the server was started, with the texmem code they never seem to happen with tuxracer, but always with bzflag and quake2. Also, I don't think I've seen this on x86, anyone? Any idea what's up? BTW, would it be feasible to do all texture uploads via blits from AGP instead of the clumsy method we're using? Might improve upload performance and even make swapping out to AGP a nop in some cases... If you're using anything other than R100-class or MGA, then there have been no changes to the code in the texmem branch from when I create the branch. I've been patiently waiting for somebody with the various other DRI supported hardware to make the changes. Good thing I'm not holding my breath while I wait... :) Sorry Ian, work gets in the way sometimes. I haven't had much time at all lately. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Sorry Ian, work gets in the way sometimes. I haven't had much time at all lately. Yeah, I know. It just sucks for me because I know pretty much exactly what needs to be done, but I can't really do it because I don't have access to all the different hardware. Not to worry, I have plenty of other things to keep me busy too. :) Ian, If you wanted to actually do the changes and commit them to that branch, it would save me a lot of time figuring it out could then just verify if it worked, and do some debugging if things go wrong. I think this would lead to getting it done more quickly than otherwise. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem branch
Michel Dänzer wrote: Just tried it for the first time because I hoped it would help with the texture problems seen in http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png Well, it does seem to change the behaviour, but not only for the good. While the problems occur randomly with the trunk code, mostly on the first runs after the server was started, with the texmem code they never seem to happen with tuxracer, but always with bzflag and quake2. Also, I don't think I've seen this on x86, anyone? Any idea what's up? BTW, would it be feasible to do all texture uploads via blits from AGP instead of the clumsy method we're using? Might improve upload performance and even make swapping out to AGP a nop in some cases... Yes, providing the kernel version is able to support the cmdbuf ioctl. Brian's actually done a bit of work on the Mesa-4.1 branch to clean up the code behind the actual upload (yes, sorry another branch...) that probably goes a long way to addressing your complaints. Yes, the old code was 'orrible. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Issues w/Viewperf 7 drv-08?
Ian Romanick wrote: I'm running Viewperf for the first time. The drv-08 test doesn't look right to me using the R100 driver. For most of the test, the screen is totally black. When there is something on the screen, it looks like the far clip-plane isn't set quite right. It does NOT look like this w/LIBGL_ALWAYS_INDIRECT set. Ideas? Ian, I haven't downloaded viewperf 7 yet. Can you detail your experiences building running it apart from this bug? IE: Is it going to be a pita to get running, and if so, any helpful hints? Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage and nVidia DRI drivers
Alan Cox wrote: On Thu, 2002-10-31 at 15:58, José Fonseca wrote: I don't know much about SIS 6326. I know that there is some deprecated (it hasn't been updated for the architectural changes) support for SIS 630 chips on the CVS. 6326 is much older than 630 and 315 etc. Its in the PIO with very small fifo category of devices. I've got the 3Dfx docs, and also some info on the bugs (you have to verify the stream as things like misordered triangle verticies kill the chip) On voodoo-1, even vertices that aren't snapped to 1/16th(?) subpixel coords will crash it... Hmmm, you can't do fp in the kernel, right? Keith --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New frame throttling patches
Felix, I've cleaned up the WaitForFrameCompletion function a bit committed. The logic is slightly different, but a lot easier to read/understand, I think. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New frame throttling patches
Felix Kühling wrote: On Tue, 29 Oct 2002 13:23:22 + Keith Whitwell [EMAIL PROTECTED] wrote: Felix, I've cleaned up the WaitForFrameCompletion function a bit committed. The logic is slightly different, but a lot easier to read/understand, I think. Ok, I just think that the name rmesa-irqsEmitted is now a bit misleading (can't think of a better one, though). Agreed, I can't either. And you removed the delay loop. I remember reading a comment like don't hammer the bus in the old code. And by removing the delay loop you also eliminated the cause for the IRQ/busy ping ponging. So the irqsEmitted magic should be no longer necessary. The delay loop is eliminated by modern versions of gcc anyway. The irqsEmitted magic is still necessary to avoid the (first) busywait, which I'd like to do. It basically says: If I have to emit an irq for this frame, then don't try to do without them for at least 9 more frames. This should stop the pingponging in all but very marginal situations, and then it won't be more than 1 pingpong per 10 frames. Finally, if do_irqs is disabled you alsways use usleeps. But I assume it's your intention to never do real busy waiting. No - there's an 'if (rmesa-do_usleeps)' protecting all relevent uses of usleep, I think. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] stable branch created
I've created a stable-1-0-branch as a tag from alan's pre-xf4.3-merge tag 'trunk-20021022'. This will be the site for the first stable binary snapshot, and will target XFree86 4.2.x installations. I haven't done anything more than create the branch at this stage. Before releasing the binary, we have at least one compatibility issue to fix (libxaa.a). Does anyone have any others? Reide, if you're reading, if you wanted to build a preliminary snapshot from that branch, using rh7.3, that would be useful, I think. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New frame throttling patches
Felix Kühling wrote: Hi, here is a new set of frame throttling patches for the radeon and r200 drivers. It implements a second chance strategy to avoid ping-ponging between busy waiting and IRQ waiting with very high frame rates. Felix, do you have versions of these that apply cleanly to the trunk? R200 in particular. Keiht --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: pageflipping CRTC{,2}_OFFSET_{,CNTL}
Michel Dänzer wrote:
http://penguinppc.org/~daenzer/DRI/radeon-pageflip.diff
is an attempt to fix the following pageflipping issues:
* the 2D driver clobbers the CRTC{,2}_OFFSET_CNTL registers when
switching modes; as a consequence, flips only take place on the
next vertical blank, so you can see the back buffer being drawn to
* the 2D driver AdjustFrame() function doesn't take the current page
into account
* the DRM doesn't take the viewport position into account, so the
viewport is always reset to the upper left on a flip
* the DRM doesn't handle CRTC2 (for CloneMode)
I can't fully test it, people who have reported any of these items (in
particular Jacek Rosik IIRC :) please give it a spin and let me know if
it helps.
Looks basically ok to me...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
Ian Romanick wrote: On Fri, Oct 25, 2002 at 10:39:23AM -0600, Jens Owen wrote: I've heard you and others talk about triple buffering a few times, and I'm wondering if you can fill me in on a few details. Is the primary motivation for a 3rd buffer to aliviate delays associated with vertical refresh? Using a page swapping method, I would guess the pointers for front, back and display buffer would look like: Yes, that is a very nice summary of triple buffering. You've also caught on to the potential problem with it. If your frame rate exceeds your refresh rate, you're toast. Only if you sync to vertical refresh. I wouldn't propose that... From my point of view it's a scheme to make pageflipping work on hardware where the pageflip command isn't instantaneous. When this is the case you have to wait on the pageflip, which is boring, or start rendering immediately (a clear to the new backbuffer, which is still being displayed, which is bad), or have a third buffer to look at --- triple buffering. Keith --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
Ian Romanick wrote: On Fri, Oct 25, 2002 at 06:19:14PM +0100, Keith Whitwell wrote: Ian Romanick wrote: On Fri, Oct 25, 2002 at 10:39:23AM -0600, Jens Owen wrote: I've heard you and others talk about triple buffering a few times, and I'm wondering if you can fill me in on a few details. Is the primary motivation for a 3rd buffer to aliviate delays associated with vertical refresh? Using a page swapping method, I would guess the pointers for front, back and display buffer would look like: Yes, that is a very nice summary of triple buffering. You've also caught on to the potential problem with it. If your frame rate exceeds your refresh rate, you're toast. Only if you sync to vertical refresh. I wouldn't propose that... From my point of view it's a scheme to make pageflipping work on hardware where the pageflip command isn't instantaneous. When this is the case you have to wait on the pageflip, which is boring, or start rendering immediately (a clear to the new backbuffer, which is still being displayed, which is bad), or have a third buffer to look at --- triple buffering. That's basically what we said. :) You're still toast if you render too fast. I remember running into this problem when I was demo coding on the Amiga back-in-the-day. I used triple buffering in my 3D demos so that I never had to wait for the retrace. Then I upgraded from my Amiga 500 (7.14MHz 68000) to an Amiga 3000 (25MHz 68030) and all hell broke loose. Here's the problem... Time step 1: - Buffer 0 is being displayed (front buffer / display buffer). - Buffer 1 is the render buffer (back buffer). Time step 2: - Finish rendering to buffer 1, and queue it to be displayed on the next frame (front buffer). - Buffer 0 is still being displayed. Vertical beam is, say, 1/3rd of the way down the screen now (display buffer). - Buffer 2 becomes the render buffer (back buffer). Time step 3: - Finish rendering to buffer 2, and queue it to be displayed on the next frame (front buffer). - Buffer 0 is still being displayed. Vertical beam is, say, 2/3rd of the way down the screen now (display buffer). - Buffer 0 becomes the render buffer (back buffer). Time step 4: - Hey! What happened to the bottom of my display?!? Let me tell you what, that took a long time to debug! Notice that this is exactly the same problem as in the double buffer case if you don't wait for the retrace. The sollution was to use a vblank interrupt to (basically) fence the buffers, though I didn't know the term 'fence' at the time. You still /might/ have to wait, but only if you have a very high frame rate. That's why I only saw the problem after increasing my CPU speed by a factor of 10. :) Ah, yes I see where you're coming from -- basically in that case you need to throttle the frame rate anyway -- we already have mechanisms for this, but they may need beefing up if we ever do triple buffering. Keith --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Disabling certain fast paths
Malte Cornils wrote: On Thu, Oct 24, 2002 at 01:31:14AM +0200, Malte Cornils wrote: Is there any way I could help in a different way, maybe you could guess something after looking at a screenshot? If you supply a patch, I promise I'll test it, of course. With TCL it's way faster :-) BTW, I've put up two screenshots, one with the problem/TCL, one without. They're 1 MiB each, since I used lossless compression. Also, the green patches are sometimes of different colour on some textures, and they flicker back to normal occasionally. http://studsun1.ira.uka.de/~s_malte/nwn_tcl.png http://studsun1.ira.uka.de/~s_malte/nwn.png Hmm. Looks like depth fighting, but that doesn't make much sense as I wouldn't expect there to be multipass rendering going on here. In any case what output is produced when you run with 'R200_DEBUG=fallback' ? Keith --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible multiple glx context bug
I just tried this with RADEON_TCL_FORCE_DISABLE=1, RADEON_NO_VTXFMT=1 and RADEON_NO_CODEGEN=1 and I can still reproduce the bug. Are any other bells ringing? No, now there's just hard work... Keith --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible multiple glx context bug
Ian Romanick wrote: On Wed, Oct 23, 2002 at 12:27:57AM +0200, Charl P. Botha wrote: On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote: On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote: Run glthreads with something like: glthreads -n 5 Here's an additional data point. If you move the call to glXDestroyContext to the end of draw_loop (and delete the other two calls), the program works as expected on the Radeon. The event_loop won't terminate, but I leave fixing that trivial bug as an exercise for the reader. :) Hrmmm, interesting. The reason I made this is to reproduce a bug in a much larger application where that kind of control (taking glxDestroyContext() INto the thread) is quite difficult. Ian, do you consider this to be a bug? It's a bug somewhere. :) I'm going to have to dig more before I can determine if the bug is in the app, the driver, or both. Brian or Keith: Do either of you have an opinion about this? Certainly a bug. First thing of concern is whether it's the vtxfmt/codegen stuff which isn't threadsafe, but should get turned off at the first sign of multithreading. Keith --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Disabling certain fast paths
Malte Cornils wrote: Hi, I'm having a visual problem with an application (NWN under Wine) - it works fine with LIBGL_ALWAYS_INDIRECT=true but displays the problem (some textures flicker and show wrong colours) with hardware-accelerated r200. How can I selectively disable/enable hardware acceleration for certain OpenGL operations so that I can narrow this down? Is there an environment variable for this? How can I find out what extensions my app uses, or failing that, what extensions are even available? Or do I need to compile DRI-enabled Xfree86 myself? There are a few chunks of functionality that you can disable via environment variables: 'R200_NO_VTXFMT' and 'R200_NO_TCL' are the big ones. Beyond that, you will have to look at the code. I'd recommend especially looking at the 'FALLBACK' macro, and the functions in r200_state.c. Keith --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: quads rendered too small
Michel Dänzer wrote: On Son, 2002-10-13 at 17:54, Michel Dänzer wrote: I've done some more clueless digging into the problem visible in http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and http://penguinppc.org/~daenzer/DRI/celestia.jpeg . My first suspicion was an off-by-one error in the scissor code, but enlarging the scissor rectangle doesn't help; making it smaller makes the problem worse though, so the scissor code seems to be correct. So the quads actually seem to be rendered one pixel too small in both directions; Actually not. The problem with the evas demo is that the Radeon can't seem to cope with infinity for texture coordinates (the demo doesn't render just one quad per background tile, but four of 'em, three having infinity for some texture coordinates; those aren't rendered). The first attached patch fixes that, but is a bit awkward; better ideas anyone? Fix the application. I'm pretty sure we're allowed to bin vertices containing bogus float values. As for the text in celestia, that's fixed by the second patch, which I'll commit soon unless someone sees a problem with it. It has the colormaterial change which I said earlier I believe is incorrect. Additionally when changing things like subpixel offsets, please run both glean and conform to verify that you haven't broken these tests (there are bugs with both, but fiddling with subpixel can break them totally). Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Xpert]SIGFPE in Radeon 7500 DRI support
This comes up so often (once a week?) that I think we should change the name of the function to gl_test_os_katmai_exception_support_SIGFPE_is_expected_just_ignore_it(). And we should rename radeon_cp_get_buffer while we're at it. Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
Ian Romanick wrote: Over the past year an issue of OpenGL versioning has come up a few times. Basically, we have conflicting goals of wanting to advertise OpenGL 1.3 or 1.4 but not wanting to advertise extensions that aren't hardware accelerated (cube textures and shadow maps come to mind). I believe that a solution exists, but it will require some trivial changes to Mesa. Basically, we advertise whatever OpenGL version we want (assuming that the driver knows how to fall-back for unsported functionality), but only advertise extension strings for functionality that is hardware accelerated. For example, advertise version 1.2, but only advertise GL_EXT_texture3D in the extension string if it's hardware supported. This may sound silly, but I think it's a good compromise. It turns out that this is what Nvidia does. That's not to say that Nvidia is always right, but I think this is better than being stuck back at 1.2. :) Does GL_EXT_texture3D still work, even though it's not listed? If not, that takes all the hard work out of advancing mesa -- no need to code stuff up, just bump the version number... Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
Ian Romanick wrote: From what I have been told, this is how it works on the Nvidia drivers. I have not verified this first hand. if ( extension string contains GL_EXT_texture3D ) 3D textures are hardware accelerated else if ( advertised OpenGL version = 1.2 ) 3D textures are a software fallback else 3D textures are not supported at all So, a TNT will advertise OpenGL version 1.2 but not GL_EXT_texture3D. 3D textures will work, but they will be sw rendered. On whichever Geforce supports 3D textures in hw, OpenGL version 1.2 AND GL_EXT_texture3D would be advertised. It's not a perfect system, but it fixes most of the cases where an app checks the extension string to see of some feature is supported in hardware and gets an upleasant surprise from a sw fallback. It does seem semantically richer than the standard way of doing things. I wonder if the spec gives some wiggle room on this. Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
Alexander Stohr wrote: From what I have been told, this is how it works on the Nvidia drivers. I have not verified this first hand. if ( extension string contains GL_EXT_texture3D ) 3D textures are hardware accelerated else if ( advertised OpenGL version = 1.2 ) 3D textures are a software fallback else 3D textures are not supported at all Nice sheme - this will even allow to check the software paths by just tuning the GL version (e.g. via environment variable). But what will you do if your software path is not yet covered by a specific OpenGL version but you still want to use it for testing your experimental application? It doesn't help us much with that case, it's true. However we don't have that capability with the current scheme either. Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] PCIGART Radeon AIW support
James Fung wrote: Thanks. The PCI radeon seems to work fairly well actually: OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/3DNow! TCL OpenGL version string: 1.2 Mesa 4.0.4 glxgears gives 1000 frames in 5.0 seconds = 200.000 FPS I've tried going through the Mesa demos and they seem to run OK, however I've only ever seen them run on the Radeon so far so I don't really know what I'm supposed to see. I also tried tuxracer - the ice patches seem to flicker (especially at the edges of the ice patches where the textures seem to flicker in and out), and there seems to be a similarly odd flicker/flash on the gloss.c mesa demo. These are known issues with the radeon driver. They're not really bugs as the behaviour is within GL spec, but we'd all rather it didn't happen. --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm When did sourceforge start doing this? Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm_write_string: debug, or neccessary?
Philip Brown wrote: I note that the apparent sole purpose for drm_write_string() is to record context switches in a buffer, which can be read by processes doing userland read() calls on the drm dev. Is this for debug purposes only? Probably. I didn't know it was there... Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa 4.1 branch
Russ Dill wrote: On Tue, 2002-10-15 at 10:01, Stefan Lange wrote: Q3A: stable (at least for the time I tested), but not very fast. In fact it shows the same symptoms I got with earlier versions of DRI-trunk (before around 2002-10-11): poor overall speed, and a framerate that maxes out at 50 FPS. Is the r200-code in your branch from before that date? If yes, that would explain the behaviour. This speed problem is somehow related to displaying the players weapon, or status. If you are playing q3a, and switch to free fly mode, the fps jumps to around 100-250fps That makes sense. The speed problem comes from agressively throttling glClear() operations. Q3 does multiple clears of the backbuffer for drawing the little floating head and I don't know what else in the status bar. So, I expect the speed to go up after a trunk merge. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa 4.1 branch
hmm, that's odd. I still get floating point exceptions for almost every GL-app. with TCL disabled. Demos that _do_ work with TCL disabled include: clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos Maybe this can give you a clue, why some are working and some aren't? Could I have messed something up during checking out/compiling/installing that is causing these FPE's? Try running under gdb posting a strack trace. Note that there will be an initial fpe during sse detection -- this is normal and you have to hit 'c' to continue past it. Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
Michel Dänzer wrote: On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). [...] One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I may have stumbled upon this one, see the attached patch. Unfortunately, this doesn't fix the black roofs in bzflag, I wonder if it helps with flightgear... Index: radeon_state.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state.c,v retrieving revision 1.18 diff -p -u -r1.18 radeon_state.c --- radeon_state.c 25 Aug 2002 22:24:39 - 1.18 +++ radeon_state.c 12 Oct 2002 01:24:14 - @@ -885,7 +885,7 @@ void radeonUpdateMaterial( GLcontext *ct GLuint mask = ~0; if (ctx-Light.ColorMaterialEnabled) - mask = ~ctx-Light.ColorMaterialBitmask; + mask = ctx-Light.ColorMaterialBitmask; The old code is correct -- if colormaterial is enabled, then calls to glMaterial should only affect the bits of the material that aren't being covered by colormaterial. In other words, the colormaterial should reflect the current color - anything set by glMaterial is instantly overrided by the current color. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon snapshots, assertio failures and segfaults
A. H. Gee wrote: Hi everyone, Hopefully a useful data point: the radeon nightly snapshots now work for me as long as I use Jose's libxaa.a. Without the new libxaa.a, I get the much reported blank screen. Looks like we need to bundle libxaa.a with the nightly backups. The radeon driver works fine most of the time, but still falls over with our medical imaging application. This differs from the usual OpenGL game in that it has multiple popup windows with multiple GL contexts. There are two symptoms: (a) Repeatable assertion failures as follows: radeon_vtxfmt.c:1045: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. This one is well documented and I believe near the top of Keith's todo list! A workaround is RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1. (b) More sporadic (but not rare) segfaults, which nothing seems to work around. Seemed to be introduced some time in August, I don't get these with the 1 August snapshots. Here's a debug trace, showing that this one too is to do with destroying contexts in the multiple context applications: Program received signal SIGSEGV, Segmentation fault. 0x4207adb8 in chunk_free () from /lib/i686/libc.so.6 (gdb) where #0 0x4207adb8 in chunk_free () from /lib/i686/libc.so.6 #1 0x4207ac24 in free () from /lib/i686/libc.so.6 #2 0x4051dd08 in _mesa_extensions_dtr (ctx=0x84c4988) at extensions.c:351 #3 0x4050523a in _mesa_free_context_data (ctx=0x84c4988) at context.c:1723 #4 0x4050527f in _mesa_destroy_context (ctx=0x84c4988) at context.c:1738 #5 0x4062191d in radeonDestroyContext (driContextPriv=0x8445308) at radeon_context.c:575 #6 0x404f05ff in driDestroyContext (dpy=0x8170878, scrn=0, contextPrivate=0x8445308) at dri_util.c:762 #7 0x4005c7df in __glXFreeContext () from /usr/X11R6/lib/libGL.so.1 I've just looked over this code and it seems ok. Probably what is happening is something else, somewhere else, is being free'd twice, or freed without being allocated. This will usually corrupt the internal datastructures used by free/malloc result in a crash later on, like the above. As for tracking it down, try ElectricFence, or even Purify if you have access to it (I think I heard they do a linux version now)... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Radeon 8500 woes...
Adam Duck wrote: Joe == Joe Mackay [EMAIL PROTECTED] writes: Joe On Thu, 10 Oct 2002, Frank Van Damme wrote: www.student.kuleuven.ac.be/~m9917684/r200-20020920-linux.i386.tar.bz2 should work. Joe Brilliant... thanks, you're a star! Joe Working fairly well now, apart from Xv. Just have to wait until it's as Joe good as the NVidia driver ;-) Well, I managed to run the newest binary snapshots by installing the newest r200-snapshot (yesterday) and copying radeon_drv.o from 0924 into my XFree-dir. It works. I even have Xv. That leads me to another question: what exactly is in radeon_drv.o? That's the 2d driver. It also does some 3d initialization, including turning on interrupts. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa 4.1 branch
I've tested the radeon, r200 and tdfx drivers and they seem OK. I can't test the i810, i830, r128, mga, etc drivers (either because I don't have the right hardware or mine's broke). Some of the other drivers (like sis, ffb, etc) aren't enabled in the build process and haven't been ported. I'm not sure what the status of those drivers is. I've got most of these. I'll have a test fest later on. If I'm lucky I can do Ian's changes at the same time. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa viewport transformation and depth scaling
José Fonseca wrote:
The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth
test. After assuring that the mach64's z control register was being set
properly I realized that the vertex buffers had the z in a [0,1] scale
while the primitive drawing functions expected them in a a [0,0x].
The previous mach64 (mesa 3.x) driver defined the coord setup as
#define COORD \
do {\
GLfloat *win = VB-Win.data[i]; \
v-v.x = win[0] + xoffset; \
v-v.y = - win[1] + yoffset; \
v-v.z = win[2]; \
v-v.rhw = win[3]; \
} while (0)
while for example the R128 defined as
#define COORD \
do {\
GLfloat *win = VB-Win.data[i]; \
v-v.x = win[0] + xoffset; \
v-v.y = - win[1] + yoffset; \
v-v.z = depth_scale * win[2]; \
v-v.rhw = v-v.rhw2 = win[3]; \
} while (0)
So I removed the 'depth_scale' in calculation of hw_viewport, in
mach64CalcViewport, and everything worked fine.
But I still don't understand what's the relationship between
*CalcViewport and the viewport calculations made in _mesa_set_viewport.
At _mesa_set_viewport, for instance, there is a comment that says This
is really driver-specific and should be maintained elsewhere if at
all.. It seems that _mesa_set_viewport sets the scale to [0,MaxDepth],
but the *CalcViewport in most DRI drivers undo this scaling, rescaling
to a [0,1].
Correct. The _mesa_set_viewport code is really setting things up for how the
software rasterizer likes it's coordinates. In the Mesa 3.x days, Mesa would
multiply things by the viewport (giving VB-Win), whether you wanted them or
not, then you'd have to undo it with code like the above. Now, the driver
still 'fixes up' the viewport, but at least it doesn't have to do it per-vertex.
My question is why the other DRI drivers do this (don't the chips expect
the depths in integer format as well?) and in what depth scale should
the vertex buffers be after all?
No, there's a good mixture. Some want floats scaled to certain values, lots
want floats in 0..1, all sorts of things.
This understanding would be important because the current mach64
triangle setup engine is able to specify the z values in 16.1 format,
but only the 16 integer part is being used, so I would like to implement
that as well.
Basically the responsibility for the viewport transformation has been shifted
to the driver. You don't see it because it's hidden in the t_dd_vbtmp (?)
template, but it's the driver that really does it.
So, you can take ndc coords (VB-ProjectedClipPtr), and manipulate them to
whatever twisted format the hardware likes.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa viewport transformation and depth scaling
José Fonseca wrote: Keith, I'm curious to know how you reminded after so long (7 months)! Did you actually writed it now or was it stuck in a mail queue all this time? By now I got to more or less to those answers, but thanks anyway. As saying goes: it's better late than never! Oh. It was highlighted in my browser as a new piece of mail. Maybe I did that by accident... Oh well... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon_drv.h
Tom Hosiawa wrote: What exactly is drm_radeon_depth_clear_t storing; is it registers on the card having something to do with the way depth buffers get used??? If you look at where it's used, you get a clue that these are register values: OUT_RING_REG( RADEON_RB3D_ZSTENCILCNTL, depth_clear-rb3d_zstencilcntl ); However, some explanation might help: Radeons can (with the docs we have) only clear the depth buffer via the 3d engine -- by drawing a quad with z-testing disabled, a planemask so no colors get drawn, and various other state set the right way. The register values stored in drm_r_d_c_t are the values needed to set the card into a state to draw the quad. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] waiting for anoncvs_dri's still there ;-(
Brian Paul wrote: Dieter Nützel wrote: cvs update M xc/config/cf/host.def M xc/config/cf/xf86site.def M xc/config/cf/xfree86.cf P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c cvs server: [16:53:25] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:53:55] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:54:25] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:54:55] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs [update aborted]: received interrupt signal Any glue? I'm stuck on this too. I think that sourceforge has a cron job that goes through and deletes stale cvs locks (once per day). Hopefully it'll be OK tomorrow. Last time I had to raise a support ticket on the sourceforge site. There's even something that says 'there is no automated process for removing these locks'. I'll do this now. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] waiting for anoncvs_dri's still there ;-(
Keith Whitwell wrote: Brian Paul wrote: Dieter Nützel wrote: cvs update M xc/config/cf/host.def M xc/config/cf/xf86site.def M xc/config/cf/xfree86.cf P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c cvs server: [16:53:25] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:53:55] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:54:25] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs server: [16:54:55] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw cvs [update aborted]: received interrupt signal Any glue? I'm stuck on this too. I think that sourceforge has a cron job that goes through and deletes stale cvs locks (once per day). Hopefully it'll be OK tomorrow. Last time I had to raise a support ticket on the sourceforge site. There's even something that says 'there is no automated process for removing these locks'. I'll do this now. Actually, having said that, it seems to have been cleared! Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Ian Romanick wrote:
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
{ARB,IBM}_texture_mirrored_repeat (but it could), but R100 does. Currently,
both the the paletted texture extensions are disabled in the MGA driver. We
should probably also add a note that only AGP Radeons (R100 R200) are
supported on x86. Somebody should probably also add a line for PowerPC.
With regards to SGIS_generate_mipmap, is there any reason we can't enable
that on all hardware? Even for the hardware where it is enabled, it uses
the sw fallback.
But why?
Apps might prefer to have no mipmaps than have them generated by (slow)
software. In this case, advertising the string is misleading.
Apps which want mipmaps regardless will *have* to have a fallback path
themselves, so apps that care will already know how to do this when the
extension isn't advertized.
Overall, this 'false advertising' doesn't aid one class of apps, and confuses
another...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm_os_linux.h: max() macro?
Brian Paul wrote: in drm_os_linux.h in the DRM_WAIT_ON macro there's: schedule_timeout(max(HZ/100,1)); \ Where is max() supposed to be defined? It's undefined when I compile here. Replacing it with: schedule_timeout((HZ/100 1) ? HZ/100 : 1);\ Sounds reasonable to replace it. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New r100 waiting patch
Felix Kühling wrote: Hi Keith, I attached a new r100 waiting patch against the latest trunk. I assume that you have the most up-to-date r200 waiting code in your tree. I added EAGAIN to conditions handled gracefully. But I couldn't find any situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using grep on .../linux/drm/kernel). Is that just a precaution for future changes in the ioctl? I've had reports of it on FreeBSD. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New r100 waiting patch
Felix Kühling wrote: Hi Keith, I attached a new r100 waiting patch against the latest trunk. I assume that you have the most up-to-date r200 waiting code in your tree. I added EAGAIN to conditions handled gracefully. But I couldn't find any situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using grep on .../linux/drm/kernel). Is that just a precaution for future changes in the ioctl? Felix, Does this patch address the irq/busywait pingponging that was happening last time? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Xpert]512x512 OpenGL Texture for ATI 7500 Mobility?
Brian Paul wrote: Keith Whitwell wrote: Ti Leggett wrote: There seems to be a 512x512 OpenGL texture size limit for ATI 7500 Mobility. There's a game I'm helping test and it uses textures over 1024x1024 and they work on a regular ATI 7500 but don't on a 7500 Mobility. 512x512 textures do work though. Any ideas why this is? It's not a hardware limitation because the same game runs fine @ 1024x1024 textures under windows. Thanks! The maximum texture size is scaled down according to how much memory you have. There are games out there (quake 2, iirc) that don't behave correctly without this. It may be a behaviour that's outlived it's usefulness however -- it's not required by the GL spec at all. I'm not sure I understand. We should advertise GL_MAX_TEXTURE_SIZE such that N textures of that size can be accomodated (where N = num texture units). OK, That's what we do. I didn't realize it was a requirement, however, I just did it to make q2 work properly many years ago. The windows driver probably is using agp texturing to fit the larger textures in, which we should do also. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
Ian Romanick wrote:
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
One option is to have the kernel actually do the fixup of the buffers when
they are submitted by the client, so the driver never knows really where it's
textures are, but talks about them via. some indirection.
I've been looking into this to assess the difficulty of such an
implementation. The back patching would be done in radeon_emit_state /
radeon_emit_packets, yes?
In radeon_emit_packets you have some code like:
if ( packet is RADEON_PP_TXFILTER_? or R200_PP_TXOFFSET_? )
{
texture_id = data[ offset_of_texture_id ];
address = address of texture_id;
if ( address is not in texturable memory )
{
address = get space for texture;
copy_texture( from user memory to address );
}
data[ offset_of_texture_id ] = address of texture_id;
}
Is that basically what you had in mind? There would be similar code in
radeon_emit_state.
Yes, effectively. The only other choice is to have the client emit data about
where to find values in the command stream that need to be fixed up.
Ignoring issues of SGIS_generate_mipmaps or glCopyPixels for a moment, a
system like this would need some sort of fencing. Basically, reference
counting for packets that set a texture. When a texture is bound to a
texture unit, increment the counter. When another texture is bound, put a
command in the stream to trigger an interrupt. When the interrupt is
received, decrement the counter. If the counter is zero, then the texture
is not in use and can be taken out of memory.
Interrupts are much to expensive to use each time a texture is bound... It
will be necessary to think about this at a lower time frequency, or find some
mechanism other than irq's to acheive it.
This would also allow proper synchronization of glTexSubImage?D.
This also raises the question of NV_fence. If we go down this path, we will
have already implemented most of the infrastructure for NV_fence. Should we
go the final mile and export it?
We should do this anyway.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200: new and exciting crash
Andy Dustman wrote: I managed to get the r200 driver working again by doing a complete CVS install. Some notes: * The card does now seem to generate interrupts at about the same frequency as the current mode's vertical refresh. * Surprisingly (for me, at least), glxgears is now running at about 2000+ fps and consuming about 70% CPU. I expected a lower frame rate (equal to vertical refresh) and minimal CPU usage, but my expectations may be unrealistic. * Quake3 still crashes after a few minutes, but with an error I haven't seen before: r200WaitForFrameCompletion: drmRadeonIrqWait: -16 It did this on two separate occasions. Machine locks up, although I believe on one occassion SysRq still worked. * Setting R200_DEBUG=sanity and running glxgears *immediately* locks the machine hard with no output. Hmm. What happens if you pipe the output to a file? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) pro blems
Felix Kühling wrote: On 03 Oct 2002 11:01:57 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: On Don, 2002-10-03 at 01:52, thork wrote: about the aperture thing, he told me those 8Mb where from system memory not from the video card memory, I found this thing in the log: (--) RADEON(0): VideoRAM: 65536 kByte (64-bit DDR SDRAM) and ofcourse the other lines next: (II) RADEON(0): Using 8 MB AGP aperture but when I load the agpgart modules it says: Sep 30 14:18:32 thork kernel: agpgart: AGP aperture is 64M @ 0xf800 This is the upper limit for the AGP aperture size the DRI can use. the 480FPS on glxgear where using 24bits of color, now the CVS thing is giving me 500FPS ... but come on! ITS A RADEON 7000! Yes, exactly. ;) No hardware TCL (well, actually some VEs do seem to have that, you can try the RADEON_TCL_FORCE_ENABLE environment variable if you're desperate for more fps, but be warned that it will lock up if it doesn't work with your chip). Also, try to enable page flipping if you haven't already. That's funny: without TCL glxgears is slightly faster on my Radeon 7500! Just the CPU usage is higher. With TCL I get 864 FPS (about 14% CPU usage), without TCL it's 872 FPS (about 22% CPU). That should make some sense if you think about it. Because you aren't using 100% cpu, you know that in some way the card is the limiting factor. By turning off tcl you are unloading work from the card, thus perhaps making its life easier allowing it go faster... But really, the difference is so small that it probably doesn't mean anything at all. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
Ian Romanick wrote:
On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
- Do we really need the 3 in radeon_vtxfmt_c.c:
static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
{
- GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)1];
+ GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)3];
dest[0] = s;
dest[1] = 0;
}
If we don't need the mask, then the AND instructions should be removed
from the assembly stubs in radeon_vtxtmp_x86.S as well.
We definitely need something here. This code must not crash for bogus values
of target, but the behaviour is otherwise undefined. In the above code you'd
want to set up a bogus value for texcoordptr[3] to point to some temporary
storage, or anywhere at all, really. An alternative is a guard like:
if (target - GL_TEXTURE_0_ARB 3)
which is slightly more work when looking at the codegen templates.
I've made some changes (and a discovery) here, and I should have a new
version of the patch out for people to review either later today or
tomorrow. My discovery is that the '- GL_TEXTURE0' is useless. The value
for GL_TEXTURE0 is 0x84C0. The low order 5 bits are all 0. For any of the
possible valid values for target, subtracting GL_TEXTURE0 is the same as
masking with 0x1F. Masking with 0x1F followed by a mask with 0x03 (or
0x01) is redundant.
My vote is to change the 2-TMU version (in all 6 places) to:
static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
{
GLfloat *dest = vb.texcoordptr[target 1];
dest[0] = s;
dest[1] = 0;
}
Neat!
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) pro blems
Could it be that the AGP bus is the limiting factor and pushing TCL vertices requires more bandwidth than just pushing rasterization info? Maybe, but the difference Felix reports (1%) might as well be noise. Sorry, I know we shouldn't even get into it regarding gears...it's not a benchmark. Okay, everyone go back to their corners and repeat: Gears is not a benchmark Gears is not a benchmark Gears is not a benchmark It is a benchmark - for glClear() and glXSwapBuffers() only. That's why it benefits so much from page flipping. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 GL_NV_vertex_array_range allocator
Karl Rasche wrote: Attached is a patch to attempt to duplicate the r200 agp allocator, independant of any one particular drivers' code. Also, is a quick implementation for the mga driver. Hopefully I went about this in a somewhat correct mannor. If not, please let me know... Thanks. karl [k a r l r a s c h e] We have no tolerance for dysfunctional PC's, and are swift to employ the floor [EMAIL PROTECTED] tool as a method of extracting the meaty nut-pulp contained within XT cases and old phone systems --accrc.org My first question, I haven't looked at the code properly yet, is about ioctl numbers. Where are they coming from? How do we avoid overlapping with the driver-specific ioctl numbers? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Felix Kühling wrote:
Keith,
you got the condition for waiting for an interrupt wrong.
r200_ioctl.c, line 330
...
/* if there was a previous frame, wait for its IRQ */
- if (iw-irq_seq != -1 sarea-last_frame r200GetLastFrame( rmesa ) ) {
+ if (iw-irq_seq != -1 r200GetLastFrame( rmesa ) sarea-last_frame ) {
UNLOCK_HARDWARE( rmesa );
ret = drmCommandWrite( fd, DRM_RADEON_IRQ_WAIT, iw, sizeof(*iw) );
...
OK, fixed.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
I definitely running this on my dual Athlon with latest ACPI for 2.4.19 and irq's routing enabled, I think. With procinfo -f I see ~980 irq/sec during gears. Same with r200 code from yesterday. But it was much faster. I think I may have fixed your problem (thanks to Felix), can you try again? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 GL_NV_vertex_array_range allocator
Karl Rasche wrote: My first question, I haven't looked at the code properly yet, is about ioctl numbers. Where are they coming from? How do we avoid overlapping with the driver-specific ioctl numbers? From what I gather from drm.h, the driver specific ioctls are supposed to begin at 0x40. The highest general ioctl I saw was 0x39, so I assumed there was room for a few more without having to juggle the driver ioctl range. OK. I think we should make a note of this -- it looks like device-independent ioctl numbers are somewhat limited. I guess we can start moving downwards from whatever the top of the range is, too. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [patch] r200 smart frame throttling
Felix Kühling wrote: Hi r200'ers, here is the improved frame throttling for r200. It compiles on my system. Time for testing ... I still get a lot of busy waiting with this patch. I assume the behaviour is the same on the radeon. Run it against 'multiarb' from the mesa demos. Every second frame is busy waited, and cpu load is high. The original irq_wait patch didn't have this behaviour, and I've committed a version of that on the r200 now. Keith --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Dieter Nützel wrote: Keith, after your latest r200 IRQ merge setenv R200_NO_USLEEPS 1 is badly needed, again? gears is lower than ever Mesa/demos ./gears r200CreateScreen 550 frames in 5.019 seconds = 109.584 FPS 566 frames in 5.016 seconds = 112.839 FPS 574 frames in 5.004 seconds = 114.708 FPS 590 frames in 5.006 seconds = 117.859 FPS Sounds like you aren't getting irq's, for some reason, and it is falling back to busy waiting. The question is why aren't you getting irq's? Keith --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200_MAX_CLEARS vs R200_MAX_OUTSTANDING
Felix Kühling wrote:
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The corresponding radeonClear uses a macro RADEON_MAX_CLEARS. There is a
macro R200_MAX_CLEARS defined in r200_ioctl.c, too. But it is never used.
Did I step on a bug here? Should I change this to
if ( rmesa-sarea-last_clear - clear = R200_MAX_CLEARS ) {
break;
}
If you want. I think the number should be '1' in both cases. I don't really
see the need for a macro, even, as we've pretty much narrowed down the only
acceptable value.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200_MAX_CLEARS vs R200_MAX_OUTSTANDING
Brian Paul wrote:
Felix Kühling wrote:
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The corresponding radeonClear uses a macro RADEON_MAX_CLEARS. There is a
macro R200_MAX_CLEARS defined in r200_ioctl.c, too. But it is never used.
Did I step on a bug here? Should I change this to
if ( rmesa-sarea-last_clear - clear = R200_MAX_CLEARS ) {
break;
}
Regards,
Felix
What's the story with throttling in glClear? I hope we're not using
glClear as a frame counter of some sort. Applications don't necessarily
have to call glClear at all. Other apps may call glClear several times per
frame.
No, this is code by Gareth, I think, to deal with apps like 'clearspd' that
just queue up clears in a tight loop. Without throttling, the behaviour is bad.
However, I can think of a dozen different ways to get similar bad behaviour
without calling glClear either.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Felix Kühling wrote: On Sun, 29 Sep 2002 23:25:03 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: Am Sonntag, 29. September 2002 22:57 schrieb Felix Kühling: On Sun, 29 Sep 2002 22:47:47 +0200 Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository:xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by:keithw@usw-pr-cvs1. 02/09/29 13:22:44 Log message: irqwait patch from felix Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: radeon_context.c radeon_context.h radeon_ioctl.c Revision ChangesPath 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See [patch] smart irq/busy wait in radeonWaitForFrameCompletion on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Oops, forgot one debug message. Could you remove fprintf (stderr, Waited %d.\r, wait); from radeon_ioctl.c line 692 manually? I don't want to spam the list with patches. Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Sure. As far as I could see the code is very similar. However, this: rmesa-do_irqs = (0 rmesa-dri.drmMinor = 6 !getenv(R200_NO_IRQS) rmesa-r200Screen-irq); looks like IRQs are turned off by default on R200. So my code wouldn't be used. Is the reason for IRQs being disabled that the frame throttling is not implemented properly or are there lower level problems with IRQs? No, this is a hangover from the bugs last week. It can be removed now. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch: IRQ_WAIT in radeonFinish
Felix Kühling wrote:
Hi,
I was able to reduce CPU usage of applications which use glFinish by
emitting and waiting for an IRQ in radeonFinish before
radeonWaitForIdle. I'm not sure whether radeonWaitForIdle is still
needed after waiting for the IRQ, but keeping it does at least not hurt.
The patch is attached.
One more thing: Since radeonWaitForFrameCompletion uses IRQs there are
no more lag problems. Because the IRQ emit is the last thing on the ring
all frames are finished when the IRQ is received. So checking for
MAX_OUTSTANDING in a loop is no longer necessary in that case, right?
Best regards,
Felix
Felix, I'd prefer to leave that code as it is for now. Specifically, I'd
like to see a situation where the irq's are used to allow at most 1 frame
outstanding, whereas they currently allow zero, which I believe is suboptimal.
The code is a simple test of irqs should either stay as it is, or get fixed
properly.
I like the patch below, however. There's no need for the WaitForIdle any
more, I think.
Keith
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
Index: radeon_ioctl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c,v
retrieving revision 1.24
diff -u -r1.24 radeon_ioctl.c
--- radeon_ioctl.c25 Sep 2002 17:20:30 - 1.24
+++ radeon_ioctl.c28 Sep 2002 13:32:57 -
@@ -1090,6 +1090,29 @@
{
radeonContextPtr rmesa = RADEON_CONTEXT(ctx);
radeonFlush( ctx );
+ if (rmesa-do_irqs) {
+ int fd = rmesa-dri.fd;
+ int ret;
+
+ drmRadeonIrqEmit ie;
+ drmRadeonIrqWait iw;
+
+ ie.irq_seq = iw.irq_seq;
+
+ LOCK_HARDWARE( rmesa );
+ ret = drmCommandWriteRead( fd, DRM_RADEON_IRQ_EMIT, ie, sizeof(ie) );
+ if ( ret ) {
+ fprintf( stderr, %s: drmRadeonIrqEmit: %d\n, __FUNCTION__, ret );
+ exit(1);
+ }
+ UNLOCK_HARDWARE( rmesa );
+
+ ret = drmCommandWrite( fd, DRM_RADEON_IRQ_WAIT, iw, sizeof(iw) );
+ if ( ret ) {
+ fprintf( stderr, %s: drmRadeonIrqWait: %d\n, __FUNCTION__, ret );
+ exit(1);
+ }
+ }
radeonWaitForIdle( rmesa );
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] snapshots
Should we stop producing snapshots temporarily until the xaa/compiler/who-knows-what problems are resolved? There seem to be a lot of complaints about the ones up there now... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch: IRQ_WAIT in radeonFinish
Felix Kühling wrote: On Sat, 28 Sep 2002 14:56:38 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: Hi, I was able to reduce CPU usage of applications which use glFinish by emitting and waiting for an IRQ in radeonFinish before radeonWaitForIdle. I'm not sure whether radeonWaitForIdle is still needed after waiting for the IRQ, but keeping it does at least not hurt. The patch is attached. One more thing: Since radeonWaitForFrameCompletion uses IRQs there are no more lag problems. Because the IRQ emit is the last thing on the ring all frames are finished when the IRQ is received. So checking for MAX_OUTSTANDING in a loop is no longer necessary in that case, right? Best regards, Felix Felix, I'd prefer to leave that code as it is for now. Specifically, I'd like to see a situation where the irq's are used to allow at most 1 frame outstanding, whereas they currently allow zero, which I believe is suboptimal. Ok, what do you think about this one? It waits for the IRQ emitted in the previous call to WaitForFrameCompletion and emits a new one to be waited for the next time. It relies on the implementation of radeon_wait_irq which returns immediately if the irq you're waiting for has allready occured. So I don't have to worry about checking if I missed the IRQ. I tested it with and without page flipping. Q3 and Torcs looked a bit jerky before, but now they run perfectly smooth. Using a static variable doesn't cut it -- that should go into the radeonContext struct in radeon_context.h. Beyond that, it would be *nice* if the irq never happened unless we thought that we were in danger of out-racing the card. I don't really have a good scheme to detect that situation -- perhaps every once in a while go back to the busy waiting case, and only start emitting irq's if you ever actually have to wait. That's a little complex, perhaps... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: radeonWaitForFrameCompletion with IRQs
Felix Kühling wrote: On Sat, 28 Sep 2002 16:31:56 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: [snip] Using a static variable doesn't cut it -- that should go into the radeonContext struct in radeon_context.h. Beyond that, it would be *nice* if the irq never happened unless we thought that we were in danger of out-racing the card. I don't really have a good Is emitting an IRQ really costlier than busy waiting? Good question. I really don't know. scheme to detect that situation -- perhaps every once in a while go back to the busy waiting case, and only start emitting irq's if you ever actually have to wait. That's a little complex, perhaps... Ok, I think it can be done. However, we would react to load changes with one frame delay. Before I go on amusing people with another naive patch, I'll explain my idea. If you think it's ok, I'll go ahead implementing it, this time using radeonContext instead of a static variable ;) radeonContext would contain the irq_seq number and a boolean specifying whether there is an IRQ to wait for. If there is none, we have to do busy waiting. If we wait for an IRQ we check first, whether the last frame has already been completed. If so, we don't have to wait. In both cases (busy waiting and IRQ), if we did really wait, we emit an IRQ guessing that it will be the same next time. radeonContext is updated accordingly. To avoid switching the waiting scheme all the time we could switch to IRQ waiting only if we had to do at least N usleeps. This sounds good. I'm looking forward to see if you can implement it without things getting too ugly. In the meantime, why don't you send me a tested version of your earlier patch, modified to keep 'irq_seq' in rmesa. I'll commit it. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: On Don, 2002-09-26 at 18:17, Keith Whitwell wrote: Michel Dänzer wrote: Something else I've been thinking about is that relying on the swi_emitted and swi_received counters being in sync is pretty fragile. It might be better to use a scratch register instead. Yes, it could be made more robust. Do you think the approach with a scratch register is good? Yep, but I guess you have to worry about then going to sleep *after* the interrupt has arrived, if there is a delay in getting the scratch write across the bus, compared to the irq, which should be instantaneous. ... We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out what has happened -- particularly have the interrupts been disabled? Turns out they haven't. GEN_INT_CNTL looks exactly like it should. Interestingly, the GEN_INT_STATUS bits are set as well, and acknowledging them helps. So it seems that somehow, the service routine didn't get called for an interrupt, or the acknowledgement got lost. If the updated patch works for you as well, I'll commit it. The patch doesn't seem to do anything about this case, just print something out... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] (r200) AGP Fast Write disabled by default
Stephane Chauveau wrote: Hi, The r200 dri drivers are working fine on my system but I noticed something strange in my logs: (**) RADEON(0): Using AGP 4x mode (II) RADEON(0): AGP Fast Write disabled by default My bios says that AGP Fast Write is enabled. Is there an issue with AGP Fast Write and the r200? I couldn't find anything about AGP fast write in XFree86 documentation but I assume that if it is 'disabled by default' then there should be a way to enable it. Option AGPFastWrite 1 I think there are problems with some motherboards, i845 in particular... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
It's a big hack to be doing this. I'd really like to know why this happens, So would I. I suspect it's a workaround for some problem, it worked fine here without. (as I said on IRC yesterday: but then I have sane hardware :) but in the mean time I'm ok to see it go in. Okay, I'll commit it later tonight. Maybe I should be more pedantic about things... Well, I'd rather you wouldn't be speaking in riddles. Just about committing code that is a hack-around without really understanding what's going on. I think it's more or less inevitable, however, with all the different bits of hardware interacting with each other us in the middle trying to sort it out. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
