Re: [Dri-devel] mach64 dri on freebsd 5.2
On 8 Mar 2004 [EMAIL PROTECTED] wrote: Leif Delgass [EMAIL PROTECTED] writes: I forgot to bring in the drm_linux_list.h for bsd that was added on the mach64-0-0-6-branch. I just added it and it is included from drmP.h. With any luck that should fix the compile errors in the kernel module. ok, thank you again, that does fix the compile errors in the kernel module. I built the module, and loaded it: # kldstat | grep mach64 51 0xc4e88000 15000mach64.ko # ls -l /dev/dri/card0 crw-rw-rw- 1 root wheel 145, 0 Mar 8 08:08 /dev/dri/card0 I set my ld path to point to the new gl libs: # setenv LD_LIBRARY_PATH /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/:$LD_LIBRARY_PATH # ldd which glxinfo /usr/X11R6/bin/glxinfo: libGLU.so.1 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGLU.so.1 (0x28079000) libGL.so.1 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGL.so.1 (0x280f3000) libXext.so.6 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libXext.so.6 (0x2816f000) libX11.so.6 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libX11.so.6 (0x2817e000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28246000) libm.so.2 = /lib/libm.so.2 (0x2826a000) libc.so.5 = /lib/libc.so.5 (0x28283000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x2835d000) # glxinfo -display :1 name of display: :1.0 display: :1 screen: 0 direct rendering: Yes [rest of output snipped for clarity.] but glxgears only gets about 115.3 frames: # glxgears -display :1 [1] 6381 577 frames in 5.0 seconds = 115.400 FPS 576 frames in 5.0 seconds = 115.200 FPS 576 frames in 5.0 seconds = 115.200 FPS 577 frames in 5.0 seconds = 115.400 FPS which is the same as without dri. So gl thinks it has dri, but performance is no better. Don't expect huge numbers from glxgears, you'll notice more improvement in apps using textures and more geometry than gears. (note - the -display :1 is because I am running two Xservers. If I disable the 2nd Xserver, I still get only 115 frames, but I didn't have that output to paste.) (note2 - I am going to try building a few gl games - gltron and tuxracer - and see if they improve.) You should see a significant difference in those. I looked at the log file, and here is the important output: XFree86 Version 4.3.99.12 (DRI mach64-0-0-7-branch) [snip] (II) LoadModule: glx (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libglx.a (II) Module glx: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: dri (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module drm (II) LoadModule: drm (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/freebsd/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: ati (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/drivers/ati_drv.o (II) Module ati: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 6.5.3 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 [snip] (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 detected. (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active Device section card0. [snip] (II) ATI(0): [drm] SAREA 2200+1208: 3408 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) ATI(0): [drm] DRM interface
Re: [Dri-devel] mach64 dri on freebsd 5.2
On Sun, 7 Mar 2004, Dave Airlie wrote: What is the status of mach64 dri support on freebsd 5.2 ? nobody has tested it for a while, so I say it suffers from bitrot... mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should all be there, just needing some updates for FreeBSD 5.2, I'll look into it over the next while (need to sleep for a day or two :-) Dave. I just brought over the missing Makefiles and mach64_drv.c (with PCI ID list removed since it's in mach64.h now) for bsd from mach64-0-0-6-branch. I haven't tested the build, but I think I picked up all the necessary pieces. -- Leif Delgass http://www.retinalburn.net --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Building DRM for 2.6.3. And mach64 randr and Kconf.
On Sun, 7 Mar 2004, Mike Mestnik wrote: I never got gatos to work on 2.6 but atitvout workes if I set X to 1024x768 or 800x600 or 640x480. It has problems with regard to VT switching and video mode changing. On a VT I run atitvout ntsc detect then switch to X running the mode I use 1024x768 for movies and 640x480 for nintendo games. Then I run atitvout t as I can only use one display at a time. I run atitvout l and then can change VTs and resolution. Have you tryed using Makefile.linux or Makefile.kernel with 2.6.3? Also there is no Kconfig support for mach64!!! The Kconfig option from mach64-0-0-6-branch didn't make it over to the new branch. I've added the mach64 option back in. --- Jan Geldmacher [EMAIL PROTECTED] wrote: On Sun, 7 Mar 2004 04:08:11 -0800 (PST) Mike Mestnik [EMAIL PROTECTED] wrote: I was building mach64 drm for 2.6.3. I had the worst time convincing Makefile.linux and inturn Makefile.kernel that it was not lessthan25 and lessthan2552. I finaly gave up once I saw I had to gointo all the .h and .c files and add #defines there as well. Also I don't have a mach64 pro so I guess I can't use the kmod any way. This laptop has AGP, will there ever be DRI support for the Rage Mobility P/M AGP 2x? What is capeble of being accelerated and what type of FPS could I expect to get if I added the support? The Rage Mobility P/M has always been supported by the driver, as far as I can remember. There is a list of PCI IDs in the mach64 DRM now, but I haven't checked it to see if anything is missing yet, but there are entries for Rage Mobility P/M and Rage Mobility P/M AGP 2X. I have a Rage Mobility P/M AGP 2x, too. Building and installing dri on 2.6.1 was no problem with the latest cvs version. I just followed the instructions on http://dri.sourceforge.net/cgi-bin/moin.cgi/ATIMach64 However TVout makes problems. It worked under 2.4.x, but I can't get it to work with 2.6/Xfree (neither gatos nor atitvout)... I can only activate tvout using plain console without X started. hth Also the Debian mach64 driver added xrendr or was that the new X server? Any way it workes nice and now I think I can get rid of all my layouts for TV output. __ Do you Yahoo!? Yahoo! Search - Find what you_re looking for faster http://search.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 dri on freebsd 5.2
before string constant builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:420: error: syntax error before string constant builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:421: error: syntax error before string constant builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:422: error: syntax error before string constant (builddir is the root of my builddir, /2nd/usr/from_ext_cvs/dri_mach64_branch/mach64-0-0-7-branch/xc.build/ .) I also tried running 'make -f Makefile.bsd' in the dir xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel, but of course that dies with the same errors. A bit of reading through the code and googling dri.freedesktop.org leaves me with the impression this code was for old 'DRM_LINUX' support, which has been superceeded, but still I can find no drm kernel module for freebsd. btw - I had mentioned this on the dri-users list, but not here, sorry about that, I am running freebsd 5.2p2. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] freedesktop CVS
Hello, I'm not able to checkout the DRI CVS from freedesktop.org, since I seem to have been dropped from the dri group -- same problem that others had recently. I sent an email to Eric but apparently he's away for some time. Does anyone else on the list have the ability to modify groups on freedesktop.org? Thanks, Leif -- Leif Delgass http://www.retinalburn.net --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
On Thu, 12 Feb 2004, Dave Airlie wrote: Okay the last few fixes make tuxracer and glxgears work again, so the new branch should be as useable as the old one, I think there are still a few cleanups in the native vertex code (using macros for a few things), and then a texmem converison might be in order. But it's good enough for me to get on with some real work on my laptop :-) Dave. Hello, It's great that you are picking this up. It's been on my todo list for a long while but free time is nonexistant for me these days (full time grad student + half time research assistant = - half time DRI developer?!) I actually have a near complete texmem conversion that's been gathering dust for a while. I'll try to clean it up and send a patch in the next few days. -- Leif Delgass http://www.retinalburn.net --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] driconf for pygtk2
Hello all, I recently had some time to check out the trunk and try out the new GUI configuration tool. The box I tested on is running RedHat 9, which comes with pygtk2 installed, so I decided to port driconf to pygtk2 rather than try to figure out how to install an older pygtk in parallel with the new one. I'm attaching the patch (against driconf-0.0.11 from the DriConf wiki page) in case anyone else is in a similar situation. I'm a python newbie, but the lion's share of the changes were simple search and replace (the PyGTK FAQ covered most, but not all of the necessary changes). I also included a couple of minor visual tweaks: setting the initial window size to match the window size after selecting a profile (kept the window from being extended beyond the desktop borders when it was placed in the lower right corner of the screen on startup), and setting the window background to white when the DRI logo is displayed (since the wider window exposed the gray background behind the image). -- Leif Delgass http://www.retinalburn.net --- driconf.orig.py 2003-10-25 13:41:31.0 -0500 +++ driconf.py 2003-10-26 18:59:33.0 -0500 @@ -18,61 +18,64 @@ # Contact: http://fxk.de.vu/ +# Ported to PyGTK-2 by Leif Delgass [EMAIL PROTECTED] + import os import locale import dri try: import pygtk -# make sure gtk version 1.2 is used. -pygtk.require (1.2) +# make sure gtk version 2.x is used. +pygtk.require (2.0) except ImportError: # not supported everywhere, so ignore import errors pass -from gtk import * +import gtk from driconf_xpm import * # global variable: main window mainWindow = None -class DataPixmap (GtkPixmap): +class DataPixmap (gtk.Image): A pixmap made from data. window = None def __init__ (self, data): Constructor. DataPixmap.window.realize() style = DataPixmap.window.get_style() -pixmap, mask = create_pixmap_from_xpm_d(DataPixmap.window.get_window(), -style.bg[STATE_NORMAL], -data) -GtkPixmap.__init__ (self, pixmap, mask) +pixmap, mask = gtk.create_pixmap_from_xpm_d(DataPixmap.window.window, +style.bg[gtk.STATE_NORMAL], +data) +gtk.Image.__init__ (self) +self.set_from_pixmap(pixmap, mask) -class MessageDialog (GtkDialog): +class MessageDialog (gtk.Dialog): A simple message dialog with configurable buttons and a callback. def __init__ (self, title, message, buttons = [OK], callback = None, - modal = TRUE): + modal = gtk.TRUE): Constructor. -GtkDialog.__init__ (self) +gtk.Dialog.__init__ (self) if mainWindow: self.set_transient_for (mainWindow) self.callback = callback self.set_title (title) first = None for name in buttons: -button = GtkButton (name) -button.set_flags (CAN_DEFAULT) +button = gtk.Button (name) +button.set_flags (gtk.CAN_DEFAULT) button.connect (clicked, self.clickedSignal, name) button.show() -self.action_area.pack_start (button, TRUE, FALSE, 10) +self.action_area.pack_start (button, gtk.TRUE, gtk.FALSE, 10) if not first: first = button -hbox = GtkHBox() -label = GtkLabel (message) -label.set_justify (JUSTIFY_LEFT) -label.set_line_wrap (TRUE) +hbox = gtk.HBox() +label = gtk.Label (message) +label.set_justify (gtk.JUSTIFY_LEFT) +label.set_line_wrap (gtk.TRUE) label.show() -hbox.pack_start (label, TRUE, TRUE, 20) +hbox.pack_start (label, gtk.TRUE, gtk.TRUE, 20) hbox.show() -self.vbox.pack_start (hbox, TRUE, TRUE, 10) +self.vbox.pack_start (hbox, gtk.TRUE, gtk.TRUE, 10) first.grab_default() self.set_modal (modal) self.show() @@ -83,32 +86,32 @@ self.callback (name) self.destroy() -class WrappingCheckButton (GtkCheckButton): +class WrappingCheckButton (gtk.CheckButton): Check button with a line wrapping label. -def __init__ (self, label, justify=JUSTIFY_LEFT, wrap=TRUE, - width=0, height=0): +def __init__ (self, label, justify=gtk.JUSTIFY_LEFT, wrap=gtk.TRUE, + width=-1, height=-1): Constructor. -GtkCheckButton.__init__ (self) -checkHBox = GtkHBox() -checkLabel = GtkLabel(label) +gtk.CheckButton.__init__ (self) +checkHBox = gtk.HBox() +checkLabel = gtk.Label(label) checkLabel.set_justify (justify) checkLabel.set_line_wrap (wrap) -checkLabel.set_usize (width, height
Re: [Dri-devel] Radeon PCI and CVS
On Sun, 15 Jun 2003, Dieter [iso-8859-15] Nützel wrote:
Am Samstag, 14. Juni 2003 23:30 schrieb José Fonseca:
On Sat, Jun 14, 2003 at 10:26:42PM +0200, Dieter Nützel wrote:
Am Samstag, 14. Juni 2003 17:23 schrieb José Fonseca:
I forgot to guard the DRM AGP structures by '#if __REALLY_HAVE_AGP',
causing those errors. This as been fixed in CVS now.
Where and _when_.
Isn't there.
http://sourceforge.net/mailarchive/forum.php?thread_id=2584981forum_id=6512
Do we _need_ a new DRI CVS home, then?
I get this over and over again:
dri-trunk/xc cvs update
cvs [update aborted]: recv() from server cvs.dri.sourceforge.net: EOF
Sometimes this:
cvs update: warning: unrecognized response `' from cvs server
cvs [update aborted]: This server does not support the global -q option.
Didn't the server support compression?
Once you have it complied tell me if everything runs OK - some people
are having some problems with the AGP initializition, and this was what
I was thinking when I replyed this morning.
I tried to put it in by hand. --- But no luck.
Before my change I got this:
Jun 14 14:05:17 SunWave1 kernel: Linux agpgart interface v0.99 (c) Jeff
Hartmann
Jun 14 14:05:17 SunWave1 kernel: agpgart: Maximum main memory to use for
agp memory: 941M
Jun 14 14:05:17 SunWave1 kernel: agpgart: Detected AMD 760MP chipset
Jun 14 14:05:17 SunWave1 kernel: agpgart: AGP aperture is 64M @
0xe800 Jun 14 14:05:17 SunWave1 kernel: [drm] AGP 0.99 aperture @
0xe800 64MB Jun 14 14:05:17 SunWave1 kernel: [drm] Initialized radeon
1.8.0 20020828 on minor 0
Jun 14 14:05:17 SunWave1 kernel: [drm] Loading R200 Microcode
Jun 14 14:21:13 SunWave1 kernel: [drm:radeon_cp_init] *ERROR*
radeon_cp_init called without lock held
Jun 14 14:21:13 SunWave1 kernel: [drm:radeon_unlock] *ERROR* Process 3101
using kernel context 0
Jun 14 14:28:02 SunWave1 kernel: [drm:radeon_cp_init] *ERROR*
radeon_cp_init called without lock held
Jun 14 14:28:02 SunWave1 kernel: [drm:radeon_unlock] *ERROR* Process 4007
using kernel context 0
Argh!
GL_RENDERER: Mesa GLX Indirect
Now I get this:
Sometimes with direct rendering, sometimes without.
The OpenGL windows are empty after running gears for some seconds.
ipers comes up with help information ('h' key to toggle this) but
without 'back ground' rendering. The normal desktop is in the 'back'.
After hitting 'h' I get an empty window and during moving the window I
get a smearing desktop in the window. I have to press CTRL+'C' to kill
them.
Try again from CVS, perhaps the anonymous cvs was outdated (I know this
hapens sometimes with SourceForge).
For nearly 24 hours?
[snip]
According to the sourceforge website, anonymous (pserver) cvs access and
ViewCVS have been moved to the backup server to reduce the load on the
main (developer) server. The backup server will be around 24 hours behind
the main server.
Nothing changed ;-(
Send me a copy of these two files, please.
Regards,
Dieter
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI and CVS
On Sat, 14 Jun 2003, Chris wrote: Yes. Please send me your /var/log/messages and /var/log/XFree86.0.log . um, those won't help considering DRI won't even compile, I'm sure its for DRI you were meaning. snip from compile log make[11]: Entering directory `/usr/src/linux-2.4.21-rc8' make -C /usr/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kern el CFLAGS=-D__KERNEL__ -I/usr/src/linux-2.4.21-rc8/include -Wall -Wstrict-prot otypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-poin ter -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE MAKING_MODULES=1 modules make[12]: Entering directory `/usr/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/ker nel' gcc -I/usr/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/dr m/kernel -D__KERNEL__ -I/usr/src/linux-2.4.21-rc8/include -Wall -Wstrict-pro totypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-poi nter -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -nostdinc -iwit hprefix include -DKBUILD_BASENAME=gamma_drv -c -o gamma_drv.o gamma_drv.c In file included from drmP.h:125, from gamma_drv.c:34: drm_agp.h:43: error: parse error before agp_memory drm_agp.h:43: warning: no semicolon at end of struct or union drm_agp.h:48: error: parse error before '}' token drm_agp.h:48: warning: type defaults to `int' in declaration of `drm_agp_mem_t' drm_agp.h:48: warning: data definition has no type or storage class drm_agp.h:56: error: parse error before agp_kern_info END SNIP X4.3.99.6 does work however. It looks to me like the contents of drm_agp.h need to be protected with: #if __REALLY_HAVE_AGP /* struct definitions and prototypes */ #endif This was present in drmP.h before the struct/typedef definitions and prototypes were split out into drm_agp.h. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missinglibGL.so?)
On Wed, 4 Jun 2003, Ian Romanick wrote: John Sheu wrote: Output of gdb on glxinfo: Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...[New Thread 16384 (LWP 2145)] name of display: :0.0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2145)] 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 584 texmem.c: No such file or directory. in texmem.c Hmm...looking at the code, my guess is that rmesa-nr_heaps is 2 on Rage 128 even on PCI cards. In gdb you can 'print rmesa-nr_heaps' to see. You might also try 'print r128scrn-texSize[0]' and (if nr_heaps is 2) 'print r128scrn-texSize[1]'. Since I don't have a Rage 128, that would help. :) Perhaps Leif can take a look at this. Note that this has *NOTHING* to do with your libGL.so. This is 100% in the driver. nr_heaps should be 1 on PCI cards (see r128CreateScreen() in r128_screen.c). However, the DDX will enable DRI even if the local texture heap size is 0 on a PCI card, which I consider to be a bug (I changed the mach64 driver to disable DRI if there's not enough mem for a texture heap). I also think you'd run into the same problem if there is no room for a local heap, but there is space for an AGP heap. In working on texmem for mach64, I've changed the heap indexes for local/AGP to be context variables instead of #defines, so that texture_heaps[0] can be AGP if there is only an AGP heap and no local heap. I'm pretty sure I ran into this problem on r128 before when I tried running at 24-bit depth with a high enough resolution. If this is the problem, I think you'd see a message like: Reserved 0 kb for textures at offset 0x0 in the X log. Still, I think the drivers should also check the return of driCreateTextureHeap() and bail out if it fails. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missinglibGL.so?)
On Thu, 5 Jun 2003, John Sheu wrote: On Thursday 05 June 2003 11:45 am, Leif Delgass wrote: I'm pretty sure I ran into this problem on r128 before when I tried running at 24-bit depth with a high enough resolution. If this is the problem, I think you'd see a message like: Reserved 0 kb for textures at offset 0x0 in the X log. Right, that appears in the logs. So what to do? Try a lower resolution and/or color depth. We can fix the segfault, but that won't change the fact that there isn't enough on-card memory to use 3D at the configured resolution/depth (at least with the current static shared back buffer allocation scheme). -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 DRI problems
On Sat, 31 May 2003, Paul Mackerras wrote: José Fonseca writes: On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote: * The hang always occurs within a mach64_dma_dispatch_vertex call for primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears. glxgears only uses quads primitives, so the primitive is not relevant here. Hmmm, I am _definitely_ observing calls to mach64_dma_dispatch_vertex with prim = 8 while running glxgears. And it is the one that seems to cause the trouble. You're talking about sync/async DMA mode here, right? Have you tried some of the other Mesa demos? It would be useful to see what other apps do or don't cause a lockup, if it is always in dispatching vertex buffers, and if the type of primitive is the same or not. I'm inclined to agree with Jose that the primitive type shouldn't matter, but it's worth looking into. * I can get it to hang in mmio mode running glxgears if I make mach64_dispatch_pseudo_dma() just wait for space in the FIFO (or even for the FIFO to be empty) rather than waiting for the engine to be idle every 16 words. Was this using direct MMIO or HOST_TO_DATA? MMIO. Here's some more info on HOSTDATA: In MMIO/pseudo-DMA mode, when we see a descriptor with BM_HOSTDATA as the GUI master target register (rather than BM_ADDR), we feed the blit data to the card through the HOST_DATA[0-15] registers, so it's still MMIO. The thing we have to be careful of is that you can't wait for idle between writes that set up the blit and the writes of the blit data to the HOST_DATA registers, or else the engine will lock up. That's what the no_idle_wait flag is for in the pseudo-DMA dispatch code. The docs say that full FIFO discliple must be maintined when writing to the HOST_DATA registers, which means checking for enough FIFO entries. The registers are sequential, so you can do an assembly optimized memcpy of 16 32-bit words at a time, checking the fifo between copies. When doing DMA to BM_HOSTDATA, the assumption is that the engine takes care of FIFO discipline (BM_HOSTDATA isn't really documented well). At any rate, this doesn't apply to gears since it doesn't use textures. Can anyone give me any pointers about how to get this chip going properly? From what you describe here I see three explanations: - there is some kind of caching corrupting the data from/to the hardware, which is specific to some of the PPC architectures That would not explain how I can get the chip to hang when I am feeding it with MMIO. - the driver is emitting bad 3D data - this is IMHO unlike since some other people have no problems with PPC and I also think this is unlikely, given that it works fine in MMIO mode (as long as I use the normal code which waits for the engine to be idle every 16 words). - your hardware is buggy - I had problems in the past with an AGP controller, but AFAIK the AGP isn't used in PPC, so I don't know what could be in fault. Later powerbooks (PPC laptops) have AGP, but not this one. I have AGP on my titanium G4 powerbook, which has a Rage 128 chip, for instance. This chip (3D Rage LT Pro, code 'LI') does have some bugs; for instance, 2D diagonal lines sometimes get drawn incorrectly (most noticeable with xpilot). So it is quite possible that there is a hardware bug. This is the same chip I have (also rev. dc) on x86, but mine is AGP. The lockups you are describing sound identical to previous reports on PPC, iirc. MMIO works, but sync and async DMA cause lockups. Also, we originally tried waiting for 16 FIFO entries instead of waiting for idle in the pseudo-DMA path. It works for me on x86, but it caused lockups for ppc users. For DMA, the condition where the FIFO is empty, but GUI_ACTIVE is set in GUI_STAT is a symptom of an engine lock-up, which could be caused by a number of things. I've definitely seen that state many times before, so I don't think it necessarily indicates a hardware bug. I remember other reports on ppc where the engine would lock in this state at the last descriptor in the ring. You should be able to get a (partial) dump of the ring contents by loading the kernel module with drm_opts=debug. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 DRI problems
On Sat, 31 May 2003, Leif Delgass wrote: Here's some more info on HOSTDATA: In MMIO/pseudo-DMA mode, when we see a descriptor with BM_HOSTDATA as the GUI master target register (rather than BM_ADDR), we feed the blit data to the card through the HOST_DATA[0-15] registers, so it's still MMIO. The thing we have to be careful of is that you can't wait for idle between writes that set up the blit and the writes of the blit data to the HOST_DATA registers, or else the engine will lock up. That's what the no_idle_wait flag is for in the pseudo-DMA dispatch code. The docs say that full FIFO discliple must be maintined when writing to the HOST_DATA ^ discipline, that is. I need more coffee. ;) registers, which means checking for enough FIFO entries. The registers are sequential, so you can do an assembly optimized memcpy of 16 32-bit words at a time, checking the fifo between copies. When doing DMA to BM_HOSTDATA, the assumption is that the engine takes care of FIFO discipline (BM_HOSTDATA isn't really documented well). At any rate, this doesn't apply to gears since it doesn't use textures. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bin. driver packages
On Fri, 30 May 2003, [iso-8859-15] José Fonseca wrote: On Fri, May 30, 2003 at 12:49:57AM -0500, John Sheu wrote: Two questions... 1. Are the wrapped binary driver packages ever coming back? Appearently there is a problem while building them, because they are back for some time. I'm going to look into it. 2. It seems with an old one I got (binary driver packages) it was missing the libGL's so that once installed, (for example) glxinfo segfaults as it tries to load old libGL's. An oversight or purposeful omission? Not an oversight - libGL shouldn't be necessary as the one that comes with XFree86 suits perfectly. The segfault must be due to something else. You shouldn't get a segfault in any case -- a backtrace would be helpful there. However, there are some new GLX extensions (the swap/sync extensions) supported by the drivers that will only work with a new libGL from the trunk. The drivers check the internal GLX API version of libGL in __driRegisterExtensions() before enabling these newly supported GLX extensions. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
On Thu, 29 May 2003, Ian Romanick wrote: Ian Romanick wrote: Ian Romanick wrote: Log message: Fixed the various supported texture wrap modes. Added a fallback for unsupportable combinations of S/T wrap modes. All of the exported modes on Radeon, R200, and MGA should be correct now. I'm going to try and look at i830 this week. Could somebody please see about fixing up Rage128 and 3dfx? I see that both of those have some of the same problems that the fixed drivers used to have. Has anyone had a chance to look at this on either Rage128 or 3dfx? I did a little snooping in both drivers, and I have a couple theories, but someone with the actual hardware will have to verify them. I think the Rage128 driver is wrong in a couple of ways. It uses the same mode for GL_CLAMP and GL_CLAMP_TO_BORDER. iirc, textures with a border are a fallback on r128. GL_CLAMP looks the same in texwrap on r128 as it does with software/indirect rendering. If the hardware, like the Intel hardware, can't support GL_CLAMP, then it should use GL_CLAMP_TO_EDGE. This is consistent with the Intel driver. I think it's also closer to what people are likely to expect. I looked at Delph3D, and the Rage128 drivers for the other operating system don't support ARB_texture_mirrored_repeat. They do, however, support ATI_texure_mirror_once. Changing 'b' in texwrap.c to 1.2 (from 0.2) will show which the driver is actually doing. I tried this. It is in fact doing mirrored repeat (looks the same as software/indirect rendering with b set to 1.2). http://delphi3d.net/hardware/viewreport.php?report=294 The Rage128 driver also doesn't export the SGI versions of any of the clamp extensions. This is trivial and not necessary, but is probably a good idea. I think we should export the EXT and SGIS edge clamp extensions (the texwrap demo gave a warning about that since the GL version is 1.2 but the extensions aren't present). I'll add this. The 3dfx driver also has a number of problems. The switch-statement that handles texture wrap modes doesn't have a case for GL_CLAMP_TO_EDGE, which is a required part of GL 1.2. The bad part is that because GL_CLAMP_TO_EDGE comes after GL_CLAMP in the test, it will probably look okay in the test. Moreover, I don't see a mode for it (or GL_CLAMP_TO_BORDER) in tdfx_glide.h. I'm not sure what we should do about that. At the very least we should make GL_CLAMP_TO_EDGE work like GL_CLAMP. Leaving the currently set mode as-is is just plain wrong. tdfx_glide.h has a mirror mode (GR_TEXTURECLAMP_MIRROR_EXT, line 308), so the hardware probably supports ARB / IBM_texture_mirrored_repeat. That should be investigated. The driver also doesn't export any of the extension strings. I assme that is because it doesn't actually support any of the extensions (even the required one). The Banshee driver (from 07-Jan-2000), Voodoo3 driver (from 16-Jan-2001), and the Voodoo5 driver (from 21-Nov-2000) for that other operating system all export SGIS_texture_edge_clamp, but that's all. Either 3dfx implements GL_CLAMP as GL_CLAMP_TO_EDGE (like Intel), or there some missing bits in tdfx_glide.h. http://delphi3d.net/hardware/viewreport.php?report=19 http://delphi3d.net/hardware/viewreport.php?report=17 http://delphi3d.net/hardware/viewreport.php?report=204 --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] EXT_stencil_wrap support on older ATI cards
On Wed, 28 May 2003, Ian Romanick wrote: Leif Delgass wrote: On Wed, 30 Apr 2003, Ian Romanick wrote: After cleaning up some of the left-over issues from the texmem merge, I did a quick check low-hanging fruit functionality that could be added so some of the drivers. In doing so, I notied that neither the r128 driver or the radeon driver support EXT_stencil_wrap. Since this extension is part of the 1.4 core spec, it seems like a fairly important one to add. According to Delph3D, EXT_stencil_wrap is supported by both of these chips. http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_stencil_wrap I did some experimentation with the radeon driver and the stencilwrap test (in the tests directory in Mesa). I made a small modification to is so that it would log errors and continue on. I modified the radeon drivers to use the same values for GL_INCR_WRAP and GL_DECR_WRAP as the R200 driver (all of the other stencil op values are the same). The interesting thing that I noticed is that RADEON_STENCIL_*_DEC behaves like R200_STENCIL_*_DEC_WRAP should. Using R200_STENCIL_*_INC_WRAP on the R100 behaves like RADEON_STENCIL_*_INVERT, but R200_STENCIL_*_DEC_WRAP works correctly. I just did the same patch/test here on Radeon 7500 and the stencilwrap test works fine. INC/DEC saturate as expected and INC_WRAP/DEC_WRAP wrap correctly. I'm attaching the patch I used. I think the *only* difference between your patch and mine is that I used the GL 1.4 names and you used the EXT names. Yep. The Rage 128 driver doesn't currently support a hardware stencil, but I've been working on getting that going as well. So far, I've found that using the same bits for stencil wrap modes as R100/R200 does work, but there are problems with readback. The r128 driver calls ioctls in the drm that blit to and from an AGP span buffer to implement Read/DrawPixels for the depth buffer. This seems to be in order to avoid having to convert coords/offsets to account for depth buffer tiling. At any rate, the problem I see in readback seems to indicate some sort of caching problem. I modified stencilwrap in the same way you did to continue and report errors. I see off-by-one errors that vary (in a seemingly random way) in number and value from one run to the next. That is, I get a few old values and then things seem to catch up. I'd like to do some more testing and see if I can reproduce the same behavior with the depth component values. That's interesting. I think the problems I was seeing with stencil on i830 were just read-back errors as well. I've tried a few of the SGI sample tests you mentioned that use the stencil buffer on r128 with my preliminary stencil patch and they are working. There is still a bug with quake3 and r128 (with or without a stencil buffer) where damage textures and sometimes other objects show through walls and such that looks like some sort of depth bug. I'm not sure if this is related to read-back though. BTW, I fixed the fire demo bug on r128 (and mach64). It wasn't related to texmem at all, but rather it was a Mesa 4.1/5.x merge problem. The Color.AlphaRef alpha test reference value was changed from GLubyte to GLfloat in Mesa 4.1, and all the drivers except r128 were updated to convert from a float to a ubyte when programming their respective alpha test registers. At any rate, I'd like to commit the attached patch, but it would be good to get some more data points from R100 users. Testing has convinced me that the stencil wrap register settings are the same for all the ATI cards we have drivers for that support a hardware stencil, but I don't have docs for R100 or Rage 128. I think there was some bug in the 7200 that was fixed in the 7500. I have attached my version of stencilwrap.c, my output from stencilwrap.c, and my patch to the driver. I should be able to try this out on an M6 and possibly a 7000 a little later today. We may be able to enable this, but only on certain versions of the R100 chip. :( Your stencilwrap output from the 7200 is truly bizarre. :O I wonder what setting the INVERT bit does? So far, it looks like you have: DECR_WRAP - does INVERT DECR - does DECR_WRAP INCR_WRAP - does DECR_WRAP INCR - OK INVERT- ? And does the same thing happen with fail and zfail? It would be good to have a test that tries all of the stencil func/op combinations in addition to the stencil wrap extension. Since our patches are virually identical, it does appear to be a hardware bug on that particular card. Looks like we may need to pass a PCI id or some sort of hardware family designation from the X server to the Mesa driver. In any case, we'll need to get test reports on as many r100 variants as possible. If we need workarounds/fallbacks for specific card revisions, it would be nice to know if they all break in the same way
Re: [Dri-devel] GL_MESA_ycbcr_texture possible with the old radeon?
On Tue, 27 May 2003, Ian Romanick wrote: Leif Delgass wrote: On Fri, 23 May 2003, Ian Romanick wrote: Andreas Stenglein wrote: In radeon_reg.h there are some new txformats: RADEON_TXFORMAT_VYUY422 RADEON_TXFORMAT_YVYU422 Would it be possible to make the MESA_ycbcr_texture extension available for the original (old) radeon or are there some issues which prevent this? Are there other extensions which could be backported from the R200-driver? Maybe GL_NV_texture_rectangle, GL_ARB_texture_cube_map ? Now that MESA_ycbcr_texture is in the r100 driver, did you want to tackle NV_texture rectangle? The MESA_ycbcr_texture patch hadn't been committed to CVS yet, but since I've tested them, I committed the r128 and R100 portions of the patch. I didn't commit the i810 and mga patches, since I'm not able to test those myself. Sorry for falling asleep at the wheel. I was waiting to make sure we had the DRM version requirement issue for R100 resolved first. I guess we decided that the version didn't matter? Right. Since the new radeon Mesa driver (the first to export the extension) always uses an 8-bit format for blits, it will work with any drm version. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [trunk] CVS compilation errors (DRM_WRITEMEMORYBARRIER)
Don't worry about it, shit happens. ;) I fixed a couple of things that I came across, and I'm doing a quick onceover through CVS web to double-check. Great work with the documentation, btw. One minor issue I had: Can we keep the emacs mode magic for the drm files: -*- linux-c -*- This sets up the indentation and style in emacs if you have the mode defined (as described in the kernel docs). It needs to be on the first line of the file. Would it mess up doxygen to add a comment above the header?, e.g.: /* -*- linux-c -*- */ /** * \file ... --Leif On Wed, 28 May 2003, [iso-8859-15] José Fonseca wrote: Sorry about that. I merged everything manually using a visual diff util to prevent that this happened, and compiled everything after and corrected the errors, but still failed. José Fonseca On Tue, May 27, 2003 at 08:46:04PM -0500, Leif Delgass wrote: Looks like the change to drm_os_linux.h that removed the argument from the DRM_*MEMORYBARRIER() macros was reverted with the documentation merge. I just checked in a fix. --Leif On Wed, 28 May 2003, Dieter [iso-8859-15] Nützel wrote: Linux 2.4.21-rc2-jam1 r128_state.c:81: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:96: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:122: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:138: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:157: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:172: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:199: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:223: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:398: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:419: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:440: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:462: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:510: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:524: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:552: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:565: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:610: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:625: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:673: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:685: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:768: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:828: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:882: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:955: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:979: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1073: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1097: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1144: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1206: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1234: macro `DRM_WRITEMEMORYBARRIER' used without args make[12]: *** [r128_state.o] Error 1 radeon_cp.c:728: macro `DRM_MEMORYBARRIER' used without args radeon_cp.c:735: macro `DRM_MEMORYBARRIER' used without args radeon_cp.c:753: macro `DRM_MEMORYBARRIER' used without args radeon_cp.c:760: macro `DRM_MEMORYBARRIER' used without args make[12]: *** [radeon_cp.o] Error 1 etc. Thanks, Dieter --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress
Re: [Dri-devel] [PATCH] Fixes for GLX_SGI_video_sync
On Wed, 28 May 2003, Dieter Nützel wrote: Am Dienstag, 13. Mai 2003 18:07 schrieb Leif Delgass: Attached are two patches: the first fixes problems with GLX_SGI_video_sync in the drivers and common vblank code and adds a common driGetMSC32() function in vblank.c. The second patch adds a '-sync' option to glxgears that will use the extension to sync to the refresh. Here are more details on the first patch: - Added a generic driGetMSC32() to vblank.c, which gets the current MSC by calling drmWaitForVBlank() with a relative wait of 0 (i.e., don't wait, just return the current MSC value). I should point out that since the vblank counter in the kernel is an unsigned int rather than an unsigned long, this will return a 32-bit value (then cast to an int64_t) even for 64-bit platforms (not sure if this is true for all platforms, but I checked it on Alpha and Sparc64 on the compile farm and it's 32-bit). - The radeon and r200 drivers' implementations of GetMSC was using the wrong counter (frame age instead of vblank counter), and mga was doing a wait for absolute 0 rather than a relative wait for 0. I changed all the drivers to use the new generic implementation. One possible problem of using the counter for both the SGI/OML extensions is that the OML version wants the counter incremented for each field with an interlaced mode, and the SGI version does not. - I added support to r128 for GLX_SGI_swap_control, GLX_SGI_video_sync, and GLX_MESA_swap_control. GLX_SGI_video_sync can be exported by any driver using the common vblank code by installing callbacks to the two generic functions (driWaitMSC32 and driGetMSC32) in the DriverAPI struct. - Since some of the drivers already had C99 designated initializers for some of the new DriverAPI members, I changed those drivers to use them for initializing all the members. gcc supports this as an extension to C89, but I'm not sure if this will be an issue when merging into the XFree86 tree. - I fixed a couple of problems with the driWaitForMSC32() implementation, some of which cropped up when it's used for the SGI extension instead of the OML extension. First, I made the local vars unsigned ints and added explicit casts on the paramters passed as int64_t to unsigned int, in order to match up with the unsigned int sequence returned from the kernel and make it more clear (to me at least) what's going on. Second, I made the function behave as expected for SGI_sync_control when target_msc == 0 (which is what is passed in from glxcmds.c for the SGI extension), i.e. don't wait for the target, just proceed to the test against the divisor and remainder. This should be fine for the OML version if zero is passed as the target, as it works as if the target was missed (and you're pretty much gauranteed to always miss 0 for a 64-bit counter which is supposed to never roll over). The last fix affects both extensions: the calculation of the next target MSC (from the divisor/remainder) needed a tweak: MSC - (MSC % divisor) + remainder gives you the refresh closest to the current one, but it can be _after_ the current one, so we only need to add divisor if that value is less than or equal to the current MSC. Anyone have comments and/or suggestions? Obviously, there are still 32-/64-bit issues to work out. What about hits stuff? -Dieter I committed this (minus the gears patch), so GLX_SGI_video_sync should be working for r200, radeon (r100), r128 and mga. The 32-/64-bit question is still an open one, though. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ 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)
On 12 Apr 2003, Eric Anholt wrote: On Sat, 2003-04-12 at 10:17, Leif Delgass wrote: I think setting rmesa-sarea-nbox = 0 when there are 3 or fewer cliprects and the cliprects dirty flag isn't set should be correct. The idea is that, since r128 has three auxiliary hardware scissors (3 cliprects can be emitted per re-used vertex buffer), there is no need to update the scissor registers unless the cliprects have changed or there are more than 3 cliprects. Actually, I'm not sure why the test isn't nbox 4. Similarly the check for nbox = R128_NR_SAREA_CLIPRECTS should be a right? That sounds right, yes. Wouldn't it make much more sense for the kernel to be basing its uploading of cliprects off of sarea_priv-dirty R128_UPLOAD_CLIPRECTS? If I understand it right, then we wouldn't need tricks like count=0 (not 100% sure on this one) and nbox=0 setting. As it is, nothing uses sarea_priv-dirty R128_UPLOAD_CLIPRECTS. Yeah, it's all done client side right now. The real problem may be elsewhere. One possibility is that on context switches with the X server, the ring may not be flushed of drawing commands using old clipping information. Another thing that might help is updating the window position and scissor information immediately from r128GetLock, rather than setting new_state flags. This is one of the changes I made in the mach64 driver relative to r128, based on the code in the radeon driver. Mach64 used to have the same sort of clipping and overlapping window problems as r128. I'll have to go back through my changes and see if I can reconstruct what I did. It would also improve window moving if we implement XAA blits for back-buffer (and depth buffer?) moves as in the Radeon driver (I did this for mach64 also). For now it's still an improvement because it does clip things correctly, but by uploading cliprects every time. I'll try to compare more carefully against what radeon/mach64 do with clipping and get it fixed right. I'm working on this now. I think one of the problems is the delayed updating of new drawable info. The new_state flag isn't examined between acquiring the lock and calling r128FlushVerticesLocked, so new drawable info coming after acquiring the lock doesn't get used until after the vertex buffer is sent, causing stale scissor and window position info to be used. Basically, I'm making the code look a bit more like radeon and mach64. I don't think XAA blits would solve the problem I was seeing, if you were trying to say that. Once in a while after moving the window the gears would continue spinning at the same offset in the screen as before, just with the window in a different place. I'll take a look at that, though. It wouldn't fix drawing outside of the window, but it would prevent an offset back buffer being swapped to the front or being drawn over and then swapped. That makes the moves look jerky. I think what you're seeing is probably a result of the window offset not being picked up early enough, as I mentioned above. I just tested a patch that reworks the state handling for window position, cliprects and scissor and I've been able to eliminate the show through with overlapping windows while still using sarea-nbox = 0 for fewer than 4 cliprects. I'll post a patch you can try soon. Another question: the advantage of Allocate/FreeOffscreenArea()s in the TransitionTo2/3d is to leave more room for pixmaps in the 2d-only case, right? Right, I think we should add this as well. It's especially helpful for these older cards with less memory. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fresh DRI driver snapshots - call for testers
On 4 Apr 2003, Sergey V. Oudaltsov wrote: There are new driver snapshots from the trunk (for XFree86 4.3.0) on http://dri.sourceforge.net/snapshots/ . They were built wihout a glitch but are yet untested. Please report back success and/or failure. Great!! Does this include mach64 (which is in bleeding-edge subdir)? Also, Leif, what about those cool DRI+Xv snapshots? I think we should switch the mach64 snapshots to the mach64-0-0-6-branch now. The merge from the trunk is complete, so that branch is now based on XFree86 4.3.0 and Mesa 5.0.1. I'll be merging in Brian's updates to Mesa from the trunk soon as well. I have a new DRI+Xv source patch for this branch available at: http://www.retinalburn.net/linux/dri_xv.html I'll be adding binaries pretty soon, probably built on RedHat 9. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Trunk to mach64 branch merge
FYI, I'm about to start a merge of the trunk into the mach64-0-0-6-branch. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: alpha planes, glxinfo, etc
On Fri, 28 Mar 2003, Keith Whitwell wrote: Leif Delgass wrote: On Thu, 27 Mar 2003, Keith Whitwell wrote: Leif Delgass wrote: I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. Hmm, changing this back doesn't seem to affect the output from glxinfo: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x22 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 'bf sz' is still 24, despite me setting bufferSize to 32 in i830_dri.c: pConfigs[i].bufferSize = 32; any clues, anyone? Keith I ran into that as well, see: http://marc.theaimsgroup.com/?l=dri-develm=104457475806902w=2 I think the code related to bufferSize in xc/programs/Xserver/GL/mesa/src/X/xf86glx.c is suspect regarding bufferSize. I think the X visual depth is being used instead of the sum of the channel sizes. There is a comment that a bufferSize of 32 [...]may foul-up the visual matching code[...]. I haven't looked at it closely enough to see what would be needed to fix it. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. On Thu, 27 Mar 2003, Keith Whitwell wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/i810/ Changes by: [EMAIL PROTECTED] 03/03/27 00:46:48 Log message: i830 wasn't reporting alpha component at 32bpp Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/i810/: i830_dri.c Revision ChangesPath 1.11 +2 -2 xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.c --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Thu, 27 Mar 2003, Keith Whitwell wrote: Leif Delgass wrote: I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. OK, I'll look into this. It's odd, because conform was working fine at 32bpp -- when did you make these changes? Keith It was back when I did a mini-audit of the visuals being exported in several drivers before 4.3.0 (beginning of Feb.). Here's my original message about i830: http://marc.theaimsgroup.com/?l=dri-develm=104457580107963w=2 The thread started here where I posted my orginal list of visuals exported by some of the drivers: http://marc.theaimsgroup.com/?l=dri-develm=104448416328979w=2 There were fixes committed for a few other drivers as well. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 binary packages do not work with kernel 2.5.66
On Tue, 25 Mar 2003, Michael Thaler wrote: Hello, I just compiled and installed the latest linux developer kernel. I tried to install the Mach64 binary drivers from www.retinalburn.com. With kernel 2.4.20 it works fine for me, but with kernel 2.5.66 I get the following error message: :/usr/local/src/dripkg# modprobe mach64 FATAL: Error inserting mach64 (/lib/modules/2.5.66/kernel/drivers/char/drm/mach64.o): Invalid module format Is it possible to get the Mach64 driver working with ther developer kernels? Will it help to coompile the mach64 branch? Greetings, Michael Right now I'm not sure if the DRM drivers in DRI cvs will work unmodified when built against 2.5.x (assuming they actually build). Linus and others have been maintaining DRM drivers in the 2.5.x kernel tree based on the DRI trunk, but of course mach64 is not part of the DRI trunk yet, so it's not in the kernel sources yet. If you want to use 2.5.x with the mach64 driver, you may need to do some merging/modification of the DRM code from the mach64 branch (I'm not planning to install a development kernel on my test system). Make sure you've updated all the utilities required to run the 2.5.x kernels (e.g. modutils) and rebuilt the mach64.o module for the current kernel you're running. If you're not comfortable hacking on the code yourself, I'd suggest sticking with a 2.4.x kernel to use the DRI driver until the new stable kernel series (2.6/3.0?) is opened. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
I just ran into a problem with this change in host.def when building the trunk: #define UsrLibDir /usr/X11R6/lib This caused the build to be installed in /usr/X11R6 even though I had ProjectRoot defined as /usr/X11R6-DRI. According to xc/config/cf/README, UsrLibDir is the directory in which to install libraries. Judging from the checkin comment, perhaps AlternateUsrLibDir was what was intended? (README says linker needs -L to find project libraries). There is also an AlternateIncRoot for includes. Since I have symlinks in /usr/X11R6-DRI/lib to /usr/X11R6/lib for libs not built in the DRI tree, I got the build to work by restoring my original install in /usr/X11R6/lib and commenting out the UsrLibDir define. -Leif On Sat, 15 Mar 2003, Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/03/15 17:55:31 Log message: define UsrLibDir so external X libraries are always found Modified files: xc/xc/config/cf/: host.def Revision ChangesPath 1.50 +2 -0 xc/xc/config/cf/host.def --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 sharing interrupts race condition..
On Mon, 24 Mar 2003, Keith Whitwell wrote: Dave Airlie wrote: I've just had the misfortune of having my NFSROOT system (lots of network interrupts), have its card sharing interrupts with the i810 graphics.. once I run anything 3d the kernel oops.. The attached patch contains the quick fix which is to check in thr irq handler if dev-dev_private is NULL or not before going using it .. also a udelay patch included which I think the DRI tree has but the LK one doesn't(arrgg too many trees :-).. I've attached a second patch to xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c that may also fix the problem but which I haven't tested, What happens is the DMA cleanup occurs which frees the private data, and an interrupt comes in from the network card most likely but the i810 driver is let know as the IRQ hasn't been deregistered yet.. This issue also will affect the i830 and gamma (not that anyone cares) but maybe others as well as my DRI tree is old enough at this stage What codebase is this patch against? I was of the opinion that we'd actually eliminated the use of interrupts from the i810 driver. Keith It looks like the i810 and i830 drm modules in the 2.4.x kernel tree still use interrupts. In any case, I think the patch against i810/i830_dri.c should be applied so we have a drmCtlUninstHandler to match the drmCtlInstHandler -- which is there for backward compatibility with older drm modules. Also, this would be used if vblank support is added for i810/i830. -- Leif Delgass http://www.retinalburn.net --- 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] i810 sharing interrupts race condition..
On Mon, 24 Mar 2003, Keith Whitwell wrote: Leif Delgass wrote: On Mon, 24 Mar 2003, Keith Whitwell wrote: Dave Airlie wrote: I've just had the misfortune of having my NFSROOT system (lots of network interrupts), have its card sharing interrupts with the i810 graphics.. once I run anything 3d the kernel oops.. The attached patch contains the quick fix which is to check in thr irq handler if dev-dev_private is NULL or not before going using it .. also a udelay patch included which I think the DRI tree has but the LK one doesn't(arrgg too many trees :-).. I've attached a second patch to xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c that may also fix the problem but which I haven't tested, What happens is the DMA cleanup occurs which frees the private data, and an interrupt comes in from the network card most likely but the i810 driver is let know as the IRQ hasn't been deregistered yet.. This issue also will affect the i830 and gamma (not that anyone cares) but maybe others as well as my DRI tree is old enough at this stage What codebase is this patch against? I was of the opinion that we'd actually eliminated the use of interrupts from the i810 driver. Keith It looks like the i810 and i830 drm modules in the 2.4.x kernel tree still use interrupts. Oh, wow. In any case, I think the patch against i810/i830_dri.c should be applied so we have a drmCtlUninstHandler to match the drmCtlInstHandler -- which is there for backward compatibility with older drm modules. Also, this would be used if vblank support is added for i810/i830. I'm well snowed under right now - can you commit this if it looks right? Keith It looks fine to me, though I can't test it myself. Even if it doesn't completely fix the problem, I think it's the 'Right Thing' to do. I've committed the i810/i830_dri.c fix to the DRI trunk (I also added the drmCtlUninstHandler symbol to the referenced symbol list in i810_driver.c). If someone can verify that this fix works with a Linux 2.4.x drm module, I can submit this to XFree86 as well for the 4.3.x branch. -- Leif Delgass http://www.retinalburn.net --- 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] dri driver features page
On Sat, 8 Mar 2003, Brian Paul wrote:
Nicholas Leippe wrote:
On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote:
Who is the audience for the table? Is it the end user checking to see if a
feature is available and/or has some form of HW acceleration? Or is the
audience the DRI developer, looking to see what pieces need implementing?
That might dictate how much you put in the table, especially color coding.
That's a very good question that I didn't have the answer to when I reworked
it. I'm still not sure. I get the impression from what Brian has said that
he feels it's more for the end user (gl app programmer) to let them know
whether a feature is available for use since he doesn't care to distinguish
any further.
I would prefer to at least distinguishing between hw and sw support, but it's
Brian's baby. :)
I think that if you want to get into more detail about hw vs. sw features, etc
that it should be put below in the Driver-specific Notes section below. But
if someone feels strongly about it and will do all the work to do something
fancier, that's fine. I just don't have time for it.
Nice looking table, I like it.
Thanks.
So, how do I install it on the Mesa site? Just copy the
dri_driver_features.phtml file? That doesn't seem to work. I don't know
anything about dynamic html or html widgets.
-Brian
First off, good work Nicholas!
I did a survey of the extensions exported by the drivers in the trunk and
texmem branches and found a few edits/corrections that I made in the
attached revision, and I also have a few questions. You can see
the dynamic version with my edits on the DRI site here (note that it's
not linked to from the live pages):
http://dri.sourceforge.net/doc/dri_driver_features_new.phtml
Changes:
Add to list:
---
GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to
support this?)
GL_ARB/SGIS_texture_border_clamp - R200 (texmem), R100
GL_EXT/SGIS_texture_edge_clamp - R200, R100 (texmem)
GL_ATI_texture_mirror_once - R200, R100
GL_NV_blend_square - R200, R100
Modifications:
-
GL_ARB_texture_mirrored_repeat - R200 YES, R128 YES (texmem)
GL_EXT_stencil_wrap - i830 NO (currently disabled with #if 0)
GL_SGIS_generate_mipmap - R200 YES
GL_EXT_blend_function_separate - should be GL_EXT_blend_func_separate
Should R128 export GL_EXT_texture_lod_bias? The driver supports it but it
seems from the comment in r128_tex.c that scaling of the bias param might
not be quite correct.
The mga driver in the texmem branch exports these now, but are they really
supported?:
GL_EXT_fog_coord, GL_EXT_secondary_color, GL_EXT_stencil_wrap
There are a couple of other minor changes I had made to the version of the
table on the DRI site that aren't reflected in the dynamic version. The
attached version has these edits and those above (at least the ones I was
sure about).
BTW, I changed the PHP tags from '?' to '?php' and '?=' to '? echo',
since the short versions didn't work when testing on my local system with
PHP 4.1.2, and the PHP docs indicate the short versions are deprecated
since they don't work well with XHTML.
Some other enhancements I thought of that could be made:
- show only the driver notes for the currently selected driver
- have extensions default to no unless they are specified for a
particular driver. That would make editing/adding extensions easier.
--
Leif Delgass
http://www.retinalburn.net
?php
class Driver {
var $exampleCards;
var $primaryAuthors;
var $oses;
var $archX86;
var $archAlpha;
var $archPowerPC;
var $driverName;
var $kernelModule;
var $xfree86_2d_driver;
var $hardwareStencil;
var $hardwareAlphaChannel;
var $hardwareTCL;
var $GL_ARB_multisample;
var $GL_ARB_multitexture;
var $GL_ARBSGIS_texture_border_clamp;
var $GL_ARB_texture_cube_map;
var $GL_ARBEXT_texture_env_add;
var $GL_ARBEXT_texture_env_dot3;
var $GL_ARBEXT_texture_env_combine;
var $GL_ARB_texture_mirrored_repeat;
var $GL_ATI_texture_env_combine3;
var $GL_ATI_texture_mirror_once;
var $GL_EXT_blend_color;
var $GL_EXT_blend_func_separate;
var $GL_EXT_blend_logic_op;
var $GL_EXT_blend_minmax;
var $GL_EXT_blend_subtract;
var $GL_EXT_fog_coord;
var $GL_EXT_paletted_texture;
var $GL_EXT_secondary_color;
var $GL_EXT_shared_texture_palette;
var $GL_EXT_stencil_wrap;
var $GL_EXTSGIS_texture_edge_clamp;
var $GL_EXT_texture_filter_anisotropic;
var $GL_EXT_texture_lod_bias;
var $GL_MESA_pack_invert;
var $GL_MESA_texture_ycbcr;
var $GL_NV_blend_square;
var $GL_NV_texture_rectangle;
var $GL_SGIS_generate_mipmap;
var $GLX_NV_vertex_array_range;
};
function addDriver($vendor
Re: [Dri-devel] dri driver features page
On Sat, 8 Mar 2003, Brian Paul wrote: [snip] GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to support this?) I wouldn't advertise support for GL_ARB_multisample until it really works. The OpenGL spec allows one to support the entrypoints without really implementing the feature (sort of like texture compression). It's not trivial to implement and I'm not sure we even have the technical information needed for doing it with the ATI chips. OK. So it sounds like this should be #ifdef'ed out in the radeon, r200 and mga drivers. [snip] There are a couple of other minor changes I had made to the version of the table on the DRI site that aren't reflected in the dynamic version. The attached version has these edits and those above (at least the ones I was sure about). BTW, I changed the PHP tags from '?' to '?php' and '?=' to '? echo', since the short versions didn't work when testing on my local system with PHP 4.1.2, and the PHP docs indicate the short versions are deprecated since they don't work well with XHTML. Some other enhancements I thought of that could be made: - show only the driver notes for the currently selected driver - have extensions default to no unless they are specified for a particular driver. That would make editing/adding extensions easier. Feel free to incorporate your changes and make the page live. I don't want to be the sole gatekeeper for this info/webpage. At the top where it says Select drivers to view you might point out that one can use shift-click to select multiple entries. Finally, a notice that this table reflects the latest code in CVS, and not necesarily the drivers in XFree86 4.3 or RH8, etc., might be wise. -Brian OK, I've added the disclaimer and the note about selecting multiple drivers. I also implemented my suggestion about only showing the appropriate driver notes when a subset is selected (I'm a PHP newb, but it seems to work. :) ). I've also added back the anchor links to the driver notes on the chip names at the top of the table. I commented out the line that prints the ARB_multisample line for now. The dynamic page is now live with these changes. I changed the link on the status page to the new phtml page. The original flat HTML file is still in /doc as dri_driver_features.html.orig -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
On Sat, 8 Mar 2003, Nicholas Leippe wrote: On Saturday 08 March 2003 05:02 pm, Leif Delgass wrote: BTW, I changed the PHP tags from '?' to '?php' and '?=' to '? echo', since the short versions didn't work when testing on my local system with PHP 4.1.2, and the PHP docs indicate the short versions are deprecated since they don't work well with XHTML. Good catch. I didn't know that. Some other enhancements I thought of that could be made: - show only the driver notes for the currently selected driver I see someone did this and someone also made the chip titles links to the details below like the original page. Much nicer, thanks. Yeah, I added those. I also cleaned up a couple things to get it to validate as transitional HTML 4.01. - have extensions default to no unless they are specified for a particular driver. That would make editing/adding extensions easier. Sure--doesn't really matter too much. I noticed that R200 lists the Radeon 9000. This is actually an R250 part iirc. If it's the same driver, should we change R200 to say R200/R250 ? They are similar, but not identical of course. Well, afaik Radeon 9000 and Radeon Mobility M9 work with the r200 driver. ATI recently announced a Radeon 9200 (RV280?) as well, which looks like it may work too, since I think it will be just a higher clocked 9000 with AGP 8x. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R128 DRM
On Sat, 1 Mar 2003, Jon Smirl wrote: Where is the current source for the R128 DRM driver? It's not in the DRI tree any more. I do see it under drivers/char/drm in the Linux 2.5 tree. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ It's in os-support/shared/drm/kernel, along with the other drivers using the os-independence templates (r128, radeon, mga). This gets linked into the appropriate drm/kernel dir for the OS in the build tree. -- Leif Delgass http://www.retinalburn.net --- 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] DRI trunk 4.3.0 merge?
Now that XFree86 4.3.0 is tagged/released, is there a plan for merging 4.3.0 into the DRI trunk? -- Leif Delgass http://www.retinalburn.net --- 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] Website (Was: S3TC (again))
Regarding the website, I made a couple of changes to the driver feature table in /doc/feature_table.html -- primarily to add ATI_texture_env_combine3 to the list of extensions. I noticed that the link was moved from the documentation page to the status page. However, the link on the status page is to an older version of the table (/other/dri_driver_features.html), which is not as complete and doesn't have the driver notes/environment variable lists. Could you either change the link back to the newer table in /doc, or move the new table from /doc to /other, please? (neither the status page nor the table in /other are group writable). In either case, we should probably remove the old version to eliminate confusion. FYI, I also updated the cvs branch page with the new mach64 branch tag and removed some info that wasn't valid anymore from the description. --Leif On Sun, 23 Feb 2003, Smitty wrote: Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On 22 Feb 2003, Michel Dänzer wrote: On Sam, 2003-02-22 at 00:48, Alan Cox wrote: I updated the radeon DRM to include the texture upload changes. My radeon hang with flightgear now happens every two hours instead of instantly. Is that exactly every two hours? :) By texture upload changes do you mean my radeon_cp_dispatch_texture() fix? If so, are you sure that makes the difference? I merely fixed it not to leave out parts of big textures. I'd rather expect the COMMIT_RING() change to make a difference. When it dies X is stuck, the mouse pointer works. Because it's SIGIO driven. I do wonder if the register writes in RADEONSetCursorPosition() could interfere with the CP to cause FIFO overflows. Does anyone have an idea how to determine whether writes to certain registers go through the FIFO? I asked ATI devrel about this but didn't get a reply. :( The only indication that these might not is that I'd expect it to cause problems much more frequently if they did. IIRC, at least on mach64, hardware cursor position updates don't go through the draw engine FIFO (any registers below dword offset 0x040 don't use the FIFO), so locking isn't necessary. However, we do lock the DRM when updating the cursor image, since it blits the image to the framebuffer through the host data FIFO. When I was first working on 2D/3D sync, we did the sync on every EnterServer, which slowed things down considerably since the sync happened on every cursor position update. Now we only do the sync for blits and XAA operations and I've never seen a lockup because of the hardware cursor. Anyway, Alan, can you try if disabling Silken mouse or even using SW cursor (make sure you have the fix for crashes with SW cursor and DRI though :) makes a difference? The 3D app is burning a lot of CPU and the system is otherwise running. At the point the 3D is killed (kill -9 etc) the box hangs solid Classical chip crash or lockup. :\ -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On 22 Feb 2003, Michel Dänzer wrote: On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: On 22 Feb 2003, Michel Dänzer wrote: On Sam, 2003-02-22 at 00:48, Alan Cox wrote: I do wonder if the register writes in RADEONSetCursorPosition() could interfere with the CP to cause FIFO overflows. Does anyone have an idea how to determine whether writes to certain registers go through the FIFO? I asked ATI devrel about this but didn't get a reply. :( The only indication that these might not is that I'd expect it to cause problems much more frequently if they did. IIRC, at least on mach64, hardware cursor position updates don't go through the draw engine FIFO Good, that makes a lot of sense of course. (any registers below dword offset 0x040 don't use the FIFO), Where did you find this information? Have you found anything similar about Radeons anywhere? It's in the register reference and programmer's guide. I don't have docs on Radeons, so I don't know if there is a similar convention there. so locking isn't necessary. However, we do lock the DRM when updating the cursor image, since it blits the image to the framebuffer through the host data FIFO. The radeon driver writes it to the framebuffer directly. Actually, looking at it again, so does mach64 (I was thinking of an XAA function). However, the DDX does an XAA sync before writing the cursor image to synchronize the framebuffer access. Since we do the 3D/2D sync in the XAA sync, I had to put a DRILock/Unlock around it. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003 crash with current trunk
On Thu, 20 Feb 2003, Leif Delgass wrote: On Thu, 20 Feb 2003, Philip Brown wrote: On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote: Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on Debian unstable and the latest demo release of UT2003 (v2206 -- which is purported to not need S3TC extensions), I get the following traceback reported by UT2003: phil@trigger /scratch/phil/ut2k3/demo ./ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. ??? This looks like you are using Xig libGL.so library. Deinstall Xig libs before doing tests like this. No, that's ut2k3 looking for S3TC support. Actually, I'm not sure it's S3TC. There may be some other functionality in that X extension that it looks for. In any case, that message just means it couldn't find that X server extension. I see that and I've never had XiG drivers installed. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] UT2003 crash with current trunk
On Thu, 20 Feb 2003, Daniel Vogel wrote: On Thu, 20 Feb 2003, Philip Brown wrote: On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote: Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on Debian unstable and the latest demo release of UT2003 (v2206 -- which is purported to not need S3TC extensions), I get the following traceback reported by UT2003: phil@trigger /scratch/phil/ut2k3/demo ./ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. ??? This looks like you are using Xig libGL.so library. Deinstall Xig libs before doing tests like this. No, that's ut2k3 looking for S3TC support. No. BTW, the above warning message is harmless IIRC. Yeah, I realized my error just after posting it (see my reply to myself). ;) [ 6] /usr/X11R6/lib/modules-dri-trunk/dri/mga_dri.so [0x43f31fb7] [ 7] /scratch/phil/ut2k3/demo/System/OpenGLDrv.so(DrawPrimitive__ 22FOpenGLRenderInterface14EPrimitiveType+0x373) Might be interesting to know why it crashes inside the driver :) I agree. Based on the MESA_DEBUG log, It looks like ARB_texture_env_combine isn't supported in the MGA driver. I see defines for what look like combiner registers, but it's not implemented in the driver yet (I don't have hardware docs myself so I don't know the specifics of what the cards can do). The INVALID_ENUMS here appear to be the result of that and a lack of ARB_texture_cube_map (neither of which are in core OpenGL 1.2). However, the driver shouldn't cause a segfault even with a bad enum. A trace from gdb would be helpful, I think. On the plus side, the R100 and R200 drivers now support ATI_texture_env_combine3 and one bug that was causing vertex corruption in the intro cinematic in the R100 driver was fixed. However, there are still vertex problems that appear to be in the R100 driver to track down. I can't test R200, so I'm not sure what the status is there. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ 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, this commit includes references to rmesa-hw.cube[], which isn't in radeon_context.h yet. I don't see any reason not to commit the entire cube map patch, but leave the extension disabled. I haven't had time to investigate the problems yet, but most of the code looks to be identical to r200. At any rate, I haven't encountered any regressions as a result of having the patch applied. With the extension enabled, the cubemap demo seems to kind of work, but it seems to only use the yellow cube face. Is that what you were seeing? On Wed, 19 Feb 2003, Ian Romanick wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: idr@sc8-pr-cvs1.03/02/19 09:00:33 Log message: Cut dead code calculations from uploadSubImage. Added support to uploadSubImage for face 1 (required for eventual cube_map support). Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: Tag: texmem-0-0-1 radeon_texmem.c Revision ChangesPath 1.11.14.8 +26 -21xc/xc/lib/GL/mesa/src/drv/radeon/radeon_texmem.c --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ 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)
On Wed, 19 Feb 2003, Ian Romanick wrote: Leif Delgass wrote: Ian, this commit includes references to rmesa-hw.cube[], which isn't in radeon_context.h yet. I don't see any reason not to commit the entire cube map patch, but leave the extension disabled. I haven't had time to investigate the problems yet, but most of the code looks to be identical to r200. At any rate, I haven't encountered any regressions as a result of having the patch applied. D'oh! The problem is that part of the (full) patch modifies kernel code. I don't want to get into a situation where we have funky non-working kernel code floating around. I should either back out the broken stuff that I put in or commit the rest of the user-side cube_map support. Ugh. With the extension enabled, the cubemap demo seems to kind of work, but it seems to only use the yellow cube face. Is that what you were seeing? Yeah, that's exactly what I see. Any thoughts? I don't have docs, so I can't verify that we're not missing any relevant bits. The r200 has pp_texformat_x, which has a bit for the texcoord use: non-projective, cubic, volume, etc. I don't see anything like that for R100. I tried modifying the texgen matrices to swap the third and fourth columns, but it didn't seem to have an effect. The upload code looks like it's the same as r200, but I haven't tried to verify that it's working right. Do you know which face the yellow one is? -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Tue, 18 Feb 2003, Martin Spott wrote: On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote: On Fri, 2003-02-14 at 14:52, Martin Spott wrote: Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Mike Harris builds in Red Hat beta and in rawhide It appears to me that the kernel modules of Mike's build do not differ from XFree86 4.2.99.901 - at least he didn't include any additional patches that thouch the kernel modules. I have the impression he also did not include any patches that touch the Radeon driver in a way that might prevent from lockups. So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? Martin. I noticed that Michel's fix for large textures in radeon_cp_dispatch_texture() has only been in XFree86 cvs since 4.2.99.902 (about 10 days ago). I'm not sure if the problem that fixed could cause a lockup, but you might want to try building a DRM from current X cvs and see if it makes a difference. -- Leif Delgass http://www.retinalburn.net --- 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 Independence and Mach64
On Tue, 18 Feb 2003, [iso-8859-15] José Fonseca wrote:
On Mon, Feb 17, 2003 at 08:15:02PM -0500, Leif Delgass wrote:
As I was doing some minor cleanups in the mach64 drm in the new branch, I
made some additional search and replace conversions of the mach64 DRM to
the os independence macros (I couldn't restrain myself ;) ). However, I
want to share what I've done so far and get some feedback, since there are
a couple of issues here:
1. We are currently using access_ok() to check the vertex buffers
submitted by the client before copying them to (what will be) private
kernel buffers. There was only a macro in drm_os_linux.h for
DRM_VERIFYAREA_READ(), so I added DRM_ACCESSOK_READ(). I don't really
know the details of what the difference is between verify_area() and
access_ok() (Jose added that code based on a suggestion from Linus, I
think), but I believe access_ok() is intended as a security check, which
is the reason for the copy. It seems that this all maps to the same thing
for *BSD at the moment -- i.e. the unchecked macros aren't implemented
differently from the checked ones, right?
They seem to be equivalent, onyle the semantics of the return value
differ. Here is the definition of verify_area in my distribution kernel
sources (linux-2.4.20-gentoo-r1), in include/asm-i386/uaccess.h:
static inline int verify_area(int type, const void * addr, unsigned long size)
{
return access_ok(type,addr,size) ? 0 : -EFAULT;
}
So perhaps we should converge on one.
OK, I've changed this to use DRM_VERIFYAREA_READ().
I also made some other changes to the copy/verify:
I added a check to the ioctl handler (mach64_dma_vertex) to check that the
vertex buffer has an integral number of dwords (in addition to the check
against MACH64_BUFFER_SIZE). I also changed copy_and_verify_from_user to
return an error code instead of the number of bytes copied. I don't see
any reason to dispatch a buffer unless all checks succeed (in fact it can
potentially cause lockups if we submit a partial buffer), so it's either
all or nothing. If it succeeds then we just copy buf-used to the private
buffer struct. This also allows us to return a more meaningful error
code, e.g. EFAULT for failed verify_area/copy_from_user, EINVAL for bad
command counts or buffer size, and EACCES for disallowed register commands
in the buffer. It also lets us get rid of the 'copied' local var and a
couple of adds inside the loop. A couple of other minor tweaks I made
were copying the byte length parameter to a local var and declaring the
function as inline. It also now will generate an error if there is a
register command without at least one data dword following it (in addition
to checking for a command count that overflows buf-used). That check is
now the new loop condition (n 1 instead of n (!=0) ), so it doesn't add
anything inside the loop. There is one extra conditional in the loop now
to check the return of copy_from_user. All of this may or may not have
much of a performance effect, but it is a pretty critical code path, I
think.
2. The Mach64 driver makes heavy use of the list struct and macros from
linux/list.h. I moved the define for list_for_each_safe() (needed for
older 2.4 Linux kernels) from mach64_drv.h to drmP.h, since that has
already been added in XFree86 CVS (I think the i8x0 drm uses it now also).
I also removed the include of linux/list.h from the mach64 driver, since
it already gets included (indirectly?) through the drm headers. However,
it looks like an analogue of linux/list.h might need to be added to the
BSD drm headers. The only wrinkle there is that it also uses
linux/prefetch.h.
FYI Eric, here's what we're currently using from linux/list.h:
struct list_head
INIT_LIST_HEAD()
list_entry()
list_for_each()
list_for_each_safe()
list_del()
list_add_tail()
list_empty()
3. We still need to work out the wrapper/alternative to
pci_alloc_consistent() and friends.
I'm still reading Ian texmem-2 proposal and looking to the source code
to get a hold of this.
Something I have in my old tree that I haven't merged to the new branch
yet is setting up the ring in AGP when available. That will get rid of
the use of pci_alloc_consistent for AGP cards. However we still can't do
private buffers in AGP without multiple buffer lists. However, it might
be enough to allow porting/testing on *BSD to continue with the PCI mode
setup in mach64_dma.c disabled (with the current temporary code that
uses client buffers instead of secure buffers).
Eric, do you have hardware to test on?
4. As I mentioned before, the interrupt code is not converted, but it's
currently unused.
My memory is failing: this might still be usefull for Xv, isn't it?
Maybe, maybe not. DMA for XVideo seems to be of questionable value,
judging from the Rage 128 driver. Plus the fact that you have to
wait/sync when switching between GUI masters and system masters. I've
Re: [Dri-devel] DRM OS Independence and Mach64
On Tue, 18 Feb 2003, Leif Delgass wrote: My memory is failing: this might still be usefull for Xv, isn't it? Maybe, maybe not. DMA for XVideo seems to be of questionable value, judging from the Rage 128 driver. Plus the fact that you have to wait/sync when switching between GUI masters and system masters. I've used interrupts to test page flipping with vsync. However, this is also of questionable utility. Page flipping without vsync doesn't really buy anything, since it has to be done synchronously (block until the vertical counter resets). What I meant to say here is that page flipping without vsync _interrupts_ on mach64 doesn't buy you much. It's not possible to do page flipping _without_ syncing the flip to the refresh on mach64. Doing it without interrupts means polling the vertical counter: either block until the counter resets, or poll whenever you have new buffers to see if you can commit them. The latter is not much different from my interrupt method. I got interrupts working using an atomic commit flag that's set on vblank and checked when adding buffers to the ring, since I was getting lockups trying to do the commit in the bottom half. Ideally, you would commit the ring in the bottom half, so the card can work in the time between the interrupt and the arrival of the next buffer from the client. One advantage is that it seems to smooth out some of the stutters in rendering as well as eliminating tearing, but at the cost of reducing the framerate if the app can't keep up with the vertical refresh. Most apps on mach64 (other than gears) don't fall into that category. :( To clarify, here I meant that most apps fall in the category of having a framerate _slower_ than the refresh. -- Leif Delgass http://www.retinalburn.net --- 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 Independence and Mach64
On Tue, 18 Feb 2003, Linus Torvalds wrote:
On 19 Feb 2003, Alan Cox wrote:
copy_from_user sorts out the whole thing itself. In general
__copy_from_user and verify_area isnt a win, except if you do lots of
small copies to/from the same area, which is often a bad idea anyway.
It _can_ be a good idea, though.
In particular, it's a _really_ good idea if the loop is basically a
glorified memcpy, at which point it can be very much worthwhile to move
the limit checking outside the loop.
An example of this is doing things like copy-and-checksum, or, in the
case of DRM copy-and-check-validity, where the code should sanely look
something like
u32 *addr; /* Command list */
if (!access_ok(VERIFY_READ, addr, size))
return -EFAULT;
while (size 0) {
unsigned int cmd;
if (__get_user(cmd, addr))
goto efault;
addr++;
switch (cmd) {
... verify it ...
}
*dst++ = cmd;
}
where the difference between a get_user() and a __get_user() can be
quite noticeable (the unchecked version is usually a single instruction in
size and has no nasty branch behaviour or anything like that, while the
checking version usually has at least one conditional branch and uses up
one or two registers etc).
Of course, this is really only worth doing for tight loops that really
matter. If the code in the loop is crap, the optimization just isn't worth
the complexity.
(And the extreme case of this is when the code is _so_ performance
critical that you end up writing it all in assembly language. The example
of this is the TCP copy-and-checksum stuff. The above example is somewhere
between the normal usage and the TCP copy-and-checksum extremes).
Linus
The code is similar to this, but with a couple of differences. We have to
split apart 'cmd' into two local vars (swapping bytes for big-endian) and
verify them (register address and count of data dwords following). If the
verify passes, we copy the command as in the last line of the loop above,
but then we need to __copy_from_user up to 7 dwords of data into the
destination without reading it. So it's a loop of alternating 1 dword
read/verify/write and 1-7 dwords straight copy.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
On Wed, 19 Feb 2003, [iso-8859-15] José Fonseca wrote: On Tue, Feb 18, 2003 at 06:30:40PM -0500, Leif Delgass wrote: I also made some other changes to the copy/verify: I added a check to the ioctl handler (mach64_dma_vertex) to check that the vertex buffer has an integral number of dwords (in addition to the check against MACH64_BUFFER_SIZE). I also changed copy_and_verify_from_user to return an error code instead of the number of bytes copied. I don't see any reason to dispatch a buffer unless all checks succeed (in fact it can potentially cause lockups if we submit a partial buffer), so it's either all or nothing. If it succeeds then we just copy buf-used to the private buffer struct. This also allows us to return a more meaningful error code, e.g. EFAULT for failed verify_area/copy_from_user, EINVAL for bad command counts or buffer size, and EACCES for disallowed register commands in the buffer. It also lets us get rid of the 'copied' local var and a couple of adds inside the loop. At that time I coded that way as an aid to debug that code. Now I don't see any problem in letting that go. A couple of other minor tweaks I made were copying the byte length parameter to a local var and declaring the function as inline. It also now will generate an error if there is a register command without at least one data dword following it (in addition to checking for a command count that overflows buf-used). That check is now the new loop condition (n 1 instead of n (!=0) ), so it doesn't add anything inside the loop. There is one extra conditional in the loop now to check the return of copy_from_user. All of this may or may not have much of a performance effect, but it is a pretty critical code path, I think. My impression is that the effect of the copy/verify is noticeable in slower machines but neglectable in faster. But I guess that the hit is probably more related to the processor cache than its actual speed. At some point, I'm planning on trying out oprofile with the new branch. Last time I looked, a lot of time seemed to be spent in freelist_get waiting for free buffers, but I think that was also before copy/verify. 3. We still need to work out the wrapper/alternative to pci_alloc_consistent() and friends. I'm still reading Ian texmem-2 proposal and looking to the source code to get a hold of this. It's now official: I'm coding on this. I'm adding the _ioctl suffix to most IOCTLs (e.g., agp_alloc - agp_alloc_ioctl) to leave to the agp_alloc for internal DRM usage, and writing a set of pci_* to wrap the pci_*_consistent and pci_pool_* API in the Linux. Nothing of this will break binary compatability and will allow one to [optionally] setup all main DMA buffers from within DRM_IOCTL_DMA IOCTL instead of the X server. Of course that I would like to pursue this idea in Mach64 driver. I'll be interested to see what you come up with. How much of the setup in atidri.c were you thinking of moving to the kernel? We'd still need to allow for XF86Config options dealing with the AGP aperture and buffer region size(s), as well as passing a handles back to the Xserver for the AGP aperture (to setup the AGP registers) and the AGP texture map (although maybe the Mesa client could just get it with a get_param ioctl). If the Xserver does it, it needs to leave space for the private buffers in AGP when calculating the region sizes/offsets. Something I have in my old tree that I haven't merged to the new branch yet is setting up the ring in AGP when available. That will get rid of the use of pci_alloc_consistent for AGP cards. However we still can't do private buffers in AGP without multiple buffer lists. However, it might be enough to allow porting/testing on *BSD to continue with the PCI mode setup in mach64_dma.c disabled (with the current temporary code that uses client buffers instead of secure buffers). BTW, is it OK to enable snapshots from the 0-0-6 branch instead? I think that would be fine, but I think that might mean that the extras package will be required too. BTW, what's the status of the trunk snaphots? Are we waiting for 4.3.0 to start those again? -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM OS Independence and Mach64
As I was doing some minor cleanups in the mach64 drm in the new branch, I
made some additional search and replace conversions of the mach64 DRM to
the os independence macros (I couldn't restrain myself ;) ). However, I
want to share what I've done so far and get some feedback, since there are
a couple of issues here:
1. We are currently using access_ok() to check the vertex buffers
submitted by the client before copying them to (what will be) private
kernel buffers. There was only a macro in drm_os_linux.h for
DRM_VERIFYAREA_READ(), so I added DRM_ACCESSOK_READ(). I don't really
know the details of what the difference is between verify_area() and
access_ok() (Jose added that code based on a suggestion from Linus, I
think), but I believe access_ok() is intended as a security check, which
is the reason for the copy. It seems that this all maps to the same thing
for *BSD at the moment -- i.e. the unchecked macros aren't implemented
differently from the checked ones, right?
2. The Mach64 driver makes heavy use of the list struct and macros from
linux/list.h. I moved the define for list_for_each_safe() (needed for
older 2.4 Linux kernels) from mach64_drv.h to drmP.h, since that has
already been added in XFree86 CVS (I think the i8x0 drm uses it now also).
I also removed the include of linux/list.h from the mach64 driver, since
it already gets included (indirectly?) through the drm headers. However,
it looks like an analogue of linux/list.h might need to be added to the
BSD drm headers. The only wrinkle there is that it also uses
linux/prefetch.h.
3. We still need to work out the wrapper/alternative to
pci_alloc_consistent() and friends.
4. As I mentioned before, the interrupt code is not converted, but it's
currently unused.
At any rate, the remainder of the attached patch is trivial additions of
DRM_ERR, DRM_CURRENTPID, etc. and a couple of whitespace tweaks.
--
Leif Delgass
http://www.retinalburn.net
Index: linux/drm/kernel/drmP.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h,v
retrieving revision 1.56
diff -u -r1.56 drmP.h
--- linux/drm/kernel/drmP.h 11 Jan 2003 20:58:20 - 1.56
+++ linux/drm/kernel/drmP.h 18 Feb 2003 00:33:29 -
@@ -166,6 +166,12 @@
#define pte_unmap(pte)
#endif
+#ifndef list_for_each_safe
+#define list_for_each_safe(pos, n, head) \
+ for (pos = (head)-next, n = pos-next; pos != (head); \
+ pos = n, n = pos-next)
+#endif
+
#if LINUX_VERSION_CODE KERNEL_VERSION(2,4,19)
static inline struct page * vmalloc_to_page(void * vmalloc_addr)
{
Index: linux/drm/kernel/drm_os_linux.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_os_linux.h,v
retrieving revision 1.5
diff -u -r1.5 drm_os_linux.h
--- linux/drm/kernel/drm_os_linux.h 9 Oct 2002 16:29:01 - 1.5
+++ linux/drm/kernel/drm_os_linux.h 18 Feb 2003 00:33:30 -
@@ -34,6 +34,8 @@
/* Macros for copyfrom user, but checking readability only once */
#define DRM_VERIFYAREA_READ( uaddr, size ) \
verify_area( VERIFY_READ, uaddr, size )
+#define DRM_ACCESSOK_READ( uaddr, size ) \
+ access_ok( VERIFY_READ, uaddr, size )
#define DRM_COPY_FROM_USER_UNCHECKED(arg1, arg2, arg3) \
__copy_from_user(arg1, arg2, arg3)
#define DRM_GET_USER_UNCHECKED(val, uaddr) \
@@ -60,28 +62,28 @@
#define DRM_HZ HZ
-#define DRM_WAIT_ON( ret, queue, timeout, condition ) \
-do { \
- DECLARE_WAITQUEUE(entry, current); \
- unsigned long end = jiffies + (timeout);\
- add_wait_queue((queue), entry); \
- \
- for (;;) { \
- current-state = TASK_INTERRUPTIBLE;\
- if (condition) \
- break; \
- if((signed)(end - jiffies) = 0) { \
- ret = -EBUSY; \
- break; \
- } \
+#define DRM_WAIT_ON( ret, queue, timeout, condition ) \
+do { \
+ DECLARE_WAITQUEUE(entry, current); \
+ unsigned long end = jiffies + (timeout);\
+ add_wait_queue((queue), entry); \
+ \
+ for (;;) { \
+ current-state
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mach64-0-0-6-branch)
Eric, I cvs up-ed to get this change, and I just wanted to let you know that I went ahead and moved the module info and ioctl defs from mach64_drv.c to the shared mach64.h. It's compiling fine for me. I'll leave you to it now. :) FYI, the interrupt stuff is unused right now, it's just left in for experimenting with pageflipping and such. --Leif On Sun, 16 Feb 2003, Eric Anholt wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ Changes by: anholt@sc8-pr-cvs1. 03/02/16 11:03:04 Log message: Move the mach64 DRM files to shared/drm/kernel. Modified files: xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/: Tag: mach64-0-0-6-branch Imakefile xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: Tag: mach64-0-0-6-branch Imakefile Added files: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/:Tag: mach64-0-0-6-branch mach64.h mach64_dma.c mach64_drm.h mach64_drv.h mach64_state.c Removed files: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: Tag: mach64-0-0-6-branch mach64.h mach64_dma.c mach64_drm.h mach64_drv.h mach64_state.c Revision ChangesPath 1.14.8.1 +5 -0 xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/Imakefile 1.11.8.1 +5 -0 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Imakefile --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches -- Leif Delgass http://www.retinalburn.net --- 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] mach64-0-0-6-branch
On 15 Feb 2003, Eric Anholt wrote: On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. I've been working on this locally a little, but haven't tackled the pci_alloc_consistent in a proper manner yet (the corresponding interface for us is bus_dma, which I am just beginning to understand while working on ati_pcigart.h/drm_scatter.h conversion). If you would approve of me moving the mach64 files to shared/drm/kernel, I could at least work on things incrementally (much of this stuff is mechanical changes), and then hopefully provide something pretty to review for pci_alloc_consistent. As long as the Linux build still works, that's fine by me. If you want to create the makefile links, move it to shared, and work on macro-izing the ioctls and whatnot, go for it. I was going to do this eventually, but if you're eager to get started, that's great. Of course, this will all have to happen in the mach64-0-0-6-branch for now, until we get the DRM interface/security changes done. -- Leif Delgass http://www.retinalburn.net --- 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 Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, Mike A. Harris wrote: On Fri, 14 Feb 2003, Leif Delgass wrote: I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Alan. What about dri-patches? It gets all the same spam that -devel and -users do. I don't see any reason not to restrict posting to that list to project members. Of course, there may be people with commit access that aren't subscribed. Is there a way to restrict it to sourceforge accounts rather than the subscriber list? Why not just have posts from non-members moderated? They would get held long enough for someone to look at them and go ah, this is not spam, then accept the message for posting. Of course, that would mean a message would get held until a moderator could look at it. I do this on our xfree86-list, and it works well. I dunno if that would be something one of the list maintainers would want to do or not though. Just a suggestion nonetheless. On the other side of things, spamassassin rocks. It nails almost all of my spam. A good 93% to date anyway. I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. -- Leif Delgass http://www.retinalburn.net --- 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] Your message to Dri-patches awaits moderator approval (fwd)
Speaking of Dri-patches... ;) There seems to be a problem with the @users.sourceforge.net wildcard address in the subscriber list. I'm subscribed to Dri-patches, but not with my sourceforge email. -- Leif Delgass http://www.retinalburn.net -- Forwarded message -- Date: Sat, 15 Feb 2003 18:01:02 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Your message to Dri-patches awaits moderator approval Your mail to 'Dri-patches' with the subject CVS Update: xc (branch: mesa-4-0-4-branch) Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. --- 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 Mailing list maintanence / maintaner
What about people getting the list as a digest? Also, the spam ends up in the mail archives. On Sat, 15 Feb 2003, D. Hageman wrote: I have only been glancing at this thread, but basically it comes down to this - If the spam bothers you that much setup spam filtering on your personal machine and be done with it. We waste more time and bandwidth talking about what should be done (with the list) then actually doing what really should be done (with dri). Just my thoughts ... On Sat, 15 Feb 2003, Leif Delgass wrote: On Sat, 15 Feb 2003, Mike A. Harris wrote: On Fri, 14 Feb 2003, Leif Delgass wrote: I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Alan. What about dri-patches? It gets all the same spam that -devel and -users do. I don't see any reason not to restrict posting to that list to project members. Of course, there may be people with commit access that aren't subscribed. Is there a way to restrict it to sourceforge accounts rather than the subscriber list? Why not just have posts from non-members moderated? They would get held long enough for someone to look at them and go ah, this is not spam, then accept the message for posting. Of course, that would mean a message would get held until a moderator could look at it. I do this on our xfree86-list, and it works well. I dunno if that would be something one of the list maintainers would want to do or not though. Just a suggestion nonetheless. On the other side of things, spamassassin rocks. It nails almost all of my spam. A good 93% to date anyway. I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. -- Leif Delgass http://www.retinalburn.net --- 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] DRI Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, Alan Hourihane wrote: On Fri, Feb 14, 2003 at 03:34:45 -0700, Brian Paul wrote: Smitty wrote: Hi Rich Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribers for approval. I'd even be willing to sort the non-subscribed emails, so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g I'd be happy to see postings restricted to subscribers too. Unfortunately, I don't know what the list-admin password is. Maybe Daryll or Rik do? I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Alan. What about dri-patches? It gets all the same spam that -devel and -users do. I don't see any reason not to restrict posting to that list to project members. Of course, there may be people with commit access that aren't subscribed. Is there a way to restrict it to sourceforge accounts rather than the subscriber list? -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiplei810/830M X servers
On Fri, 14 Feb 2003, Ian Romanick wrote: Leif Delgass wrote: On Fri, 14 Feb 2003, David Dawes wrote: [snip] There are some more serious things holding up 4.3, including the issue that Leif mentioned here a couple of days ago. I haven't seen anyone comment on his proposed solution for that one either... David I was wondering about that myself. :) I'll reiterate the problem, but this time with a patch to give people something more concrete to comment on. This is, I think, the easiest and quickest fix, if not necessarily the most correct. This patch does the following: 1. Move the __driGarbageCollectDrawables() call in driDestroyContext() back after the driver's DestroyContext() callback as in the original patch in the DRI mesa-4-0-4-branch. This avoids the issue of the drawable being destroyed before the driver tries to reference it, at least in the observed case in the Radeon driver's DestroyContext(). As per our earlier discussions about this patch, I think that this is absolutely correct. The old code is clearly wrong. Does anybody know why the patch was reverted??? As far as I can tell, an additional fix for the infinite loop on getting the drawable info was added (using __driFindDrawable()), and it was assumed that this part of the patch wasn't needed. Probably the double-free issue wasn't known to be there? (There's no segfault, so you'd have to use MALLOC_CHECK_ to see it in testing). 2. Free pBackClipRects in driDestroyDrawable(). This fixes a potential memory leak if there are back-buffer cliprects when the drawable is destroyed. I'm pretty sure this a seperate issue and a valid fix. That seems okay too. Is there any way to verify that the memory leak could actually ever happen? I put a printf in the block where pBackClipRects is freed (in the patched version), and I can get it to trigger when closing multiple texobj instances, e.g. I ran them both with MALLOC_CHECK_, and there's no double-free happening. So yes, it seems it can happen. 3. As an added sanity measure, set pClipRects and pBackClipRects pointers to NULL in the drawable private struct when they are freed, before freeing the struct. This _might_ prevent a mirrored private drawable struct pointer held by a driver from pointing to invalid cliprect pointers. However, it won't change the fact that the mirrored private drawable struct pointer itself would be invalid. This change is pretty dubious, as it has the potential to hide the actual problem. I don't think this should take the place of fix #1. If the mirrored private drawable pointer itself is invalid, dereferencing it produces undefined behavior. For debugging, would we just over-write the whole private drawable struct with garbage? Is there anyway to back track and NULL out the mirrored pointer when the private drawable is destroyed? Well, as I mentioned, the driDestroyDrawable() function calls the driver's DestroyBuffer() right before freeing the private struct, so the driver could NULL out it's mirrored pointer then. But that means checking for a NULL private drawable in any code that could be reached after that point. __driUtilUpdateDrawableInfo() should never be called with a NULL or invalid private drawable pointer as it stands now, as the result of freeing the cliprects is undefined behavior (even with Fix #3). Moving the __driGarbageCollectDrawables() call avoids all this, at least for context teardown. The other place __driGarbageCollectDrawables() is called is at the end of driCreateContext(). At that point, the driver's CreateContext() has been called, which initializes the drawable private pointer to NULL. The pointer first gets a real value when the context is made current. I don't see any other way that the drawable could be destroyed before the driver's context is, with Fix #1 in place. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiplei810/830M X servers
On Fri, 14 Feb 2003, David Dawes wrote:
[snip]
There are some more serious things holding up 4.3, including the issue
that Leif mentioned here a couple of days ago. I haven't seen anyone
comment on his proposed solution for that one either...
David
I was wondering about that myself. :) I'll reiterate the problem, but this
time with a patch to give people something more concrete to comment on.
This is, I think, the easiest and quickest fix, if not necessarily the
most correct. This patch does the following:
1. Move the __driGarbageCollectDrawables() call in driDestroyContext()
back after the driver's DestroyContext() callback as in the original patch
in the DRI mesa-4-0-4-branch. This avoids the issue of the drawable being
destroyed before the driver tries to reference it, at least in the
observed case in the Radeon driver's DestroyContext().
2. Free pBackClipRects in driDestroyDrawable(). This fixes a potential
memory leak if there are back-buffer cliprects when the drawable is
destroyed. I'm pretty sure this a seperate issue and a valid fix.
3. As an added sanity measure, set pClipRects and pBackClipRects pointers
to NULL in the drawable private struct when they are freed, before freeing
the struct. This _might_ prevent a mirrored private drawable struct
pointer held by a driver from pointing to invalid cliprect pointers.
However, it won't change the fact that the mirrored private drawable
struct pointer itself would be invalid. This change is pretty dubious, as
it has the potential to hide the actual problem. I don't think this
should take the place of fix #1. If the mirrored private drawable pointer
itself is invalid, dereferencing it produces undefined behavior.
If we don't use Fix #1, the alternative is to modify the drivers to set
the mirrored drawable pointer to NULL in the DestroyBuffer() callback and
deal with the possibility of a NULL drawable pointer in any code that can
be called after DestroyBuffer(), e.g when locking and any state changes
made after the lock is acquired. This might be a more correct fix, but it
seems to me it would be more intrusive and require more checking for
side-effects.
--
Leif Delgass
http://www.retinalburn.net
Index: dri_util.c
===
RCS file: /cvs/xc/lib/GL/dri/dri_util.c,v
retrieving revision 1.5
diff -u -r1.5 dri_util.c
--- dri_util.c 2003/02/11 03:30:20 1.5
+++ dri_util.c 2003/02/14 22:50:11
@@ -629,7 +629,7 @@
pdp-numClipRects = 0;
pdp-pClipRects = NULL;
pdp-numBackClipRects = 0;
- pdp-pBackClipRects = 0;
+ pdp-pBackClipRects = NULL;
}
else
pdp-pStamp = (psp-pSAREA-drawableTable[pdp-index].stamp);
@@ -740,8 +740,14 @@
(*psp-DriverAPI.DestroyBuffer)(pdp);
if (__driWindowExists(dpy, pdp-draw))
(void)XF86DRIDestroyDrawable(dpy, scrn, pdp-draw);
- if (pdp-pClipRects)
+ if (pdp-pClipRects) {
Xfree(pdp-pClipRects);
+ pdp-pClipRects = NULL;
+ }
+ if (pdp-pBackClipRects) {
+ Xfree(pdp-pBackClipRects);
+ pdp-pBackClipRects = NULL;
+ }
Xfree(pdp);
}
}
@@ -763,8 +769,8 @@
psp-fullscreen = NULL;
}
}
- __driGarbageCollectDrawables(pcp-driScreenPriv-drawHash);
(*pcp-driScreenPriv-DriverAPI.DestroyContext)(pcp);
+ __driGarbageCollectDrawables(pcp-driScreenPriv-drawHash);
(void)XF86DRIDestroyContext(dpy, scrn, pcp-contextID);
Xfree(pcp);
}
[Dri-devel] Double-free in _driUtilUpdateDrawableInfo()
I think there is a problem with this patch: (http://marc.theaimsgroup.com/?l=xfree-cvsm=104493451323441w=2) 868. Revert the DestroyContext, GarbageCollectDrawables reording in dri_util.c, and instead check if the drawable is known to the DRI client code before calling XF86DRIGetDrawableInfo (Egbert Eich). The patch moves the call to __driGarbageCollectDrawables() in driDestroyContext() (dri_util.c) back before the call to the driver's DestroyContext() callback. However, when the radeon driver calls __driUtilUpdateDrawableInfo() in it's DestroyContext() (when locking the DRM), a double-free can happen on pdp-pClipRects. The problem is that the memory pointed to by pClipRects has already been freed by driDestroyDrawable() (via __driGarbageCollectDrawables()), but 'pdp' in the context of __driUtilUpdateDrawableInfo() is the radeon driver's mirrored copy of the drawable private struct, which still has a pointer to the freed pClipRects. In fact, the drawable private struct itself (pointed to by pdp) has also been freed, but again the mirrored pointer still exists in the radeon driver, so this pointer really shouldn't even be dereferenced. The easiest/quickest fix would be to move __driGarbageCollectDrawables() back to after the driver's DestroyContext() callback as in the original patch in DRI cvs. I think an argument could also be made that the (radeon) driver should NULL out it's mirrored drawable pointer in it's DestroyBuffer() callback, which is called by driDestroyDrawable() just before it destroys/frees the drawable. That would also require adding a check for a NULL drawable to the driver's locking function (probably just returning after the DRM lock ioctl). I'm not sure if there would be any other side effects to that change. Comments? It also looks to me like there could be a memory leak on pBackClipRects in driDestroyDrawable(). It looks like pBackClipRects should be freed there (if non-NULL) along with pClipRects. Is this freed somewhere that I'm missing? -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-6-branch
I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ 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)
On Fri, 7 Feb 2003, Keith Whitwell wrote:
I don't have a local copy of the mesa-4.0.4 branch. Could somebody
commit this change to that tree? It's a pretty easy fix should make
Linus happy. :)
I'll do it.
Actually, I take that back - I don't have an r200 handy to test the diff
didn't apply cleanly enough to wing it...
Anyone else?
Keith
Here's a hand-merged diff against mesa-4-0-4-branch. How does this look?
--
Leif Delgass
http://www.retinalburn.net
Index: r200_texstate.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c,v
retrieving revision 1.7
diff -u -r1.7 r200_texstate.c
--- r200_texstate.c 5 Nov 2002 21:19:50 - 1.7
+++ r200_texstate.c 7 Feb 2003 21:41:52 -
@@ -47,6 +47,7 @@
#include mmath.h
#include simple_list.h
#include texformat.h
+#include enums.h
static void r200SetTexImages( r200ContextPtr rmesa,
@@ -702,16 +703,19 @@
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
const struct gl_texture_unit *texUnit = ctx-Texture.Unit[unit];
+ const struct gl_texture_object *tObj = texUnit-_Current;
+ const GLenum format = tObj-Image[tObj-BaseLevel]-Format;
GLuint color_combine, alpha_combine;
GLuint color_scale = rmesa-hw.pix[unit].cmd[PIX_PP_TXCBLEND2];
GLuint alpha_scale = rmesa-hw.pix[unit].cmd[PIX_PP_TXABLEND2];
if ( R200_DEBUG DEBUG_TEXTURE ) {
- fprintf( stderr, %s( %p, %d )\n, __FUNCTION__, ctx, unit );
+ fprintf( stderr, %s( %p, %d ) format=%s\n, __FUNCTION__,
+ ctx, unit, _mesa_lookup_enum_by_nr( format ) );
}
/* Set the texture environment state. Isn't this nice and clean?
-* The R200 will automagically set the texture alpha to 0xff when
+* The chip will automagically set the texture alpha to 0xff when
* the texture format does not include an alpha component. This
* reduces the amount of special-casing we have to do, alpha-only
* textures being a notable exception.
@@ -729,6 +733,8 @@
const GLenum format = tObj-Image[tObj-BaseLevel]-Format;
GLuint color_arg[3], alpha_arg[3];
GLuint i, numColorArgs = 0, numAlphaArgs = 0;
+ GLuint RGBshift = texUnit-CombineScaleShiftRGB;
+ GLuint Ashift = texUnit-CombineScaleShiftA;
switch ( texUnit-EnvMode ) {
case GL_REPLACE:
@@ -867,6 +873,8 @@
case GL_SUBTRACT:
case GL_DOT3_RGB:
case GL_DOT3_RGBA:
+case GL_DOT3_RGB_EXT:
+case GL_DOT3_RGBA_EXT:
numColorArgs = 2;
break;
case GL_INTERPOLATE:
@@ -880,10 +888,10 @@
case GL_REPLACE:
numAlphaArgs = 1;
break;
-case GL_SUBTRACT:
case GL_MODULATE:
case GL_ADD:
case GL_ADD_SIGNED:
+case GL_SUBTRACT:
numAlphaArgs = 2;
break;
case GL_INTERPOLATE:
@@ -969,14 +977,6 @@
R200_COLOR_ARG( 0, A );
R200_COLOR_ARG( 1, C );
break;
-case GL_SUBTRACT:
- color_combine = (R200_TXC_ARG_B_ZERO |
-R200_TXC_COMP_ARG_B |
-R200_TXC_NEG_ARG_C |
-R200_TXC_OP_MADD);
- R200_COLOR_ARG( 0, A );
- R200_COLOR_ARG( 1, C );
- break;
case GL_ADD_SIGNED:
color_combine = (R200_TXC_ARG_B_ZERO |
R200_TXC_COMP_ARG_B |
@@ -985,16 +985,46 @@
R200_COLOR_ARG( 0, A );
R200_COLOR_ARG( 1, C );
break;
+case GL_SUBTRACT:
+ color_combine = (R200_TXC_ARG_B_ZERO |
+R200_TXC_COMP_ARG_B |
+R200_TXC_NEG_ARG_C |
+R200_TXC_OP_MADD);
+ R200_COLOR_ARG( 0, A );
+ R200_COLOR_ARG( 1, C );
+ break;
case GL_INTERPOLATE:
color_combine = (R200_TXC_OP_LERP);
R200_COLOR_ARG( 0, B );
R200_COLOR_ARG( 1, A );
R200_COLOR_ARG( 2, C );
break;
+
+case GL_DOT3_RGB_EXT:
+case GL_DOT3_RGBA_EXT:
+ RGBshift = 0;
+ Ashift = 0;
+ /* FALLTHROUGH */
+
case GL_DOT3_RGB:
case GL_DOT3_RGBA:
+ /* DOT3 works differently on R200 than on R100. On R100, just
+* setting the DOT3 mode did everything for you. On R200, the
+* driver has to enable the biasing (the -0.5 in the combine
+* equation), and it has add the 4x scale factor. The hardware
+* only supports up to 8x in the post filter, so 2x part of it
+* happens on the inputs going into the combiner.
+*/
+
+ RGBshift++;
+ Ashift = RGBshift
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Wed, 5 Feb 2003, Leif Delgass wrote: Also, should I go ahead and commit my revised texmem patch? Yes. OK, will do. Do you want to commit your patch for combine3 to texmem? I don't have an R200, so I can't test that, but it looks like it should be easy to add there too. If SUBTRACT is the only problem, I don't think that should prevent you committing it, as that's apparently a problem even without the extension. I went ahead and committed my texmem changes as well as combine3 for radeon and r200 (including the change to the zero/one table). I can't test the r200 version, but it looks almost identical to R100. I noticed that in the check for the scale factor in the Radeon driver, it uses RADEON_SCALE_4X for dot3. Should that be RADEON_SCALE_1X? That's what the r200 driver uses for the EXT version (R200_TX[C,A]_SCALE_1X). -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Thu, 6 Feb 2003, Ian Romanick wrote: Some time ago there were some scissor problems that caused every glean test to always fail. I think those were fixed in the radeon and r200 drivers about 6 months ago. On my R100 the only tests that failed for me were the subtract tests and the alpha channel in some combinations of DOT3. I haven't had a chance to dig into that either. ok. I'll try again and see if I'm still getting scissor problems. Intuitively, it seems that NONE of these drivers, except Mach64 Rage128, is reporting the right thing. There seems to be at least one field wrong in each. I'm not 100% clear on the meaning of all the fields, so I could be wrong. Hopefully Brian or Keith can enlighten us on what they should mean. :) I'm mostly unsure of what amask means in this context. amask here is the mask for the alpha channel in the framebuffer. The reason I brought this up is that I think glean will ignore differences in the alpha component and skip cases using destination alpha read from the framebuffer if the visual reports 0 alpha bits, and I thought this might be the cause of some of the failures. I guess my question is, should the alpha bits, alpha mask, buffer size, and visual depth reflect the framebuffer bits-per-pixel, or the presence of a destination alpha that's actually written to by the card when rendering and readable by the span functions (Radeon span functions currently read the alpha from the framebuffer, Rage128/mach64 always return 255). Mach64/R128 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 Radeon/R200 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 ff00 24 16 16 16 16 24 Shouldn't this be one of the following? 8 8 8 0 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 I know that in the XFree86 Radeon driver in 24-bit each pixel is actually 4 bytes, whether the alpha channel is used or not. MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. tdfx r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel) 8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel) 8 8 8 0 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Thu, 6 Feb 2003, Ian Romanick wrote: I went ahead and committed my texmem changes as well as combine3 for radeon and r200 (including the change to the zero/one table). I can't test the r200 version, but it looks almost identical to R100. Cool. I can't think of any reason why those changes couldn't also go into the trunk. Done. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Visuals
I found another one: i830_dri.c sets alphaSize = 0, alphaMask = 0xff00, and bufferSize = 32. In i830_span.c 255 is returned for alpha in the 32-bit read functions, with a comment: /* Note to Self: * Don't read alpha from framebuffer, because its not correct. From a * reading of the spec, this should not be the case, need to ask an * engineer at Intel. */ Until someone can fix the span reads, I'll assume destination alpha isn't working. I'll fix this one. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R100 GL_ATI_texture_env_combine3
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the registers. I'm attaching a patch of what I've got. My assumptions
are that RADEON_BLEND_CTL_[ADD,ADDSIGNED,SUBTRACT] will do the
corresponding MODULATE_[ADD,ADDSIGNED,SUBTRACT] with three args. Also,
I'm assuming I can use RADEON_[COLOR,ALPHA]_ARG_A_ZERO or-ed with
_COMP_ARG_A to get GL_ONE.
Does this look right? Ian, you mentioned seeing problems with SUBTRACT,
and in an older message you were wondering about the difference between
how r100 and r200 handle PREVIOUS. Two questions: Did you come to any
conclusions on either of those questions? and what are you using to test
this? I was thinking of trying to add support to the glean texcombine
test, but I wanted to see if you had something already.
Also, should I go ahead and commit my revised texmem patch?
--
Leif Delgass
http://www.retinalburn.net
Index: radeon_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c,v
retrieving revision 1.20.2.7
diff -u -r1.20.2.7 radeon_context.c
--- radeon_context.c5 Dec 2002 15:26:34 - 1.20.2.7
+++ radeon_context.c5 Feb 2003 19:19:51 -
@@ -137,6 +137,7 @@
GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_lod_bias,
+GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once,
GL_IBM_texture_mirrored_repeat,
GL_NV_blend_square,
Index: radeon_texstate.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_texstate.c,v
retrieving revision 1.8.2.5
diff -u -r1.8.2.5 radeon_texstate.c
--- radeon_texstate.c 5 Dec 2002 15:26:43 - 1.8.2.5
+++ radeon_texstate.c 5 Feb 2003 19:19:52 -
@@ -119,7 +119,7 @@
t-pp_txfilter |= tx_table[ baseImage-TexFormat-MesaFormat ].filter;
}
else {
- _mesa_problem(NULL, unexpected texture format in radeonTexImage2D);
+ _mesa_problem(NULL, unexpected texture format in %s, __FUNCTION__);
return;
}
@@ -198,7 +198,6 @@
assert(t-image[0][i].x == 0
|| (size BLIT_WIDTH_BYTES t-image[0][i].height == 1));
#endif
- curOffset += size;
if (0)
fprintf(stderr,
@@ -206,6 +205,9 @@
i, texImage-Width, texImage-Height,
t-image[0][i].x, t-image[0][i].y,
t-image[0][i].width, t-image[0][i].height, size, curOffset);
+
+ curOffset += size;
+
}
/* Align the total size of texture memory block.
@@ -670,6 +672,22 @@
RADEON_COLOR_ARG_A_CURRENT_ALPHA | RADEON_COMP_ARG_A
};
+static GLuint radeon_zero_color[] =
+{
+ RADEON_COLOR_ARG_A_ZERO,
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_COLOR_ARG_A_ZERO,
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A
+};
+
+static GLuint radeon_one_color[] =
+{
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_COLOR_ARG_A_ZERO,
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_COLOR_ARG_A_ZERO
+};
+
/* The alpha tables only have GL_SRC_ALPHA and GL_ONE_MINUS_SRC_ALPHA.
*/
static GLuint radeon_texture_alpha[][RADEON_MAX_TEXTURE_UNITS] =
@@ -704,6 +722,17 @@
RADEON_ALPHA_ARG_A_CURRENT_ALPHA | RADEON_COMP_ARG_A
};
+static GLuint radeon_zero_alpha[] =
+{
+ RADEON_ALPHA_ARG_A_ZERO,
+ RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A
+};
+
+static GLuint radeon_one_alpha[] =
+{
+ RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_ALPHA_ARG_A_ZERO
+};
/* Extract the arg from slot A, shift it into the correct argument slot
* and set the corresponding complement bit.
@@ -900,6 +929,9 @@
numColorArgs = 2;
break;
case GL_INTERPOLATE:
+case GL_MODULATE_ADD_ATI:
+case GL_MODULATE_SIGNED_ADD_ATI:
+case GL_MODULATE_SUBTRACT_ATI:
numColorArgs = 3;
break;
default:
@@ -917,6 +949,9 @@
numAlphaArgs = 2;
break;
case GL_INTERPOLATE:
+case GL_MODULATE_ADD_ATI:
+case GL_MODULATE_SIGNED_ADD_ATI:
+case GL_MODULATE_SUBTRACT_ATI:
numAlphaArgs = 3;
break;
default:
@@ -943,6 +978,12 @@
case GL_PREVIOUS:
color_arg[i] = radeon_previous_color[op];
break;
+ case GL_ZERO:
+ color_arg[i] = radeon_zero_color[op];
+ break;
+ case GL_ONE:
+ color_arg[i] = radeon_one_color[op];
+ break;
default:
return GL_FALSE;
}
@@ -965,6 +1006,12 @@
case GL_PREVIOUS
Re: [Dri-devel] Context teardown
On Wed, 5 Feb 2003, Keith Whitwell wrote: Ian Romanick wrote: Keith Whitwell wrote: The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Yes. The light-05 test in viewperf shows this bug on r200. If you want to send me your patch, I can try it out. There are now two patches, one from Egbert Eich (who reported the problem). I haven't had time to look at his as it changes some deep, dark, dri stuff that I wasn't ever involved with, but looks sane nonetheless. His avoids the error reply from the X server, whereas mine copes with it once it arrives. I'm not sure either will help texobj which seems to be a malloc/free bug. I'm attaching both. I actually think applying *both* is the way to go. The reordering in driDestroyDrawable fixes the X error with texobj for me. I never got a segfault running texobj outside of gdb. I do remember seeing one once while debugging, but I can't recall how I got there and can't reproduce it. Where did you see the malloc problem? --Leif --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Good advice! It looks like a double free in __driUtilUpdateDrawableInfo when freeing pdp-pClipRects. But at that point not only has pClipRects been freed, so has pdp! This happens (in the original code) with __driGarbageCollectDrawables being called before the driver's DestroyContext and the subsequent lock trying to operate on a drawable that doesn't exist. However, the context still has a copy of the drawable pointer, which now points to freed memory. So it looks like the first patch eliminates the problem in this case. However, I wonder if the driver's DestroyBuffer should set the context's drawable pointer to NULL, since that's called by driDestroyDrawable right before the drawable is freed. The problem there is we'd then need to fix the lock function to handle the case where there is no drawable. --Leif On Wed, 5 Feb 2003, Brian Paul wrote: Keith Whitwell wrote: Leif Delgass wrote: On Wed, 5 Feb 2003, Keith Whitwell wrote: Ian Romanick wrote: Keith Whitwell wrote: The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Yes. The light-05 test in viewperf shows this bug on r200. If you want to send me your patch, I can try it out. There are now two patches, one from Egbert Eich (who reported the problem). I haven't had time to look at his as it changes some deep, dark, dri stuff that I wasn't ever involved with, but looks sane nonetheless. His avoids the error reply from the X server, whereas mine copes with it once it arrives. I'm not sure either will help texobj which seems to be a malloc/free bug. I'm attaching both. I actually think applying *both* is the way to go. The reordering in driDestroyDrawable fixes the X error with texobj for me. I never got a segfault running texobj outside of gdb. I do remember seeing one once while debugging, but I can't recall how I got there and can't reproduce it. Where did you see the malloc problem? The segfault you report is inside malloc, but called from the X error handler. As the 2nd patch removes the error, you never get to malloc, but my guess is something is still screwy there. However, as you say, you only see this in gdb, so I don't know what that means... Someone could probably track down the malloc problem pretty quickly with ElectricFence or with libc's built-in memory debugger. From 'man malloc': Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment vari- ables. When MALLOC_CHECK_ is set, a special (less efficient) implemen- tation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immedi- ately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Wed, 5 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the registers. I'm attaching a patch of what I've got. My assumptions
are that RADEON_BLEND_CTL_[ADD,ADDSIGNED,SUBTRACT] will do the
corresponding MODULATE_[ADD,ADDSIGNED,SUBTRACT] with three args. Also,
I'm assuming I can use RADEON_[COLOR,ALPHA]_ARG_A_ZERO or-ed with
_COMP_ARG_A to get GL_ONE.
Those assumptions seem to be correct. For the most part, your patch
looks a lot like what I have in my local tree. :) The only thing I did
different was I overlapped the zero and one tables.
static GLuint radeon_zero_alpha[] =
{
RADEON_ALPHA_ARG_A_ZERO,
RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A,
RADEON_ALPHA_ARG_A_ZERO
};
OK, so you add one to op for GL_ONE then?
Does this look right? Ian, you mentioned seeing problems with SUBTRACT,
and in an older message you were wondering about the difference between
how r100 and r200 handle PREVIOUS. Two questions: Did you come to any
conclusions on either of those questions? and what are you using to test
this? I was thinking of trying to add support to the glean texcombine
test, but I wanted to see if you had something already.
WRT GL_PREVIOUS, my conclusion is that the I didn't understand the way
that r200 texture combiners work. :) It's actually quite different from
the r100. Based on numerous glean tests, both are correct.
About GL_SUBTRACT on r100, I just don't know. I hacked up the
ttexcombine test in glean to test GL_MODULATE_*_ATI and GL_SUBTRACT.
EVERY mode that uses subtraction failed on the r100. Looking at the
expected and got output from glean, I could see that it was
expecting the right thing, but the output was wrong.
Also, should I go ahead and commit my revised texmem patch?
Yes.
OK, will do. Do you want to commit your patch for combine3 to texmem? I
don't have an R200, so I can't test that, but it looks like it should be
easy to add there too. If SUBTRACT is the only problem, I don't think
that should prevent you committing it, as that's apparently a problem even
without the extension.
Regarding glean, I need to test again, but I was seeing some other
failures even with the mesa-4-0-4 and trunk. I think there were some
off-by-one scissor errors and a couple of others. One question I had was
whether the Radeon driver should really advertise a destination alpha
channel. At depth 24, glxinfo reports 8 bit alpha for color and accum
buffers. This doesn't seem to be consistent across the drivers. Some
don't even seem to be consistent for a given entry between alpha bits,
alpha mask, and buffer size. Here's a little chart I made a while back:
Mach64/R128
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 24 16 16 16 0 24
Radeon/R200
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 ff00 24 16 16 16 16 24
MGA
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
GLINT
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth)
8 8 8 0 32 16 16 16 0 24 (pScrn-depth)
tdfx
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel)
8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel)
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
You need to continue past this exception to get to the segfault. This is just Mesa testing for SSE. On Wed, 5 Feb 2003, Adam K Kirchhoff wrote: Hello all, So there's this really great game from Garagegames called MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the ATI FireGL drivers, but segfaults when trying to use the opensource drivers: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 16384 (LWP 2053)] 0x40c9fa70 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) bt #0 0x40c9fa70 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x40c9f7e7 in check_os_sse_support () at common_x86.c:191 #2 0x40c9f96d in _mesa_init_all_x86_transform_asm () at common_x86.c:275 #3 0x40c1b557 in _math_init () at m_xform.c:218 #4 0x40bada66 in one_time_init (ctx=0x8391a38) at context.c:564 #5 0x40bafee0 in _mesa_initialize_context (ctx=0x8391a38, visual=0xbfffbc40, share_list=0x0, driver_ctx=0x838e908, direct=1) at context.c:1663 #6 0x40bb083f in _mesa_create_context (visual=0xbfffbc40, share_list=0x0, driver_ctx=0x838e908, direct=1) at context.c:1900 #7 0x40ca483f in r200CreateContext (glVisual=0xbfffbc40, driContextPriv=0x838d350, sharedContextPrivate=0x0) at r200_context.c:252 #8 0x40b9ca94 in driCreateContext (dpy=0x8381a50, vis=0x838ce20, sharedPrivate=0x0, pctx=0x838e0d4) at dri_util.c:852 #9 0x40b53a07 in CreateContext (dpy=0x8381a50, vis=0x838ce20, shareList=0x0, allowDirect=1, contextID=0) at glxcmds.c:184 #10 0x40b53b19 in glXCreateContext (dpy=0x8381a50, vis=0x838ce20, shareList=0x0, allowDirect=1) at glxcmds.c:221 #11 0x4004cab9 in X11_GL_CreateContext () from /usr/lib/libSDL-1.2.so.0 #12 0x4005086d in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 #13 0x40050b9a in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 #14 0x4004690d in SDL_SetVideoMode () from /usr/lib/libSDL-1.2.so.0 Any ideas what might be causing this? Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][patch] radeonAllocDmaRegion calledwith bytes dma buffer size
I grepped for this and didn't find it, but in Mesa there is Const.MaxArrayLockSize which defaults to 3000 (wasn't that the count in the last backtrace?). There's nowhere in the radeon or r200 driver that refer to MaxArrayLockSize. -Leif On Wed, 5 Feb 2003, Keith Whitwell wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld ÿomething 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffersize
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). On Wed, 5 Feb 2003, Keith Whitwell wrote: Felix Kühling wrote: On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Found it: radeon_context.c around line 375: /* ctx-Const.MaxArrayLockSize = */ /*MIN2( ctx-Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Yes it is, because we went back to using vertexes instead of individual arrays, but forgot to reset this max value. I've committed the fix. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld ÿomething 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffersize
On Thu, 6 Feb 2003, Felix Kühling wrote: On Wed, 5 Feb 2003 20:17:57 -0500 (EST) Leif Delgass [EMAIL PROTECTED] wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). I see lots of vertex data corruption with TCL disabled in torcs and in quakeforge. With TCL enabled there is some strange corruption in quakeforge when the console is active. Actually, disabling TCL does cause some vertex corruption right at the start of the intro. Also I tried disabling texturing (rmode 7) and the vertex corruption in-game is still there, so it doesn't seem to be related to cube mapping. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffersize
On Wed, 5 Feb 2003, Keith Whitwell wrote: Leif Delgass wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). Hmm. Do you have an r200? I wonder whats up there... Nope. See my other reply (to Felix) -- there are still problems with TCL disabled and in game maps even with TCL. I was wondering if it was related to use of more than 2 texcoords, but I still had the problem with texturing disabled in ut2k3. I'm starting to look at what we need to do to handle glTexCoord3/4. The tricky thing is that the templates (e.g. radeon_maos_verts.c) seem to assume either 2 coords, or 4 coords (with r unused). We need to be able to choose either the third or fourth texcoord to put in the card's q slot, depending on whether the target is a 3D/cubemap texture or a 2D texture. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] texmem-0-0-1 branch
Attached is the patch with the modifications you suggested.
--Leif
On Mon, 3 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
It this looks OK, I will apply it to the branch.
I've poked around with the patch, and it looks good. There are only two
things that I would change. There should probably be a comment in
texmem.h that explains the double-duty that tObj does. I think the
meaning of t-tObj == NULL is important to document.
I would also probably change printLocalLRU and printGlobalLRU to take a
pointer to __FUNCTION__ and log that in their printfs. I remember
making that change to the version in the r100 driver when I was first
mucking with the texmem stuff. That proved very useful when I was
trying to figure out how it all worked. :)
Nice work!
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
Index: lib/GL/mesa/src/drv/common/texmem.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/common/Attic/texmem.c,v
retrieving revision 1.1.2.8
diff -u -r1.1.2.8 texmem.c
--- lib/GL/mesa/src/drv/common/texmem.c 27 Jan 2003 23:43:31 - 1.1.2.8
+++ lib/GL/mesa/src/drv/common/texmem.c 4 Feb 2003 16:46:53 -
@@ -119,12 +119,10 @@
static void resetGlobalLRU( driTexHeap * heap )
{
- driTexRegion * list = heap-global_regions;
+ drmTextureRegionPtr list = heap-global_regions;
unsigned sz = 1U heap-logGranularity;
unsigned i;
- heap-local_age = ++heap-global_age[0];
-
for (i = 0 ; (i+1) * sz = heap-size ; i++) {
list[i].prev = i-1;
list[i].next = i+1;
@@ -140,7 +138,76 @@
heap-global_age[0] = 0;
}
+/**
+ * Print out debugging information about the local texture LRU.
+ *
+ * \param heap Texture heap to be printed
+ */
+static void printLocalLRU( driTexHeap * heap, const char *callername )
+{
+ driTextureObject *t;
+ unsigned sz = 1U heap-logGranularity;
+ fprintf( stderr, %s in %s:\nLocal LRU, heap %d:\n,
+ __FUNCTION__, callername, heap-heapId );
+
+ foreach ( t, heap-texture_objects ) {
+ if (!t-memBlock)
+continue;
+ if (!t-tObj) {
+fprintf( stderr, Placeholder (%p) %d at 0x%x sz 0x%x\n,
+ t,
+ t-memBlock-ofs / sz,
+ t-memBlock-ofs,
+ t-memBlock-size );
+ } else {
+fprintf( stderr, Texture (%p) at 0x%x sz 0x%x\n,
+ t,
+ t-memBlock-ofs,
+ t-memBlock-size );
+ }
+ }
+ foreach ( t, heap-swapped_objects ) {
+ if (!t-tObj) {
+fprintf( stderr, Swapped Placeholder (%p)\n, t );
+ } else {
+fprintf( stderr, Swapped Texture (%p)\n, t );
+ }
+ }
+
+ fprintf( stderr, \n );
+}
+
+/**
+ * Print out debugging information about the global texture LRU.
+ *
+ * \param heap Texture heap to be printed
+ */
+static void printGlobalLRU( driTexHeap * heap, const char *callername )
+{
+ drmTextureRegionPtr list = heap-global_regions;
+ int i, j;
+
+ fprintf( stderr, %s in %s:\nGlobal LRU, heap %d list %p:\n,
+ __FUNCTION__, callername, heap-heapId, list );
+
+ for ( i = 0, j = heap-nrRegions ; i heap-nrRegions ; i++ ) {
+ fprintf( stderr, list[%d] age %d next %d prev %d in_use %d\n,
+ j, list[j].age, list[j].next, list[j].prev, list[j].in_use );
+ j = list[j].next;
+ if ( j == heap-nrRegions ) break;
+ }
+
+ if ( j != heap-nrRegions ) {
+ fprintf( stderr, Loop detected in global LRU\n );
+ for ( i = 0 ; i heap-nrRegions ; i++ ) {
+fprintf( stderr, list[%d] age %d next %d prev %d in_use %d\n,
+ i, list[i].age, list[i].next, list[i].prev, list[i].in_use );
+ }
+ }
+
+ fprintf( stderr, \n );
+}
/**
@@ -152,7 +219,7 @@
void driUpdateTextureLRU( driTextureObject * t )
{
driTexHeap * heap;
-driTexRegion * list;
+drmTextureRegionPtr list;
unsigned shift;
unsigned start;
unsigned end;
@@ -194,6 +261,12 @@
list[(unsigned)list[heap-nrRegions].next].prev = i;
list[heap-nrRegions].next = i;
}
+
+ if ( 0 ) {
+ printGlobalLRU( heap, __FUNCTION__ );
+ printLocalLRU( heap, __FUNCTION__ );
+ }
+
}
}
@@ -326,7 +399,13 @@
}
else
{
- driDestroyTextureObject( t );
+ if ( in_use
+offset == t-memBlock-ofs size == t-memBlock
Re: [Dri-devel] Radeon PCI Fix
On 4 Feb 2003, Michel Dänzer wrote: On Die, 2003-02-04 at 19:36, Keith Whitwell wrote: Michel Dänzer wrote: On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? The r128 probably still has the mb() in place at least. Yeah, maybe that avoids the worst problems, but it definitely wasn't enough for Chris. At least with r128 PCI, I have seen lockups happen after a period of days. When that happens, I see a sort of greenish bar of corrupted framebuffer at the top of the screen. Usually killing the server with Ctl-Alt-Backspace works and I can restart X without a problem. I've also seen that with same behavior with AGP Radeon 7500 from time to time. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Context teardown
I investigated why radeonDestroyContext wasn't being called for many of the Mesa demos. It turns out that only a few of the demos actually destroy the window and/or context before exit()-ing on a key press event. So if a glut app doesn't call glutDestroyWindow() or a glx app doesn't call glXDestroyContext and XDestroyWindow/XCloseDisplay then the Mesa client driver's DestroyContext/DestroyScreen never get called. This is also the case if the app is killed by a signal. So I guess we can't assume that these functions will be called, meaning that trying to clean up state in the SAREA (e.g. global texture regions) or flushing remaining buffers from those functions can't necessarily be relied on. Also, it appears that the DRM lock is _not_ held on entering the driver's DestroyContext. I don't think this is really a problem for the current drivers, but some of my assumptions were wrong so I thought I'd point this out in case anyone else was operating under the same assumptions. ;) -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
It was with the texobj Mesa demo, which appears to call glDeleteTextures and then glutDestroyWindow on ESC. I haven't looked at the implementation of glutDestroyWindow yet. On Tue, 4 Feb 2003, Keith Whitwell wrote: Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
On Tue, 4 Feb 2003, Keith Whitwell wrote: Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith glutDestroyWindow does indeed call XDestroyWindow before glXDestroyContext. I noticed that glxgears does it the other way around, and doesn't produce the X error. As a workaround, I tried adding this to radeonGetLock and I didn't get any errors: if ( dPriv-refcount 0 ) DRI_VALIDATE_DRAWABLE_INFO( sPriv, dPriv ); Maybe we could just return at that point if refcount 1, rather than going on to deal with cliprects and texture aging. Is that needed before the command buffer gets flushed? Do you think this could be a valid fix? I'm not sure exactly what refcount is counting, but from my quick test with glxgears and texobj it appears to be 1 when the window still exists and zero when it doesn't. However, I don't know if we can rely on this being up to date. Intersting also is that glut doesn't seem to call XCloseDisplay, as radeonDestroyScreen doesn't get called. glxgears calls XCloseDisplay and that seems to call radeonDestroyScreen (it doesn't happen in XDestroyWindow). -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Wed, 5 Feb 2003, Arkadi Shishlov wrote: On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. Yes, I think that's right. As an example, there's a texture in the first UT map (can't remember the name offhand) that uses an RGBA vine texture with MODULATE. It looks it's applied to an opaque quad, since the transparent part of the texture shows up as black. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 / Rage128 texture compression update
On 2 Feb 2003, Sergey V. Oudaltsov wrote: According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. Sorry for my ignorance, are these compression methods supported in any way by DRI now? Which apps would benefit of them? No they aren't supported in DRI. For existing apps, they would probably only be useful for apps supplying uncompressed textures and requesting generic compression through ARB_texture_compression. The textures would have to be compressed in software and then passed to the card to de-compress as it applies the textures. There is no GL extension (vendor-specific or otherwise) that I know of for these formats, so it would require a new extension spec. and a software implementation of compression/de-compression as well as the support for hardware de-compression (that's the easy part). Since there's no existing extension, there wouldn't be any existing apps supplying pre-compressed textures to the GL in this format, and afaik, very few existing apps would ask for generic compressed formats either. This limits the utility of implementing it, as VQ compression is much more time consuming than S3TC/DXTC compression, as I understand it. It's better for offline compression and real-time de-compression (de-compression could be faster than with S3TC). So it would require detailed specs on the compression format as implemented in the hardware (e.g. block and codebook sizes) to write the spec. and software support, or some trial and error reverse engineering. Quite frankly, it seems like it's probably more trouble than it's worth. Does anyone know if these formats were ever supported in ATI's drivers? I'm assuming it would have to have been in the DX drivers, since I can't find any GL extension supporting them. But I can't find any reference to DX supporting VQ except for the WinCE DirectX SDK for the Sega Dreamcast. I think Microsoft made DX 5 and 6.1 sdks for the dreamcast, and DXTC/S3TC was introduced in the PC version of DX6. According to ATI's site, later Rage 128 chips (Rage Fury Pro, Rage Mobility) support DX6 texture compression, which I assume means S3TC, but I don't see any relevant register defines in the headers and I don't have specs for Rage 128. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] texmem-0-0-1 branch
Attached is a patch to the texmem branch with the changes we've been
discussing. I'd still like to take a closer look at the global heap, but
I've included the code to force initializing the global heap on the first
lock contention for now. I've changed the drm/ddx/texmem code to use the
drmTextureRegion/drm_tex_region_t struct for the SAREA and heap
structures, but only for the drivers converted to the texmem interface. I
also added a test to driAllocateTexture that deletes a placeholder (using
t-tObj == NULL to detect a placeholder) instead of swapping it out. An
explicit flag for detecting a placeholder might make the code more clear,
but using t-tObj should work too. Since placeholders should never be on
the swapped list now, I left in the assert for the swapped list being
empty in the drivers' DestroyContext, though I added code to delete
anything on the swapped list in driDestroyTextureHeap just in case that
assertion would need to be removed for some reason.
I've also included the optimization in driTexturesGone to keep an existing
placeholder if the global region is in use and matches the size and offset
of the existing placeholder.
It this looks OK, I will apply it to the branch.
I need to do some more testing on the Rage 128 driver, but so far things
seem to be working except for the problem in the fire Mesa demo, which is
still there. It kind of looks like a texture coordinate problem, but I'm
not sure yet.
--
Leif Delgass
http://www.retinalburn.net
Index: lib/GL/mesa/src/drv/common/texmem.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/common/Attic/texmem.c,v
retrieving revision 1.1.2.8
diff -u -r1.1.2.8 texmem.c
--- lib/GL/mesa/src/drv/common/texmem.c 27 Jan 2003 23:43:31 - 1.1.2.8
+++ lib/GL/mesa/src/drv/common/texmem.c 1 Feb 2003 21:39:55 -
@@ -119,12 +119,10 @@
static void resetGlobalLRU( driTexHeap * heap )
{
- driTexRegion * list = heap-global_regions;
+ drmTextureRegionPtr list = heap-global_regions;
unsigned sz = 1U heap-logGranularity;
unsigned i;
- heap-local_age = ++heap-global_age[0];
-
for (i = 0 ; (i+1) * sz = heap-size ; i++) {
list[i].prev = i-1;
list[i].next = i+1;
@@ -140,7 +138,74 @@
heap-global_age[0] = 0;
}
+/**
+ * Print out debugging information about the local texture LRU.
+ *
+ * \param heap Texture heap to be printed
+ */
+static void printLocalLRU( driTexHeap * heap )
+{
+ driTextureObject *t;
+ unsigned sz = 1U heap-logGranularity;
+ fprintf( stderr, Local LRU, heap %d:\n, heap-heapId );
+
+ foreach ( t, heap-texture_objects ) {
+ if (!t-memBlock)
+continue;
+ if (!t-tObj) {
+fprintf( stderr, Placeholder (%p) %d at 0x%x sz 0x%x\n,
+ t,
+ t-memBlock-ofs / sz,
+ t-memBlock-ofs,
+ t-memBlock-size );
+ } else {
+fprintf( stderr, Texture (%p) at 0x%x sz 0x%x\n,
+ t,
+ t-memBlock-ofs,
+ t-memBlock-size );
+ }
+ }
+ foreach ( t, heap-swapped_objects ) {
+ if (!t-tObj) {
+fprintf( stderr, Swapped Placeholder (%p)\n, t );
+ } else {
+fprintf( stderr, Swapped Texture (%p)\n, t );
+ }
+ }
+
+ fprintf( stderr, \n );
+}
+
+/**
+ * Print out debugging information about the global texture LRU.
+ *
+ * \param heap Texture heap to be printed
+ */
+static void printGlobalLRU( driTexHeap * heap )
+{
+ drmTextureRegionPtr list = heap-global_regions;
+ int i, j;
+
+ fprintf( stderr, Global LRU, heap %d list %p:\n, heap-heapId, list );
+
+ for ( i = 0, j = heap-nrRegions ; i heap-nrRegions ; i++ ) {
+ fprintf( stderr, list[%d] age %d next %d prev %d in_use %d\n,
+ j, list[j].age, list[j].next, list[j].prev, list[j].in_use );
+ j = list[j].next;
+ if ( j == heap-nrRegions ) break;
+ }
+
+ if ( j != heap-nrRegions ) {
+ fprintf( stderr, Loop detected in global LRU\n );
+ for ( i = 0 ; i heap-nrRegions ; i++ ) {
+fprintf( stderr, list[%d] age %d next %d prev %d in_use %d\n,
+ i, list[i].age, list[i].next, list[i].prev, list[i].in_use );
+ }
+ }
+
+ fprintf( stderr, \n );
+}
/**
@@ -152,7 +217,7 @@
void driUpdateTextureLRU( driTextureObject * t )
{
driTexHeap * heap;
-driTexRegion * list;
+drmTextureRegionPtr list;
unsigned shift;
unsigned start;
unsigned end;
@@ -194,6 +259,12 @@
list[(unsigned)list[heap-nrRegions].next].prev = i;
list[heap-nrRegions].next = i;
}
+
+ if ( 0 ) {
+ printGlobalLRU( heap );
+ printLocalLRU( heap );
+ }
+
}
}
@@ -326,7 +397,13 @@
}
else
[Dri-devel] texmem-0-0-1 branch
I've been looking at the texmem branch and have found a few problems. I
wanted to explain the problems I found and get some feedback before
commiting any changes or putting a patch together.
The first item is the cause of the texture corruption with multiple
contexts that I have seen with both Radeon and Rage 128. In the
DRI_AGE_TEXTURES macro in texmem.h, the age test is reversed:
#define DRI_AGE_TEXTURES( heap )\
do { \
if ( ((heap) != NULL)\
((heap)-local_age (heap)-global_age[0]) )\
driAgeTextures( heap ); \
} while( 0 )
Here global_age[0] would be _larger_ than local_age after a context's
textures have been kicked out (global_age is incremented at each upload).
Changing the test to != or fixes the problem. However, there is another
problem here. In the old driver-specific code, the local age was a signed
int, which was initialized to -1, and the global age was/is initialized to
0 (by memset-ing the SAREA). This caused the first context in a new
server generation to initialize the global LRU since the local and global
ages differed. With both now being initially 0, the global LRU is not
initialized before it is updated when the first texture upload happens.
One workaround would be to use local != global in the age test and
initialize the local age to anything 0 if the global age is 0 when the
context is created.
Also, I think it would cause less confusion if the drivers' SAREAs used
unsigned ints where the pointers in the heap/region structs in texmem.h
do. It should be safe to assume sizeof(int) == sizeof(unsigned int),
right? Actually, even better would be if all the drivers used the
drmTextureRegion struct (mga does) defined in xf86drm.h, since the code to
manipulate the struct is now being made common to all drivers. The
difference between that struct and the current driver private versions is
that drmTextureRegion uses an explicit padding byte between the first
three bytes (unsigned chars) and the age (unsigned int). Would there be
compatibility problems in moving from a struct without the explicit
padding to one with it? :
typedef struct _drmTextureRegion {
unsigned char next;
unsigned char prev;
unsigned char in_use;
unsigned char padding; /* Explicitly pad this out */
unsigned int age;
} drmTextureRegion, *drmTextureRegionPtr;
vs.
typedef struct {
unsigned char next, prev; /* indices to form a circular LRU */
unsigned char in_use; /* owned by a client, or free? */
int age;/* tracked by clients to update local LRU's */
} radeon_tex_region_t;
There are also a few failing assertions related to placeholder texture
objects. In driTexturesGone, we need to set t-heap = heap or else the
assertion that t-heap != NULL fails in driDestroyTextureObject when
destroying a placeholder. The other assertions that I don't think are
valid are in the drivers' DestroyContext, where it's assumed that the
swapped list and texture object lists are empty. Even if Mesa calls the
driver's DeleteTexture for all the real texture objects at context
teardown (does this happen?), there may still be placeholder objects on
the swapped or texture_objects lists. I think it is safer to have
driDestroyTextureHeap iterate both lists and destroy any remaining texture
objects and remove the assertions.
The last problem I found is the drivers' call to driCreateTextureHeap in
CreateContext. Passing pointers to the texList and texAge arrays without
an index results in texList[0] and texAge[0] being passed for both texture
heaps (if the driver supports the AGP heap), so those should be indexed as
texList[i] and texAge[i] where i is the heapId.
Also, I think there's a small optimization we could make, but I need to
make sure this is valid. I observed two contexts (texobj and tunnel
demos) repeatedly deleting and creating the same placeholder in
driTexturesGone when switching contexts. I think it would be possible to
keep an existing placeholder if the offset and size of the placeholder in
the texture_objects list matches the global region which has been updated.
For debugging the LRUs, I added the printLocal/GlobalLRU functions from
the old driver code to texmem.c in my tree. I think it's useful to have
these at least as static functions to use for debugging the common texmem
code.
At any rate, I can put a patch together for review, but I wanted to see if
there's anything I'm missing here.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists
Re: [Dri-devel] Streaming video through glTexSubImage2D
On Fri, 31 Jan 2003, Arkadi Shishlov wrote: On Fri, Jan 31, 2003 at 10:26:13AM -0800, Ian Romanick wrote: There are two typical ways to go about imporving texture upload performance in OpenGL applications. One is through the use of OpenGL extensions. There are several extensions available (or available any You are talking about extensions here, but my P3 600MHz Radeon8500 box with ATI binary drivers is able to push normal frame rates in MPlayer with 720x480 movies with OpenGL output driver at 80% CPU load. 30% with XVideo. It use regular glTexSubImage2D, so it is either R100 or DRI beign slow in this case (if CPU is powerful enough). I don't know much about extensions you mentioned, but how much you'll save with MPlayer? One memcpy() (assuming it doesn't wait for texture upload)? Actually, iirc, all the drivers actually implement glTexSubImage2D the same way as glTexImage2D. They always upload the entire texture image -- there was a comment I remeber seeing about the subimage index calculations being wrong. Fixing this to only upload the subimage would help the performance of glTexSubImage2D. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Streaming video through glTexSubImage2D
On Fri, 31 Jan 2003, Arkadi Shishlov wrote: On Fri, Jan 31, 2003 at 04:33:36PM -0500, Leif Delgass wrote: Actually, iirc, all the drivers actually implement glTexSubImage2D the same way as glTexImage2D. They always upload the entire texture image -- there was a comment I remeber seeing about the subimage index calculations being wrong. Fixing this to only upload the subimage would help the performance of glTexSubImage2D. I think it doesn't make any difference with MPLayer, it replace whole texture for every frame (there is draw_slice() in libvo/vo_gl.c, but I doubt it is used too much; possible source of low performance with DRI?). It always upload in RGB format, so probably much of the CPU is spent in yuv2rgb(). You're probably right, in most apps it likely wouldn't have a large impact. The extensions that Ian described are going to have more of an effect. How glTexSubImage2D can upload full texture? The original source is gone, does it keep a copy internally? Yes, the Mesa drivers currently keep a copy of all textures in system memory, but this is one of the things that could change with a new AGP/texture management scheme. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texmem-0-0-1 branch
On Fri, 31 Jan 2003, Ian Romanick wrote: Leif Delgass wrote: There are also a few failing assertions related to placeholder texture objects. In driTexturesGone, we need to set t-heap = heap or else the assertion that t-heap != NULL fails in driDestroyTextureObject when destroying a placeholder. I see the problem you're talking about here. You are correct. I misunderstood where you meant to set t-heap to heap. I now see that you meant to set it after the CALLOC in the 'if ( in_use )' block. Duh. :) Right. I should have been more specific there (the actual patch would have been more clear ;) ). Do you see what I mean now about the assertions on tearing down the context? A placeholder _does_ have a memBlock, which matches the corresponding global region marked as in use. It's in the same block you refer to here that it's added to the texture_objects list. Also, a placeholder can be moved to the swapped_objects list in driAllocateTexture (another place an assertion can fail in driSwapOutTextureObject if the placeholder's t-heap == NULL). The driver's DeleteTexture callbacks on teardown won't remove any placeholders from these lists, just the real textures that have corresponding gl_texture_object structs (t-tObj). -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 / Rage128 texture compression update
According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. On Fri, 31 Jan 2003, Ian Romanick wrote: While I was searching around the net for papers on texture memory management, I came across some references to Talisman and DirectX 6.0 texture compression. It seems that the compression algorithm used is called TREC, which is short for Texture and Rendering Compression. http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm Apparently, it is some sort of DCT based compression scheme. That would explain why ATI is the only company to ever implement it in hardware. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Ian Romanick wrote: The thing that makes XML worse is that it gives people an extra degree of freedom. This amounts to giving people more rope with which to shoot themselves in the foot. LOL. /me holds rope /me looks at foot /me scratches head -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Wed, 29 Jan 2003, Arkadi Shishlov wrote: Hi. I'm working on QuakeForge engine, and some things related to transparency (player damage blood) and 'dynamic lighting' (grenade explosion) are very slow. Quake3 runs faster in mean time. Quake3 has some hacks built in to work around the mach64's limitations. I think it looks for Rage Pro in the Renderer string to enable them. I want to investigate problem further on Quake side, but I want to be sure I understood mach64 limitation correctly from what I've read at http://www.retinalburn.net/linux/dri_status.html - glEnable(GL_FOG) and glEnable(GL_BLEND) cannot be enabled at the same time. Correct. Enabling fog when blending is enabled will have no effect (there's no software fallback). Enabling blending when fog is enabled will disable fog. So fog should not cause any slowdowns as a result of falling back to software. - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not done as a fallback since it's very common. Hardware accelerated: environment texture base format GL_DECAL any valid format - GL_RGB, GL_RGBA GL_REPLACEGL_LUMINANCE, GL_RGB, GL_RGBA GL_MODULATE GL_LUMINANCE, GL_RGB, GL_RGBA(not fully compliant) Software fallbacks: -- environment texture base format GL_BLEND any GL_REPLACEGL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY GL_MODULATE GL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY And of course anything more recent than these core environments isn't supported, e.g ADD, COMBINE, etc. cvs co -r mach64-0-0-5-branch xc/xc/lib/GL/mesa/src/drv/mach64 are the right files to investigate for additional limitations? Yes. Look at mach64UpdateTextureEnv in mach64_texstate.c for the above and mach64_state.c for fog, blending and other state. BTW, when particular operation is implemented in software but require some on-screen content, driver copy already rendered chunk from framebuffer, pass it to Mesa, then copy back? To be honest, I don't know the gory details of the Mesa software rasterizer yet, but any primitives needing a texture application that can't be done in hardware would be completely software rendered and written to the framebuffer, I think. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC logs
Well, I did a thorough search of my xchat logs and put all the days I had that were missing on http://dri.sf.net/IRC-logs/ There are still a couple days missing and there are few days that are incomplete, so if anyone has a more complete log go ahead and replace mine, they are all group writeable. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
On Wed, 22 Jan 2003, Daniel Vogel wrote: ftp://ftp.retinalburn.net/pub/ut2k3/Shot0.bmp ftp://ftp.retinalburn.net/pub/ut2k3/Shot1.bmp How does rmode 7 (untextured, lighting only) look like? rmode 5 == regular rmode 6 == just textures ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_1.bmp ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_2.bmp rmode 7 == just lighting ftp://ftp.retinalburn.net/pub/ut2k3/rmode7_1.bmp ftp://ftp.retinalburn.net/pub/ut2k3/rmode6_2.bmp As you can see, both modes still seem to have vertex problems. Could it be related to the lack of NV_vertex_array_range or ATI_vertex_array_object? I assume there's a fallback path since I don't see any GL errors related to those extensions. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
On Thu, 2 Jan 2003, Daniel Vogel wrote: A bit unrelated: Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) (if anyone wants the full log let me know) On OS X 10.2.3 this is caused by glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR ); This is indeed one of the sources of the GL_INVALID_ENUMs; however, it appears to be a bug in Mesa. There seems to be a missing break after texstate.c:423 : --- texstate.c Tue Jan 21 17:10:15 2003 +++ texstate.fixed.cTue Jan 21 17:11:19 2003 @@ -421,6 +421,7 @@ return; FLUSH_VERTICES(ctx, _NEW_TEXTURE); texUnit-CombineOperandRGB[2] = operand; + break; default: TE_ERROR(GL_INVALID_ENUM, glTexEnv(param=%s), operand); return; Brian, does that look right to you? The other INVALID_ENUMS appear to be caused by an assumption that GL_ARB_texture_cube_map is supported, which it isn't in the current DRI Radeon driver. There appear to be calls to glDisable and glTexParameter using GL_TEXTURE_CUBE_MAP_ARB even thought the extension isn't supported. At least that's what I found with MESA_DEBUG=1 just from the intro/menu screens. I tried exporting GL_ARB_texture_cube_map from the Radeon driver and along with the above patch, it makes all the OpenGL errors go away. The lack of combine3/4 seems to be handled in the version I'm using (from the UT2003.log): Init: OpenGL: WARNING: no support for combine3/4 extensions - not all blend modes supported However, I still see the same corruption reported before. This could be in part because of the missing cube map support, but it looks to me like something is causing vertex data corruption. Just a guess. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
On Tue, 21 Jan 2003, Brian Paul wrote:
Ian Romanick wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
A bit unrelated:
Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock)
(if anyone wants the full log let me know)
On OS X 10.2.3 this is caused by
glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
appears to be a bug in Mesa. There seems to be a missing break after
texstate.c:423 :
--- texstate.c Tue Jan 21 17:10:15 2003
+++ texstate.fixed.cTue Jan 21 17:11:19 2003
@@ -421,6 +421,7 @@
return;
FLUSH_VERTICES(ctx, _NEW_TEXTURE);
texUnit-CombineOperandRGB[2] = operand;
+ break;
default:
TE_ERROR(GL_INVALID_ENUM, glTexEnv(param=%s), operand);
return;
Brian, does that look right to you?
I had just come across this today also. I think a better sollution
would be to fold the GL_OPERAND2_{RGB,ALPHA} cases in with the
GL_OPERAND[01]_{RGB,ALPHA} cases. If we care about filtering out the
cases that are not valid for EXT_texture_env_combine, we should do in
the inner switch in those cases.
Feel free to whip up a patch for that. :)
-Brian
In the meantime, I've commited the one-line fix to DRI HEAD, texmem-0-0-1
and mesa-4-0-4-branch, since the bug is in 4.x also. Should I submit it
to [EMAIL PROTECTED] too or is there going to be another merge from
texmem-0-0-1 before 4.3.0?
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa glTexEnv bug (Was: S3TC and ut2k)
On Tue, 21 Jan 2003, Leif Delgass wrote:
On Tue, 21 Jan 2003, Brian Paul wrote:
Ian Romanick wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
A bit unrelated:
Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock)
(if anyone wants the full log let me know)
On OS X 10.2.3 this is caused by
glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
appears to be a bug in Mesa. There seems to be a missing break after
texstate.c:423 :
--- texstate.c Tue Jan 21 17:10:15 2003
+++ texstate.fixed.cTue Jan 21 17:11:19 2003
@@ -421,6 +421,7 @@
return;
FLUSH_VERTICES(ctx, _NEW_TEXTURE);
texUnit-CombineOperandRGB[2] = operand;
+ break;
default:
TE_ERROR(GL_INVALID_ENUM, glTexEnv(param=%s), operand);
return;
Brian, does that look right to you?
I had just come across this today also. I think a better sollution
would be to fold the GL_OPERAND2_{RGB,ALPHA} cases in with the
GL_OPERAND[01]_{RGB,ALPHA} cases. If we care about filtering out the
cases that are not valid for EXT_texture_env_combine, we should do in
the inner switch in those cases.
Feel free to whip up a patch for that. :)
-Brian
In the meantime, I've commited the one-line fix to DRI HEAD, texmem-0-0-1
and mesa-4-0-4-branch, since the bug is in 4.x also. Should I submit it
to [EMAIL PROTECTED] too or is there going to be another merge from
texmem-0-0-1 before 4.3.0?
Arggh! Merge from mesa-4-0-4-branch that is. Too many branches. ;)
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Mesa glTexEnv bug (Was: S3TC andut2k)
On Tue, 21 Jan 2003, Ian Romanick wrote:
Brian Paul wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
appears to be a bug in Mesa. There seems to be a missing break after
texstate.c:423 :
--- texstate.c Tue Jan 21 17:10:15 2003
+++ texstate.fixed.cTue Jan 21 17:11:19 2003
@@ -421,6 +421,7 @@
return;
FLUSH_VERTICES(ctx, _NEW_TEXTURE);
texUnit-CombineOperandRGB[2] = operand;
+ break;
default:
TE_ERROR(GL_INVALID_ENUM, glTexEnv(param=%s), operand);
return;
Brian, does that look right to you?
Yes. There should be a break there. I'm surprised this wasn't found
when running the texcombine conformance test or Glean test. Hmmm.
Glean didn't catch it because it only ever sets GL_OPERAND2_{RGB,ALPHA}
to the default state. This ends up taking the early-out path in
texstate.c. Just dumb luck.
[snip]
However, I still see the same corruption reported before. This could
be in part because of the missing cube map support, but it looks to me
like something is causing vertex data corruption. Just a guess.
Cube mapping works in the R200 driver with one caveat: glTexCoord3*()
commands don't work. Normally, a texgen mode like GL_REFLECT is used
with cube maps so the texcoords are generated in hardware. The h/w
vertex setup code needs to be updated to handle 3-component texture coords.
Not sure if this is the problem you're seeing though. The
Mesa/demos/cubemap program shows the problem.
How exactly does this problem look? This might be exactly the problem
that I'm geting on r100. Could you put a screenshot up somewhere? If
it is the same thing on r100, I'll go ahead and commit my cube map
changes, and we'll have to hope someone figures out how to setup the
hardware for the R coord. :/
I put up examples from UT2003. This is with the texmem branch on R100
with the texture combine one-liner, but without cube map exported
(althought the texmem branch seems to have at least the beginning of cube
map support, right?):
ftp://ftp.retinalburn.net/pub/ut2k3/Shot0.bmp
ftp://ftp.retinalburn.net/pub/ut2k3/Shot1.bmp
I don't think this is The way it's meant to be played(TM) :) At any
rate, I think you can see from the second shot what I mean about the
vertices looking wrong.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC and ut2k
On Thu, 2 Jan 2003, Ian Romanick wrote: Daniel Vogel wrote: i tried it again with the last couple of updates and it does load and run i can configure it but it did freeze apon loading a level i also noticed ut2k3's log full of Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) (if anyone wants the full log let me know) I think it is related to the lack of either ATI_texture_env_combine3 or NV_texture_env_combine4. ATI_texture_env_combine3 should be an easy extension to add to DRI though I'll add an ugly fallback for the next patch. I doubt it explains any lockups. Adding ATIX_texture_env_combine3 has been (somewhere near the bottom) of my TODO list for quite some time now. I think this moves it up at least a couple positions. :) The only problem is that this extension is an X extension, and isn't listed in the extension registry. The net result is that the enums for it aren't in the standard glext.h file. I know that Brian hasn't wanted to hand-edit glext.h in the past, but perhaps an exception could be made? Either that or perhaps would could collectively prod ATI into posting the extension to the registry. :) I was looking at this today also and it looks like ATI promoted it to ATI_ from ATIX_ (spec. is dated 8/1/02): http://www.ati.com/developer/sdk/RadeonSDK/Html/Info/ATI_texture_env_combine3.txt But as you say, it's still not in the registry or glext.h yet. BTW, the same goes for S3_s3tc if we ever get permission to implement texture compression. Some older apps look for that instead of EXT_texture_compression_s3tc, e.g. Quake 3. -- Leif Delgass http://www.retinalburn.net --- 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 fifo problem...
On Sun, 15 Dec 2002 [EMAIL PROTECTED] wrote: [...] 00:01.0 PCI bridge: ATI Technologies Inc U1/A3 AGP Bridge [IGP 320M] (rev 01) (prog-if 00 [Normal decode]) Hmm, seems to be some kind of integrated chipset? Maybe you can get agpgart working with agp_try_unsupported. I have seen an email on the debian-laptops list between (I suspect) some kernel developers referring to the ATI IGP 320 hardware stating that it was currently not totally supported. (I think they said something like ATI have not released the specs. yet, so the support has to be implemented the hard way.) My machine is an HP Pavillion ze4125 notebook. Thus is it possible tha the chipset is an integrated one. The laptop manual implies it is an integrated chipset (for some definition of integrated, which it does not specify...). When I use agp_try_unsupported=1 I get the same message in kern.log: Dec 15 12:07:17 marvin kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Dec 15 12:07:17 marvin kernel: agpgart: Maximum main memory to use for agp memory: 408M Dec 15 12:07:17 marvin kernel: agpgart: unsupported bridge Dec 15 12:07:17 marvin kernel: agpgart: no supported devices found. As you can see, there's no agpgart support for ATI's IGP chipsets yet, which means right now you'd probably only be able to get 2D accel (with MMIO) at best. b) The ATI Mobility U1 is sufficiently different from the other ATI Mobility chips to cause a kernel panic on auto-detect. Not sure how autodetection by 'the kernel' (do you mean the DRM?) would cause a panic, you'd have to provide more information to tell. Again, my mistake for being unclear. When the option accel is used, and I start XFree (using startx), I see the screen switch to tty7, but stay blank. After a few seconds a single short beep is emitted. Then the caps-lock leds flashes on and off. The system stops responding to keyboard input and does not respond to ssh requests, not orderly shutdown (but ctrl-alt-backspace or ctrl-alt-delete or a brief press on the power button). Hence the kernel is no longer responding. When I reboot and look in the XFree.log file, it ends at the point when the list of the supported ATI chipsets is printed and the entries where the driver is attempting to load the ATI driver. Thus I presume that at this point the ATI software is loaded which has to identify the chipset and this detection mechanism causes the freeze. I have also tried a chipid of 0x4966 (Radeon 9000) in the XF86Config-4 file with the Option accel and this suffers the same timeout on the FIFO error. (I read a report that the Radeon Mobility U1 was supposed to be software-compatible with this chip.) All the initial reviews I saw on IGP 320M said it's a Radeon VE/7000 core (no TCL), but mention a possible new revision coming at the end of this year or beginning of 2003. Also the Radeon IGP pages on ATI's site just call it a RADEON core and don't mention Charisma EngineTM, which is their name for TCL (see the Radeon 7500 page), although the features page refers to a broad line of chips that are pin-compatible: http://mirror.ati.com/technology/hardware/radeonigp/features.html http://mirror.ati.com/technology/hardware/radeonigp/rigp320m.html You might want to try a Radeon 7000/VE or Radeon Mobility (M6?) ChipID. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] vblank and i810
FYI, I noticed this recent patch from Arjan van de Ven from lkml. It's
got page flipping and user-defined interrupts for i830 (for 2.4):
http://marc.theaimsgroup.com/?l=linux-kernelm=103969295019388w=2
Out of curiosity, I just downloaded the i810/i815 specs. At first glance
I don't see why you couldn't use bit 7 of the interrupt registers on
i810/i815 for VBLANK interrupts, rather than emitting a wait for vblank to
the ring, but maybe I'm missing something.
On Fri, 13 Dec 2002, Ian Romanick wrote:
On Fri, Dec 13, 2002 at 01:15:01PM -0800, Sottek, Matthew J wrote:
The i810's vblank interrupt does not go to the CPU's interrupt
controller IIRC. Therefore you have to poll for vblank by reading
the current scanline.
That's quite surprising to me.
Usually apps that are waiting on vblank can be better served by
solving the actual problem rather than trying to use a generic wait
For vblank solution.
i.e. If you want to blit to the FB and don't want to see tearing,
the i810 can pause the DMA stream until a vblank. So issue the wait
for vblank before your blit and there is no need for your app to
worry about it.
Or, if you want the overlay to flip synchronous with vblank... The
Hardware already does that for you.
So, how do you delay the flip-blit to the vblank but NOT delay other
rendering? I think that would also make it difficult to implement things
like {GLX,WGL}_SGI_swap_control or {GLX,WGL}_OML_sync_control.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] vblank and i810
Just a quick follow-up to this. It looks like Arjan's patch comes from XFree86 CVS, which got a bunch of i830 updates from Keith and David Dawes a few days ago (which explains the KW comments in Arjan's patch). I assume we'll get these into DRI with the next sync-up. Just another example of the multiple repositories causing confusion... ;) On Fri, 13 Dec 2002, Leif Delgass wrote: On Fri, 13 Dec 2002, Leif Delgass wrote: On Fri, 13 Dec 2002, Ian Romanick wrote: On Fri, Dec 13, 2002 at 05:43:51PM -0500, Leif Delgass wrote: FYI, I noticed this recent patch from Arjan van de Ven from lkml. It's got page flipping and user-defined interrupts for i830 (for 2.4): http://marc.theaimsgroup.com/?l=linux-kernelm=103969295019388w=2 Good catch. Out of curiosity, I just downloaded the i810/i815 specs. At first glance I don't see why you couldn't use bit 7 of the interrupt registers on i810/i815 for VBLANK interrupts, rather than emitting a wait for vblank to the ring, but maybe I'm missing something. That was my conclusion as well. It appears that Arjan's patch does just that for the i830. Actually, I think it just has support for user-defined interrupts for DMA using bit 2, but it could be extended to include vblank support, I think. The patch includes some updates to the generic vblank template code (probably taken from DRI CVS, but I didn't look too closely), but the i830 stuff seems to still be using the DRIVER_[PRE,POST]_INSTALL macros and only enables bit 2 (user-defined interrupt). Sorry... s/bit 2/bit 1/ -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] bugreport: http://people.debian.org/~daenzer/dri-mach64/
This probably won't help with kdm, but did you also install the xlibmesa* packages? I think those contain the mach64 Mesa driver (mach64_dri.so) among other things, that you'll need to use DRI. On Thu, 12 Dec 2002, Vladimir Wiedermann wrote: hi, I'm send this email to both adresses, because i don't know, if problem is in package or DRI .. I have Debian Unstable and ATI (rage pro) Mobility graphics card. I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page in subject, made .deb by make-kpkg and installed it. Problem is, that KDM don't want to run anymore. I see, that X server started, but then it restarted. (see attached files) I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and XFree86Server 4.2.1. Funny is, that when I put startx, it works well (except that I change to console before kde is fully loaded) so please help if you can.. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] [BUXFIX] Linux agpgart version check
This patch fixes two problems with the version requirement check for the
Linux agpgart module in kdrive and libdrm.a:
1. The current code has faulty logic which prevents an error from ocurring
if the major version number of agpgart is equal to that required, but the
minor version is less than that required.
2. The current code will raise an error if the agpgart major version
number is higher than that required. Dave Jones, the current agpgart
maintainer, submitted some agp changes to the 2.5 kernel tree and bumped
the version number of agpgart from 0.99 to 1.0. This broke compatiblity
with current XFree86 versions, despite the fact that the interface hasn't
changed, so he had to change the version number to 0.100. I asked Dave if
a patch to XFree86 could assume future backwards compatibility and he
said:
Given that any breakage would screw over the freebsd folks too,
I'm inclined to do whatever I can to maintain backwards compatability.
For now, I'm going to bump through 0.99 - 0.100 - 0.whatever
as that matches the existing code, so we don't need to break
existing X setups. Fixing this would be good for the future
however, so one day, we can go to 1.0.
So my patch will only produce an error if the agpgart version is earlier
than the one required, assuming backwards compatibility in future
versions. This will allow bumping the agpgart major version some time in
the future, and still allows the agpgart version requirement in XFree86 to
be bumped if new functionality is required from a future agpgart version
(which again is assumed to also retain the original interface).
I plan to commit this to the DRI cvs HEAD. Please apply this to XFree86
cvs so it can be included in XFree86 4.3.0. Thanks.
--
Leif Delgass
http://www.retinalburn.net
Index: xc/programs/Xserver/hw/kdrive/linux/agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/kdrive/linux/agp.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 agp.c
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, evey effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
fprintf(stderr,
Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c,v
retrieving revision 1.5
diff -u -r1.5 lnx_agp.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 11 Sep 2002 00:57:49
- 1.5
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 10 Dec 2002 20:51:03
+-
@@ -89,9 +89,16 @@
xf86ReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, evey effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
xf86DrvMsg(screenNum, X_ERROR,
GARTInit: Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Re: [Dri-devel] [PATCH] [BUGFIX] Linux agpgart version check
On Tue, 10 Dec 2002, Dave Jones wrote:
On Tue, Dec 10, 2002 at 04:21:03PM -0500, Leif Delgass wrote:
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, evey effort will be made to keep the
^
Silly typo. 8)
Dave
D'oh. Thanks...here it is again with the the subject line fixed too, just
in case it missed anyone's filter. ;)
--
Leif Delgass
http://www.retinalburn.net
Index: xc/programs/Xserver/hw/kdrive/linux/agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/kdrive/linux/agp.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 agp.c
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, every effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
fprintf(stderr,
Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c,v
retrieving revision 1.5
diff -u -r1.5 lnx_agp.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 11 Sep 2002 00:57:49
- 1.5
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 10 Dec 2002 20:51:03
+-
@@ -89,9 +89,16 @@
xf86ReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, every effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
xf86DrvMsg(screenNum, X_ERROR,
GARTInit: Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Re: [Dri-devel] DRM Makefile change for Mach64
Thanks, I've committed this. On Fri, 6 Dec 2002, Allen Barnett wrote: Hi, In looking at a problem I was having with the DRM, I noticed that in dripkg in the file ./drm/Makefile.linux, near the bottom there's a dependency line: $(MACHOBJS): $(MACH64HEADERS) which should be $(MACH64OBJS): $(MACH64HEADERS) so that the mach64.o module is recompiled if one of the DRM headers changes. Thanks, Allen --- 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 -- Leif Delgass http://www.retinalburn.net --- 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
