Re: [Dri-devel] AGP and radeon driver
On Mon, 2004-03-08 at 06:58, Jon Smirl wrote: I'm trying to merge some of the functions from the radeon DRM and FB device drivers into a single driver. I've been working on the code for a week trying to get AGP working but I can't seem to figure out what is wrong. In drm/radeon_cp.c, radeon_cp_init_ring_buffer() there is a test to see if the GPU will write the registers out to AGP space: BTW, we should move this to PCI space whenever possible, as many AGP bridges seem to be buggy in this area. Does the CP need to be running for this to work? I don't think so. Does PCI bus mastering need to be enabled? Probably; otherwise there's no way for the GPU to initiate a transfer, is there? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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] AGP and radeon driver
Hi Jon,
The problem could be in Radeon memory controller mapping, perhaps
XFree86 from DRI CVS changes it.
You see there is a memory controller on Radeon chip itself which merges
several different address spaces (video ram, AGP and PCI DMA) into one.
The default (when it boots) is such that video ram overlaps the beginning
of PCI DMA space, so you are not able to do DMA into lower 64 or 128 MB of
system RAM.
XFree86 in DRI CVS has the ability to move these address spaces
dynamically.
You might find useful the following piece of code:
int radeon_check_mc_settings(KM_STRUCT *kms)
{
u32 aperture, aperture_size;
u32 mc_fb_location;
u32 mc_agp_location;
u32 new_mc_fb_location;
u32 new_mc_agp_location;
aperture=pci_resource_start(kms-dev,0);
radeon_wait_for_idle(kms);
aperture_size=readl(kms-reg_aperture+RADEON_CONFIG_APER_SIZE);
mc_fb_location=readl(kms-reg_aperture+RADEON_MC_FB_LOCATION);
mc_agp_location=readl(kms-reg_aperture+RADEON_MC_AGP_LOCATION);
new_mc_fb_location=((aperture16)0x)|
((aperture+aperture_size-1)0x);
if((new_mc_fb_location!=mc_fb_location) ||
((mc_agp_location 0x)!=(((aperture+aperture_size)16)0x))){
printk(WARNING ! Radeon memory controller is misconfigured, disabling
capture\n);
printk(WARNING ! upgrade your Xserver and DRM driver\n);
return 0;
}
return 1;
}
it is from GATOS km driver and it checks whether the configuration is the
recommended configuration from ATI docs.
best
Vladimir Dergachev
On Sun, 7 Mar 2004, Jon Smirl wrote:
I'm trying to merge some of the functions from the radeon DRM and FB device
drivers into a single driver. I've been working on the code for a week trying to
get AGP working but I can't seem to figure out what is wrong. In
drm/radeon_cp.c, radeon_cp_init_ring_buffer() there is a test to see if the GPU
will write the registers out to AGP space:
RADEON_WRITE( RADEON_SCRATCH_ADDR, RADEON_READ( RADEON_CP_RB_RPTR_ADDR )
+ RADEON_SCRATCH_REG_OFFSET );
dev_priv-scratch = ((__volatile__ u32 *)
dev_priv-ring_rptr-handle +
(RADEON_SCRATCH_REG_OFFSET / sizeof(u32)));
RADEON_WRITE( RADEON_SCRATCH_UMSK, 0x7 );
/* Writeback doesn't seem to work everywhere, test it first */
DRM_WRITE32( dev_priv-ring_rptr, RADEON_SCRATCHOFF(1), 0 );
RADEON_WRITE( RADEON_SCRATCH_REG1, 0xdeadbeef );
for ( tmp = 0 ; tmp dev_priv-usec_timeout ; tmp++ ) {
if ( DRM_READ32( dev_priv-ring_rptr, RADEON_SCRATCHOFF(1) ) ==
0xdeadbeef )
break;
DRM_UDELAY( 1 );
}
I have tried checking everything in my code and I can't figure out why this
won't work. I have agp enabled, I bound the memory, I have it mapped in the user
app and the kernel. I have also checked AGP_COMMAND and the mode is set and AGP
is enabled. I checked MC_AGP_LOCATION and MC_FB_LOCATION and they look right.
The tricky part is if I run Xfree and then run my code, my code works. So, I
appear to be missing something in the initial setup. I have tried searching all
over Xfree but I can't spot the difference.
Does the CP need to be running for this to work?
Does PCI bus mastering need to be enabled?
Any other ideas on what to look for?
The code is at bk://mesa3d.bkbits.net/drm. It is kernel 2.6 only and uses sysfs.
You need the sysfs eeprom driver for ddc to work.
=
Jon Smirl
[EMAIL PROTECTED]
__
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
---
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
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. (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.) 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 version 1.2 (II) ATI(0): [drm] created mach64 driver at busid pci::01:00.0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xc4f0d000 (II) ATI(0): [drm] mapped SAREA 0xc4f0d000 to 0x282d3000 (II) ATI(0): [drm] framebuffer handle = 0xfd00 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [drm]
What's in CVS but not in XFree86 4.4.0? (was Re: [Dri-devel] MergedFB in XFree86 4.4.0?)
Alex Deucher wrote: --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Was the DRI tree ever synced with the XFree86 tree prior to 4.4.0? I downloaded and installed 4.4.0 on a NetBSD system, thinking that MergedFB would just work but, unfortunately, it doesn't. Nope, no mergedfb in 4.4. Mergedfb is only available in the DRI tree at the moment. Is there a list somewhere of what's in the current DRI tree that isn't in XFree86 4.4.0? I think that would help answer some of the questions like this and help the folks working on the x.org tree figure out what they want to merge in from DRI CVS. An initial list is: - GLX / device independent code - Client-side support for GLX_SGIX_fbconfig. - New DRI driver interface (backwards compatable with old interface). - R200 driver - Support for 3D acceleration on Radeon IGP chipsets. - Support for 3D acceleration on MergedFB setups. - Support for GLX_SGIX_fbconfig. - Refactored texture combine environment code. - R100 (radeon) driver - Support for GLX_SGIX_fbconfig. - Refactored texture combine environment code. - MGA driver - Support for GLX_SGIX_fbconfig. --- 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] [Fwd: [Fwd: xlibmesa-gl1-dri-trunk SIGFPE]]
Roberto Pariset wrote: hello, last (few days ago) xlibmesa-gl1-dri-trunk was really great on my box (SiS + sid), but the one from yesterday makes dri program crash. here is an output from glxgears: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1076844768 (LWP 3563)] 0x4043c56c in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so (gdb) where #0 0x4043c56c in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #1 0x4043c181 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #2 0x4043c2bc in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #3 0x403c8a2b in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #4 0x4033afd2 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #5 0x4033b8f8 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #6 0x4033bb31 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #7 0x40445465 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #8 0x4031da6b in __driUtilUpdateDrawableInfo () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #9 0x400847fa in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #10 0x40084bf2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #11 0x40084e8e in glXCreateContext () from /usr/X11R6/lib/libGL.so.1 #12 0x0804fde0 in ?? () (gdb) you have any old deb? i looked at http://people.debian.org/~daenzer/dri-trunk-sid/ but found out that the version of feb 28th (working) is updated at march 4th (crashing). hth, rob That's a very, very strange stack trace. Could you try again with one of the binary snapshots? The strack trace from that should give line numbers, and that will make figuring this out a lot easier. This may be related to some code that was recently merged to the trunk from the driinterface branch. In any case, there should not be ANY way for execution to get from __driUtilUpdateDrawableInfo to __driUtilCreateScreen. That's just weird... --- 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] 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] Savage XvMC
--- Sérgio Monteiro Basto [EMAIL PROTECTED] wrote: On Thu, 2004-03-04 at 20:15, Alex Deucher wrote: For those of you messing with XvMC support on savage, I just checked in a fix for the missing extension problem. I had forgotten to port over the setup code from S3's driver. I tested it briefly on savage4, but I only got an blue window. It's possible that the XvMC stuff is prosavage/twister only. Looking at the code it looks to be based on the old streams engine, so there is a good chance it is specific to those chips. If any of you out there want to test, grab the latest DRI cvs and a copy of the savage XvMC lib. you can grab the one I built here: http://www.botchco.com/alex/savage/libsavageXvMC.a move it to /usr/X11R6/lib . Also, there is not at the moment a device independant XvMC lib so you have to link any XvMC apps directly with the device dependant lib. the savage xvmc lib name is 'savageXvMC' MPlayer-1.0pre3# ./configure --enable-xvmc --with-xvmclib=savageXvMC #mplayer -vo xvmc dvd:// (...) vo: X11 running at 1024x768 with depth 24 and 32 bpp (:0 = local display) vo_xvmc: X-Video extension 2.2 vo_xvmc: X-Video MotionCompensation Extension version 1.0 == Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough VDec: vo config request - 720 x 576 (preferred csp: Mpeg PES) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. VDecoder init failed :( Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.3.1 Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2)) (...) FATAL: Could not initialize video filters (-vf) or video output (-vo). Exiting... (End of file) better then : vo_xvmc: No X-Video MotionCompensation Extension on :0 (with via drive) To create dynamic libs I think we just need the small patch in attach. Conclusion with one Savage twisterK, I still can't play with -vo xvmc but I am more close to this goal. Sarath just noticed some missing bits in savage_video.c for FOURCC_IA44. you might try again after updating from cvs. I still don't have it working on my savage4. I even tried S3's original driver, same result. I don't know if the xvmc support ever worked. Alex -- Sérgio M. B. --- savage.orig/xc/xc/config/cf/X11.tmpl2004-02-24 17:36:57.0 + +++ via/xc/xc/config/cf/X11.tmpl 2004-02-25 05:10:39.0 + @@ -1869,7 +1869,7 @@ #if BuildXvMCLibrary #ifndef SharedLibXvMC -#define SharedLibXvMCNO +#define SharedLibXvMCYES #endif #ifndef NormalLibXvMC #define NormalLibXvMCYES __ 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
Re: What's in CVS but not in XFree86 4.4.0? (was Re: [Dri-devel] MergedFB in XFree86 4.4.0?)
--- Ian Romanick [EMAIL PROTECTED] wrote: Alex Deucher wrote: --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Was the DRI tree ever synced with the XFree86 tree prior to 4.4.0? I downloaded and installed 4.4.0 on a NetBSD system, thinking that MergedFB would just work but, unfortunately, it doesn't. Nope, no mergedfb in 4.4. Mergedfb is only available in the DRI tree at the moment. Is there a list somewhere of what's in the current DRI tree that isn't in XFree86 4.4.0? I think that would help answer some of the questions like this and help the folks working on the x.org tree figure out what they want to merge in from DRI CVS. An initial list is: - GLX / device independent code - Client-side support for GLX_SGIX_fbconfig. - New DRI driver interface (backwards compatable with old interface). - R200 driver - Support for 3D acceleration on Radeon IGP chipsets. - Support for 3D acceleration on MergedFB setups. - Support for GLX_SGIX_fbconfig. - Refactored texture combine environment code. - R100 (radeon) driver R100 supports mergedfb and IGP too. - Support for 3D acceleration on Radeon IGP chipsets. - Support for 3D acceleration on MergedFB setups. - Support for GLX_SGIX_fbconfig. - Refactored texture combine environment code. - MGA driver - Support for GLX_SGIX_fbconfig. Also the savage driver now supports DRI, although it has security issues ATM like mach64. Alex __ 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
Re: [Dri-devel] Re: [Mesa3d-dev] glLightfv() bug
Robert F Merrill wrote: Robert F Merrill wrote: Bug in mesa's glLightfv() (src/mesa/main/light.c): When you send a 4-float array to glLightfv with GL_POSITION, the fourth float indicates whether the light is directional or positional. 1 is positional, 0 is directional. However, mesa checks for this after it does a matrix transform on the float array, thus making pretty much any light directional when it shouldn't be. change the check for l-EyePosition[3] != 0.0f (line 108 light.c) to param[3] != 0.0f Also, we should be using TRANSFORM_POINT3, because the fourth float has no other significance, so it should not influence the final direction... or at least that's how I think it is... I double-checked with the GL spec and the OpenGL sample implementation and I belive Mesa is correct as-is. In the OpenGL spec, Ppli (pli in subscript) is the light position after being transformed to eye coordinates. The OpenGL SI uses a full 4x4 transformation. Later, the transformed Ppli.w is tested against zero to determine the attenuation factor (equation 2.4). -Brian --- 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.
On Mon, Mar 08, 2004 at 01:25:28AM +, Dave Airlie wrote: all the mach64 really does is triangle and texturing, not much else.. so it depends on what you run on it to decide if it goes faster.. tuxracer certainly does :-) Oh, and you can have any one you want of hardware fog and alpha; take your pick. :) -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PM PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- 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] Re: Status of XFree86 4.4.0 integration?
Mike A. Harris wrote: On Mon, 1 Mar 2004, Alan Cox wrote: On Llu, 2004-03-01 at 16:28, Michel Dnzer wrote: For my part, I'd certainly prefer staying clear of the silly new license. In the long run, I'd vote for moving the DRI X server code to a freedesktop.org X server tree and the libGL code to Mesa or its own xlibs module. I'd definitely like to see this, and perhaps closer CVS integration so that DRI work can be done as a branch on the x.org tree not in a seperate tree. Assuming all the relevant powers that be can make it happen anyway Yeah, I agree with that also. The X.org tree aims to be a much more open community project. The recent reformation of X.org into The X.org Foundation has brought with it a change in the governance structure, and there are new intirim board members present which make up a good cross section of the community projects which use X technology as a base to build upon. The current plan is to have the tree develop in a way that is rather very similar to the DRI project's tree. In fact, I am proposing that we adopt the DRI CVS guidelines in the X.org tree, and the rather liberal CVS access. There's more to it than that as well, but all things aren't all worked out quite yet. I believe that once the X.org tree is off the ground so to speak, that it would make sense to discuss the possibilities of merging the trees at some point. I think it would be infinitely beneficial for both projects to have closer integration for numerous reasons, and would foster closer collaboration, between the DRI and the core, since the two owuld essentially become one and the same. It is probably a bit premature for now to make any solid decisions though, but in the next few weeks/months things should take shape. I don't have any in-principle objections to this, though I'd like to get more of a feel for the new X.org before committing to anything... Will the X.org tree include all the XFree86 DDX code - we obviously rely on that as well as the core DRI protocol stuff. Keith --- 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] Re: What's in CVS but not in XFree86 4.4.0? (was Re: [Dri-devel] MergedFB in XFree86 4.4.0?)
On Mon, 08 Mar 2004 09:28:48 -0800 Ian Romanick [EMAIL PROTECTED] wrote: [snip] Is there a list somewhere of what's in the current DRI tree that isn't in XFree86 4.4.0? I think that would help answer some of the questions like this and help the folks working on the x.org tree figure out what they want to merge in from DRI CVS. An initial list is: - GLX / device independent code - Client-side support for GLX_SGIX_fbconfig. - New DRI driver interface (backwards compatable with old interface). Have you seen my comment about a possible binary compatibility issue? I havn't looked into it any further yet. Addition: - New driver configuration infrastructure - R200 driver - Support for 3D acceleration on Radeon IGP chipsets. - Support for 3D acceleration on MergedFB setups. - Support for GLX_SGIX_fbconfig. - Refactored texture combine environment code. - Support for configuration - R100 (radeon) driver - Support for GLX_SGIX_fbconfig. - Refactored texture combine environment code. - Support for configuration - MGA driver - Support for GLX_SGIX_fbconfig. - Support for configuration - R128, SiS - Support for configuration - New drivers - mach64 - savage - via cle266 (?) Regards, Felix --- 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] AGP and radeon driver
AGP is at physical EC00 GPU sees AGP at 400, GPU AGP base is set to EC00 user and kernel virtual can both see the memory at EC00 I also tried adding pci_set_master() with no effect. The DRM driver in the kernel does not set pci_set_master(). In RADEON_AGP_COMMAND AGP_ENABLE is set. Here's some debug output: [drm:radeon_ioctl] pid=30828, cmd=0x4008642a, nr=0x2a, dev 0xe20, auth=1 [drm:radeon_lock] 1 (pid 30828) requests lock (0x), flags = 0x [drm:radeon_lock] 1 has lock [drm:radeon_mmap] start = 0x40069000, end = 0x4006a000, offset = 0xec101000 [drm:radeon_mmap]Type = 3; start = 0x40069000, end = 0x4006a000, offset = 0xec101000 [drm:radeon_vm_open] 0x40069000,0x1000 [drm:radeon_ioctl] pid=30828, cmd=0x404c6440, nr=0x40, dev 0xe20, auth=1 [drm:radeon_do_init_cp] [drm:radeon_do_init_cp] dev_priv-gart_size 8388608 [drm:radeon_do_init_cp] dev_priv-gart_vm_start 0x400 [drm:radeon_do_init_cp] dev_priv-gart_buffers_offset 0x4102000 [drm:radeon_cp_load_microcode] [drm] Loading R200 Microcode [drm:radeon_cp_init_ring_buffer] dev_priv-gart_vm_start 400 [drm:radeon_cp_init_ring_buffer] dev_priv-fb_location 0 [drm:radeon_cp_init_ring_buffer] dev_priv-gart_size 80 [drm:radeon_cp_init_ring_buffer] dev_priv-is_pci 0 [drm:radeon_cp_init_ring_buffer] RADEON_MC_FB_LOCATION 3ff [drm:radeon_cp_init_ring_buffer] RADEON_MC_AGP_LOCATION 47f0400 [drm:radeon_cp_init_ring_buffer] RADEON_CONFIG_APER_SIZE 400 [drm:radeon_cp_init_ring_buffer] RADEON_AGP_COMMAND 1f000304 [drm:radeon_cp_init_ring_buffer] ring_start 400 [drm:radeon_cp_init_ring_buffer] cur_read_ptr 0 [drm:radeon_cp_init_ring_buffer] dev-agp-base ec00 [drm:radeon_cp_init_ring_buffer] RADEON_CP_RB_RPTR_ADDR 4101000 [drm:radeon_cp_init_ring_buffer] dev_priv-scratch f893b020 [drm:radeon_cp_init_ring_buffer] dev_priv-ring_rptr-handle f893b000 [drm:radeon_cp_init_ring_buffer] dev_priv-ring_rptr-offset ec101000 [drm:radeon_cp_init_ring_buffer] dev_priv-ring_rptr-size 1000 [drm:radeon_cp_init_ring_buffer] *dev_priv-ring_rptr-handle 334455 -- user app put this there to make sure kernel virtual, physical and user virtual matched. [drm:radeon_cp_init_ring_buffer] writeback test failed [drm:radeon_do_engine_reset] [drm:radeon_do_cp_reset] [EMAIL PROTECTED] drm]# = Jon Smirl [EMAIL PROTECTED] __ 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
Re: [Dri-devel] Re: Status of XFree86 4.4.0 integration?
Around 19 o'clock on Mar 8, Keith Whitwell wrote: I don't have any in-principle objections to this, though I'd like to get more of a feel for the new X.org before committing to anything. That seems sensible. I don't think there's any particular urgency here, nothing related to DRI will likely change radically anytime soon. Will the X.org tree include all the XFree86 DDX code - we obviously rely on that as well as the core DRI protocol stuff. Yes. Right now, the X.org tree is serving as a place for developers and distributors to collaboratively support an X tree that is essentially identical to XFree86 4.4, but without the new license and the (very small) amount of code published only under that license. Stablizing the tree and getting something shipping that people can distribute is the first priority. I'm sure lots of people would like to see Mesa/DRI development more closely tied to X driver development so that there wasn't this 'big merge' problem to face every few months. Precisely how that should work is something we can figure out in time. One key is to split responsibilities across stable interfaces so that we can ship modern drivers into existing distributions. Of course, my own hope is that X turns into a simple GL application and all of the hardware management becomes someone else's problem... -keith pgp0.pgp Description: PGP signature
Re: [Dri-devel] [Fwd: [Fwd: xlibmesa-gl1-dri-trunk SIGFPE]]
i reinstalled the latest deb in sid, using deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ as a repository. the message is the same. is it a snapshot? if not, where can i find those, exactly? thanks rob [EMAIL PROTECTED]:~$ gdb glxgears GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...(no debugging symbols found)... (gdb) run Starting program: /usr/X11R6/bin/glxgears (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 1076848864 (LWP 1255)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1076848864 (LWP 1255)] 0x4043d56c in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so (gdb) where #0 0x4043d56c in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #1 0x4043d181 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #2 0x4043d2bc in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #3 0x403c9a2b in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #4 0x4033bfd2 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #5 0x4033c8f8 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #6 0x4033cb31 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #7 0x40446465 in __driUtilCreateScreen () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #8 0x4031ea6b in __driUtilUpdateDrawableInfo () from /usr/X11R6/lib/modules-dri-trunk/dri/sis_dri.so #9 0x400857fa in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #10 0x40085bf2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #11 0x40085e8e in glXCreateContext () from /usr/X11R6/lib/libGL.so.1 #12 0x0804fde0 in ?? () (gdb) --- 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] [Fwd: [Fwd: xlibmesa-gl1-dri-trunk SIGFPE]]
Roberto Pariset wrote: mmm so can i fix it somehow or just wait for a new deb? isnt SSE a cpu flag? if so i /proc/cpuinfo says i have it (amd xp 1600+). thanks rob Il lun, 2004-03-08 alle 22:57, David Bronaugh ha scritto: SNIP I think this has been covered about a million times.. the SIGFPU is caused by the test for SSE. David Bronaugh You should just continue beyond it. It isn't anything to worry about. David Bronaugh --- 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] mach64 dri on freebsd 5.2
Leif Delgass [EMAIL PROTECTED] writes: [snip] 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. [snip] (II) ATI(0): [drm] Will request pseudo-DMA (MMIO) mode ^ [snip rest of log] Everything in the log looks fine, but you are getting MMIO mode and not real DMA mode. You should use real DMA to get the best performance. Actually, I thought real DMA mode was the default, but you should be able to force it on with: Option DMAMode async in the Device section of XF86Config. thank you. I added this to my XF86Config, and now glxgears reports: 880 frames in 5.0 seconds = 176.000 FPS 878 frames in 5.0 seconds = 175.600 FPS 883 frames in 5.0 seconds = 176.600 FPS 880 frames in 5.0 seconds = 176.000 FPS 878 frames in 5.0 seconds = 175.600 FPS more than 50% better. However I ran into unexpected trouble building gltron and have been too busy/distracted to make it work it yet. If you know of a good open source opengl benchmark, I would be grateful to know about it. --- 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] AGP and radeon driver
I think I have located the problem. AGP_BASE is getting stomped somehow. Now I just need to track down where and how. My user space app is clearly setting it: /* Initialize Radeon's AGP registers */ /* Ring buffer is at AGP offset 0 */ OUTREG(RADEON_AGP_BASE, info-ringHandle); But when I get ready to use it, it is wrong: [drm:radeon_cp_init_ring_buffer] RADEON_AGP_BASE d5c0 then I set it back to the right value and it works. [drm:radeon_cp_init_ring_buffer] RADEON_AGP_BASE ec00 This never should have been set from user space to begin with. I'm moving the code for setting it into the DRM driver in my version. Also, pci_set_master() does not seem to be required for AGP. = Jon Smirl [EMAIL PROTECTED] __ 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
Re: [Dri-devel] [Fwd: [Fwd: xlibmesa-gl1-dri-trunk SIGFPE]]
Roberto Pariset wrote: mmm so can i fix it somehow or just wait for a new deb? isnt SSE a cpu flag? if so i /proc/cpuinfo says i have it (amd xp 1600+). thanks rob Il lun, 2004-03-08 alle 22:57, David Bronaugh ha scritto: SNIP I think this has been covered about a million times.. the SIGFPU is caused by the test for SSE. Basically, if it's getting to SSE dectection, it's in the driver and wy past the bug you were seeing. So, the good news is you shouldn't see that bug anymore. The bad new is that means there's some sort of binary compatability problem going on...ugh... --- 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] [Bug 512] Video crashes xinerama system
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=512 --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 19:59 --- As I suspected, I'm finding more places where the X server segfaults due to null pointers in structures. The latest is as follows: #0 0x09534d7b in _tnl_copy_immediate_vertices (ctx=0x9c0d790, next=0x9cae520) at t_imm_fixup.c:409 #1 0x09530d37 in _tnl_execute_cassette (ctx=0x9c0d790, IM=0x9cae520) at t_imm_exec.c:456 #2 0x0951a491 in _tnl_flush_immediate (IM=0x9cae520) at t_imm_api.c:70 #3 0x0951bd0a in _tnl_Vertex3fv (v=0xbab8b530) at t_imm_api.c:869 #4 0x09314a0b in glVertex3fv (v=0xbab8b530) at glapitemp.h:1571 #5 0x0926559c in __glXDisp_Vertex3fv (pc=0xbab8b530 \201\\027?\0206\210?) at g_render.c:613 #6 0x092b4140 in __glXRender (cl=0x9868f90, pc=0xbab8b52c \020) at glxcmds.c:1188 #7 0x092baedf in __glXDispatch (client=0x98580b0) at glxext.c:431 #8 0x080cc86d in Dispatch () at dispatch.c:450 #9 0x080e2873 in main (argc=3, argv=0xbfec3b64, envp=0xbfec3b74) at main.c:435 #10 0x00b81770 in __libc_start_main () from /lib/tls/libc.so.6 The second line of code in function _tnl_copy_immediate_vertices looks like: struct immediate *prev = tnl-ExecCopySource; but the value of tnl is null so it segfaults. I'm sure this is related to most of the problems above where I'm trying to index off null pointers. Does someone understand what the ExecCopySource is and what might cause it to be null? This only happens when Xinerama is enabled, and I believe it became a problem when going from 4.2 to 4.3. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- 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] Async swapping
I'd like to discuss / revisit what it will take to implement asynchronous swapping. By this I mean glXSwapBuffers returns immediately even if the driver needs to wait several frames (due to the swap interval or whatever) to actually do the swap. I've thought of a couple ways to do this, but they all have issues. Perhaps other people can think of some alternatives? - Implement the wait in the kernel. The driver calls a new swap ioctl that takes the 'target' frame as a parameter. The kernel mainains a queue of pending swaps that is checked each time a vblank interrupt is handled. A mechanism for the driver to determine if the swap had actually happened would also be need. I don't like this method because it would make it more difficult to add support for gang-swapping (i.e., GLX_SGIX_swap_group). - Keep the queue of pending swaps in the user-space driver. Add an ioctl for the kernel to deliver a signal to the app / driver when a specified vblank has occured. I don't like this method for two reasons. First, it requires the use of a signal from a library without the knowledge of the application. That's pretty evil. Second, I don't think the driver could dispatch the swap (or do much else useful) from the signal handler. - Keep the queue of pending swaps in the user-space driver. Spawn a second thread that *only* performs swaps. It blocks on a futuex or similar the gets uped each time a vblank occurs. When the required vblank has happend, it calls the existing ioctl to perform the swap. I think I like this option the best, but using an extra thread just feels wrong. At the same time, it would be easy to encapsulate all of the knowledge about when to perform a swap in that extra thread. All of these options would require extra logic in the driver to prevent rendering operations (but certain state-changes should be okay?) while a swap was pending. Some of this could be mitigated by implementing triple buffering for windows pbuffers, but that would require per-window backbuffers and a bunch of other stuff. Actually, given enough memory, each time a swap happened the driver could just allocate a new backbuffer to render to. When the swap happened the old backbuffer would be freed. Nevermind that tangent for now... ;) --- 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] Async swapping
On Mon, Mar 08, 2004 at 08:28:55PM -0800, Ian Romanick wrote: | ... | - Implement the wait in the kernel. The driver calls a new swap ioctl | that takes the 'target' frame as a parameter. The kernel mainains a | queue of pending swaps that is checked each time a vblank interrupt is | handled. ... This is essentially the implementation that I've seen used before. As you mentioned, it has to be modified somewhat to deal with gang-swapping. Allen --- 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
