[Dri-devel] COMMIT_RING patches for r128
Michel,
How do these changes for r128 COMMIT_RING look? With these I can run
concurrent xine and glx programs in pci and agp mode with XV dma
disabled.
With XV dma enabled, in both pci and agp mode, I can run xine for some
time without any hangs. But startup a glx program and X will hang until I
kill the glx program, and then X and xine will recover. I guess sync is the
next issue, I have a follow-on question on that below.
The patch also includes a change to RING_SPACE_TEST..., based on
the radeon version, adding a register read fallback for determining ring
space.
The current drm r128 does not have any WAIT_UNTIL_*_IDLE macros.
I assume I'm going to need at least a general idle wait to address sync
issues. The only WAIT_UNTIL mask bit defined in r128_drv.h is for page
flip, are there any other bits available for wait functions?
Henry
diff -ur kernel.orig/r128_drv.h kernel/r128_drv.h
--- kernel.orig/r128_drv.h Fri Jul 5 01:31:11 2002
+++ kernel/r128_drv.h Wed Jul 17 22:02:59 2002
@@ -414,10 +414,23 @@
r128_update_ring_snapshot( ring ); \
if ( ring->space >= ring->high_mark ) \
goto __ring_space_done; \
- DRM_UDELAY(1); \
+ DRM_UDELAY(1); \
} \
+DRM_ERROR( "ring space check from memory failed, reading
+register...\n" ); \
+ /* \
+* If ring space check fails from RAM, try reading the \
+* register directly \
+*/ \
+ ring->space = ( R128_READ( R128_PM4_BUFFER_DL_RPTR )\
+ - ring->tail ) * sizeof(u32); \
+ \
+ if ( ring->space <= 0 ) \
+ ring->space += ring->size; \
+ if ( ring->space >= ring->high_mark ) \
+ goto __ring_space_done; \
+ \
DRM_ERROR( "ring space check failed!\n" ); \
- return DRM_ERR(EBUSY); \
+ return DRM_ERR(EBUSY); \
} \
__ring_space_done:\
; \
@@ -487,11 +500,16 @@
dev_priv->ring.start, \
write * sizeof(u32) ); \
} \
- r128_flush_write_combine(); \
dev_priv->ring.tail = write;\
- R128_WRITE( R128_PM4_BUFFER_DL_WPTR, write ); \
} while (0)
+
+#define COMMIT_RING() do { \
+ r128_flush_write_combine(); \
+ R128_WRITE( R128_PM4_BUFFER_DL_WPTR, dev_priv->ring.tail ); \
+} while (0)
+
+
#define OUT_RING( x ) do { \
if ( R128_VERBOSE ) { \
DRM_INFO( " OUT_RING( 0x%08x ) at 0x%x\n",\
diff -ur kernel.orig/r128_state.c kernel/r128_state.c
--- kernel.orig/r128_state.cFri Jul 5 01:31:11 2002
+++ kernel/r128_state.c Wed Jul 17 18:02:19 2002
@@ -1256,6 +1256,7 @@
*/
dev_priv->sarea_priv->dirty |= R128_UPLOAD_CONTEXT | R128_UPLOAD_MASKS;
+ COMMIT_RING();
return 0;
}
@@ -1281,6 +1282,7 @@
r128_cce_dispatch_flip( dev );
}
+ COMMIT_RING();
return 0;
}
@@ -1340,6 +1342,7 @@
r128_cce_dispatch_vertex( dev, buf );
+ COMMIT_RING();
return 0;
}
@@ -1411,6 +1414,7 @@
r128_cce_dispatch_indices( dev, buf, elts.start, elts.end, count );
+ COMMIT_RING();
return 0;
}
@@ -1420,6 +1424,7 @@
drm_device_dma_t *dma = dev->dma;
drm_r128_private_t *dev_priv = dev->dev_private;
drm_r128_blit_t blit;
+ int ret;
LOCK_TEST_WITH_RETURN( dev );
@@ -1437,7 +1442,9 @@
RING_SPACE_TEST_WITH_RETURN( dev_priv );
VB_AGE_TEST_WITH_RETURN( dev_priv );
- return r128_cce_dispatch_blit( dev, &blit );
+ ret = r128_cce_dispatch_blit( dev, &blit );
+ COM
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 23:15, Henry Worth wrote: > Michel Dänzer wrote: > > > > >The intermediate variable isn't needed if one changes the macro argument > >from v to e.g. v0. I've now basically copied those macros from the > >radeon driver and updated the above patch to what I just committed. > > > >Thanks for your fixes! > > > Took a look at the archive, I had tried that, but it won't work because not > all of the VERTEX union's variants have the color field at the same offset , > depending upon whether or not there is a depth field, thus the > vi[coloroffset]. Right, I had missed that, thanks for pointing it out. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 11:18:59PM +0200, Charl P. Botha wrote: > I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in > throwing away all my data) kernel a shot to see whether updates to agpgart > make any difference. 2.5.26 is currently missing some of the fixes of 2.4.19rc2. The big changes pending merging to 2.5.soon (my split-up work, 2.4 fix forward ports, and GregKH's PCI changes) are merged into 2.5.25-dj2 available from... ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/ Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 09:38:54AM +0200, Charl P. Botha wrote: > On Wed, Jul 17, 2002 at 01:04:38AM +0200, Michel Dänzer wrote: > > The code is there but not enabled on x86 yet. Can you try with it > > enabled? You need to define PCIGART_ENABLED both in the DRM and the 2D > > driver. It would also be interesting to know how it works besides VT > > switching, see that other thread. Beware that it used to be unstable and > > may still crash, but I guess you've gotten used to that. ;) > > Thanks to ext3 crashes aren't HALF as painful as they used to be. ;) I > will try with PCIGART_ENABLED this evening when I get home (I don't have the > laptop with me). I'm also planning to give 2.5.25 a shot at some stage to > see if updates to the AGPGART change things. Okay, I updated my DRI CVS checkout, made sure PCIGART was enabled in radeon_dri.c and the DRM sources and rebuilt both the kernel module and the radeon_drv.o module. X starts up, the bottom half of the screen is painted with a rubbish pattern and the top-half remains black. Once again, I have control of the mouse pointer, but otherwise can perform no input. Shutdown time... I checked the XFree86.log, and ForcePCIMode is definitely being honoured. I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in throwing away all my data) kernel a shot to see whether updates to agpgart make any difference. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
Michel Dänzer wrote: > >The intermediate variable isn't needed if one changes the macro argument >from v to e.g. v0. I've now basically copied those macros from the >radeon driver and updated the above patch to what I just committed. > >Thanks for your fixes! > Took a look at the archive, I had tried that, but it won't work because not all of the VERTEX union's variants have the color field at the same offset , depending upon whether or not there is a depth field, thus the vi[coloroffset]. You can get rid of the intermediate with some repeated casting, but why not just code it once and let the compiler do the work? Henry > --- 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: Mach64 flatshading
On Wed, 17 Jul 2002, Keith Whitwell wrote: > >>I've done all the others. Lets see if testing was required... > >> > > > > So, should I commit the fix for r128? I've tested that and it works fine. > > Yes, go ahead. > > > I took a look at the other drivers concerning the read buffer fix. It > > looks like mga, i810, and i830 already do this correctly. Reading from a > > separate read buffer doesn't seem to be implemented on tdfx and sis. It > > looks like ffb, gamma, r128, and radeon need the fix. The attached patch > > has fixes for all the drivers except sis (I included tdfx even though the > > ReadBuffer isn't used). I've tested the read buffer fix on mach64 and > > r128 with texenv (single-buffer mode), checking to see that textures done > > in software are correctly blended with the front buffer when the > > background is turned off (the checker-board should show through in the > > transparent areas). You'd have to force a fallback to test this on Radeon > > or other drivers without texture fallbacks. > > Sounds good - go ahead & commit this to. OK, these are both committed. I've only tested the read buffer fix on r128, but I don't forsee any problems. For most drivers with few fallbacks, the problem probably went unnoticed anyway. Thanks for the clipping fix Keith, your one line beat my original 'fix' by a mile! -- 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] Weird "memory :" messages in the kernel log
Hello! I'm using Linux 2.4.19-rc1-ac7, and sometimes the kernel prints strange messages to the kernel log while XFree86 is running: memory : c71c43d4 memory : c71c441c memory : c71c4464 It turns out that the messages come from drivers/char/agp/agpgart_fe.c Please keep in mind that the debug messages are seen not only by developers of your subsystem (AGP), they are seen by anyone who runs "dmesg -n 8" for any other reason. I had no idea that it was AGP until I scanned Linux sources for "memory :" Please at least use PFX like you do in other places. It would be nice to add some words so that users would know how serious the condition is, e.g. "memory corrupted at:" or "memory allocated at:" -- Regards, Pavel Roskin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 20:03, Henry Worth wrote: > Michel Dänzer wrote: > > > > >AGP has become very stable here since the radeon driver doesn't update > >the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING(). > >Seems updating it 'too often' is no good, for whatever 'too often' may > >mean. > > > Does this also involve the differences between the radeon_cp_* and > r128_cce_* functions involving the dirty and discard bits, and > DMA_COPY_FROM_USER's? Not sure what you mean exactly, the difference in the ioctl interfaces? I don't think those are important for stability, the radeon interfaces were the same as they are now when it was less stable. > Which versions of the kernel drivers are considered most current, dri > CVS or kernel.org? DRI Development happens in DRI CVS. > Or is some merging possibly needed? Possibly, but I don't expect anything but fixes for changes in the kernel and the like in the kernel trees. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] Have a sneak peak at the new DRI website and give your opinions.
email me and I will email you the updated version, it is currently less than 70K uncompressed (it uses the existing site) this version may be up to double that -I'll try to keep it down in size. Liam it depends --- 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: Mach64 flatshading
Leif Delgass wrote: > On Wed, 17 Jul 2002, Keith Whitwell wrote: > > >>Leif Delgass wrote: >> >>>On Wed, 17 Jul 2002, Leif Delgass wrote: >>> >>> >>> On 17 Jul 2002, Michel Dänzer wrote: >On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote: > > >>I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon >>and r200. >> >> >Great job! The clipping problems I originally reported with the >xscreensaver gears hack and fsv are fixed. > > I've applied this fix to the mach64 FastRenderClippedPoly function and reverted my previous fix. I've tested the fix on r128 and it works there as well. It looks like it needs to be applied to all drivers with the FastRenderClippedPoly function, but I can't test any of the other drivers. There's another fix I made to the mach64 driver that I think needs to be applied to all drivers, and that's setting the read buffer equal to the draw buffer when switching draw buffers. This fixes software fallbacks when drawing on the front buffer. I've tested it on r128 and it works. Should I try my hand at combining these into a single patch for all the drivers? >>>At any rate, the patch for r128 with the read buffer + flatshade fix is >>>attached. If nobody has any objections, I can commit this. Maybe someone >>>with access to other cards would like to try making the changes for other >>>drivers? >>> >>I've done all the others. Lets see if testing was required... >> > > So, should I commit the fix for r128? I've tested that and it works fine. Yes, go ahead. > I took a look at the other drivers concerning the read buffer fix. It > looks like mga, i810, and i830 already do this correctly. Reading from a > separate read buffer doesn't seem to be implemented on tdfx and sis. It > looks like ffb, gamma, r128, and radeon need the fix. The attached patch > has fixes for all the drivers except sis (I included tdfx even though the > ReadBuffer isn't used). I've tested the read buffer fix on mach64 and > r128 with texenv (single-buffer mode), checking to see that textures done > in software are correctly blended with the front buffer when the > background is turned off (the checker-board should show through in the > transparent areas). You'd have to force a fallback to test this on Radeon > or other drivers without texture fallbacks. Sounds good - go ahead & commit this to. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 21:14, Henry Worth wrote: > Michel Dänzer wrote: > > > > >Thanks for testing. I've cleaned up the patch slightly to better fit > >into the existing code and added a kludge for HOST_BIG_ENDIAN_EN: > > > >http://www.penguinppc.org/~daenzer/DRI/r128-dri-endianness.diff > > > >Henry, if this works for you, I'll commit it. > > > > > I applied and retested it, looks good. One pedantic little change to the > diff that I missed is attached, it might avoid future problems. The intermediate variable isn't needed if one changes the macro argument from v to e.g. v0. I've now basically copied those macros from the radeon driver and updated the above patch to what I just committed. Thanks for your fixes! -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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: Mach64 flatshading
On Wed, 17 Jul 2002, Keith Whitwell wrote:
> Leif Delgass wrote:
> > On Wed, 17 Jul 2002, Leif Delgass wrote:
> >
> >
> >>On 17 Jul 2002, Michel Dänzer wrote:
> >>
> >>
> >>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> >>>
> I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> and r200.
>
> >>>Great job! The clipping problems I originally reported with the
> >>>xscreensaver gears hack and fsv are fixed.
> >>>
> >>I've applied this fix to the mach64 FastRenderClippedPoly function and
> >>reverted my previous fix.
> >>
> >>I've tested the fix on r128 and it works there as well. It looks like it
> >>needs to be applied to all drivers with the FastRenderClippedPoly
> >>function, but I can't test any of the other drivers.
> >>
> >>There's another fix I made to the mach64 driver that I think needs to be
> >>applied to all drivers, and that's setting the read buffer equal to the
> >>draw buffer when switching draw buffers. This fixes software fallbacks
> >>when drawing on the front buffer. I've tested it on r128 and it works.
> >>Should I try my hand at combining these into a single patch for all the
> >>drivers?
> >
> > At any rate, the patch for r128 with the read buffer + flatshade fix is
> > attached. If nobody has any objections, I can commit this. Maybe someone
> > with access to other cards would like to try making the changes for other
> > drivers?
>
> I've done all the others. Lets see if testing was required...
So, should I commit the fix for r128? I've tested that and it works fine.
I took a look at the other drivers concerning the read buffer fix. It
looks like mga, i810, and i830 already do this correctly. Reading from a
separate read buffer doesn't seem to be implemented on tdfx and sis. It
looks like ffb, gamma, r128, and radeon need the fix. The attached patch
has fixes for all the drivers except sis (I included tdfx even though the
ReadBuffer isn't used). I've tested the read buffer fix on mach64 and
r128 with texenv (single-buffer mode), checking to see that textures done
in software are correctly blended with the front buffer when the
background is turned off (the checker-board should show through in the
transparent areas). You'd have to force a fallback to test this on Radeon
or other drivers without texture fallbacks.
--
Leif Delgass
http://www.retinalburn.net
? current.diff
? r128/r128-drawbuffer+flatshade.diff
Index: ffb/ffb_state.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/ffb/ffb_state.c,v
retrieving revision 1.4
diff -u -r1.4 ffb_state.c
--- ffb/ffb_state.c 12 Jun 2002 15:50:25 - 1.4
+++ ffb/ffb_state.c 17 Jul 2002 20:25:24 -
@@ -477,20 +477,20 @@
fprintf(stderr, "ffbDDSetDrawBuffer: mode(%s)\n",
_mesa_lookup_enum_by_nr(buffer));
#endif
- fbc &= ~(FFB_FBC_WB_AB);
+ fbc &= ~(FFB_FBC_WB_AB | FFB_FBC_RB_MASK);
switch (buffer) {
case GL_FRONT_LEFT:
if (fmesa->back_buffer == 0)
- fbc |= FFB_FBC_WB_B;
+ fbc |= FFB_FBC_WB_B | FFB_FBC_RB_B;
else
- fbc |= FFB_FBC_WB_A;
+ fbc |= FFB_FBC_WB_A | FFB_FBC_RB_A;
break;
case GL_BACK_LEFT:
if (fmesa->back_buffer == 0)
- fbc |= FFB_FBC_WB_A;
+ fbc |= FFB_FBC_WB_A | FFB_FBC_RB_A;
else
- fbc |= FFB_FBC_WB_B;
+ fbc |= FFB_FBC_WB_B | FFB_FBC_RB_B;
break;
case GL_FRONT_AND_BACK:
Index: gamma/gamma_state.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/gamma/gamma_state.c,v
retrieving revision 1.2
diff -u -r1.2 gamma_state.c
--- gamma/gamma_state.c 14 Feb 2002 01:59:52 - 1.2
+++ gamma/gamma_state.c 17 Jul 2002 20:25:28 -
@@ -1047,10 +1047,10 @@
switch ( mode ) {
case GL_FRONT_LEFT:
- gmesa->drawOffset = 0;
+ gmesa->drawOffset = gmesa->readOffset = 0;
break;
case GL_BACK_LEFT:
- gmesa->drawOffset = gmesa->driScreen->fbHeight * gmesa->driScreen->fbWidth *
gmesa->gammaScreen->cpp;
+ gmesa->drawOffset = gmesa->readOffset = gmesa->driScreen->fbHeight *
+gmesa->driScreen->fbWidth * gmesa->gammaScreen->cpp;
break;
}
Index: r128/r128_state.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r128/r128_state.c,v
retrieving revision 1.22
diff -u -r1.22 r128_state.c
--- r128/r128_state.c 12 Jun 2002 15:50:25 - 1.22
+++ r128/r128_state.c 17 Jul 2002 20:25:37 -
@@ -689,13 +689,13 @@
switch ( mode ) {
case GL_FRONT_LEFT:
-rmesa->drawOffset = rmesa-
Re: [Dri-devel] Re: r128 PPC patches
>
> I applied and retested it, looks good. One pedantic little change to
> the diff
> that I missed is attached, it might avoid future problems.
>
Another version to fix a typo.
Henry
--- r128-dri-endianness.diff.orig Wed Jul 17 12:02:48 2002
+++ r128-dri-endianness.diffWed Jul 17 12:03:34 2002
@@ -120,7 +120,7 @@
-} while (0)
+#define VERT_SET_RGBA( v, c ) \
+ do {\
-+ r128_color_t *vc = (r128_color_t *)&v->ui[coloroffset]; \
++ r128_color_t *vc = (r128_color_t *)&(v)->ui[coloroffset]; \
+ vc->blue = (c)[2]; \
+ vc->green = (c)[1]; \
+ vc->red = (c)[0]; \
Re: [Dri-devel] Re: Mach64 flatshading
Leif Delgass wrote: > On Wed, 17 Jul 2002, Leif Delgass wrote: > > >>On 17 Jul 2002, Michel Dänzer wrote: >> >> >>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote: >>> I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon and r200. >>>Great job! The clipping problems I originally reported with the >>>xscreensaver gears hack and fsv are fixed. >>> >>I've applied this fix to the mach64 FastRenderClippedPoly function and >>reverted my previous fix. >> >>I've tested the fix on r128 and it works there as well. It looks like it >>needs to be applied to all drivers with the FastRenderClippedPoly >>function, but I can't test any of the other drivers. >> >>There's another fix I made to the mach64 driver that I think needs to be >>applied to all drivers, and that's setting the read buffer equal to the >>draw buffer when switching draw buffers. This fixes software fallbacks >>when drawing on the front buffer. I've tested it on r128 and it works. >>Should I try my hand at combining these into a single patch for all the >>drivers? >> > > At any rate, the patch for r128 with the read buffer + flatshade fix is > attached. If nobody has any objections, I can commit this. Maybe someone > with access to other cards would like to try making the changes for other > drivers? I've done all the others. Lets see if testing was required... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 flatshading
On Wed, 17 Jul 2002, Leif Delgass wrote:
> On 17 Jul 2002, Michel Dänzer wrote:
>
> > On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
> > > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
> > > and r200.
> >
> > Great job! The clipping problems I originally reported with the
> > xscreensaver gears hack and fsv are fixed.
>
> I've applied this fix to the mach64 FastRenderClippedPoly function and
> reverted my previous fix.
>
> I've tested the fix on r128 and it works there as well. It looks like it
> needs to be applied to all drivers with the FastRenderClippedPoly
> function, but I can't test any of the other drivers.
>
> There's another fix I made to the mach64 driver that I think needs to be
> applied to all drivers, and that's setting the read buffer equal to the
> draw buffer when switching draw buffers. This fixes software fallbacks
> when drawing on the front buffer. I've tested it on r128 and it works.
> Should I try my hand at combining these into a single patch for all the
> drivers?
At any rate, the patch for r128 with the read buffer + flatshade fix is
attached. If nobody has any objections, I can commit this. Maybe someone
with access to other cards would like to try making the changes for other
drivers?
--
Leif Delgass
http://www.retinalburn.net
? r128-drawbuffer+flatshade.diff
Index: r128_state.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r128/r128_state.c,v
retrieving revision 1.22
diff -u -r1.22 r128_state.c
--- r128_state.c12 Jun 2002 15:50:25 - 1.22
+++ r128_state.c17 Jul 2002 19:27:03 -
@@ -689,13 +689,13 @@
switch ( mode ) {
case GL_FRONT_LEFT:
-rmesa->drawOffset = rmesa->r128Screen->frontOffset;
-rmesa->drawPitch = rmesa->r128Screen->frontPitch;
+rmesa->drawOffset = rmesa->readOffset = rmesa->r128Screen->frontOffset;
+rmesa->drawPitch = rmesa->readPitch = rmesa->r128Screen->frontPitch;
FALLBACK( rmesa, R128_FALLBACK_DRAW_BUFFER, GL_FALSE );
break;
case GL_BACK_LEFT:
-rmesa->drawOffset = rmesa->r128Screen->backOffset;
-rmesa->drawPitch = rmesa->r128Screen->backPitch;
+rmesa->drawOffset = rmesa->readOffset = rmesa->r128Screen->backOffset;
+rmesa->drawPitch = rmesa->readPitch = rmesa->r128Screen->backPitch;
FALLBACK( rmesa, R128_FALLBACK_DRAW_BUFFER, GL_FALSE );
break;
default:
Index: r128_tris.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r128/r128_tris.c,v
retrieving revision 1.17
diff -u -r1.17 r128_tris.c
--- r128_tris.c 2 Jun 2002 16:00:43 - 1.17
+++ r128_tris.c 17 Jul 2002 19:27:04 -
@@ -501,9 +501,9 @@
rmesa->num_verts += (n-2) * 3;
for (i = 2 ; i < n ; i++) {
- COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) start );
COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) VERT(elts[i-1]) );
COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) VERT(elts[i]) );
+ COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) start );
}
}
Re: [Dri-devel] Re: r128 PPC patches
Michel Dänzer wrote:
>
>Thanks for testing. I've cleaned up the patch slightly to better fit
>into the existing code and added a kludge for HOST_BIG_ENDIAN_EN:
>
>http://www.penguinppc.org/~daenzer/DRI/r128-dri-endianness.diff
>
>Henry, if this works for you, I'll commit it.
>
I applied and retested it, looks good. One pedantic little change to the
diff
that I missed is attached, it might avoid future problems.
I've also tested on my 500mhz G3 PowerBook 2000 (Pismo), no problems
with eliminating the HOST BE bit there, even sleep/wake work. Hadn't
tried your XV dma fix on it before, alas the speedup isn't as dramatic as
on the G4, but it does reduce dropped frames enough to eliminate most of
the flutter. Alas, while the dma/agp instabilites don't manifest as quickly
as on the SMP system, they can be tripped if I try hard enough.
Thanks,
Henry
--- r128-dri-endianness.diff.orig Wed Jul 17 12:02:48 2002
+++ r128-dri-endianness.diffWed Jul 17 12:03:34 2002
@@ -120,7 +120,7 @@
-} while (0)
+#define VERT_SET_RGBA( v, c ) \
+ do {\
-+ r128_color_t *vc = (r128_color_t *)&v->ui[coloroffset]; \
++ r128_color_t *vc = (r128_color_t *)&((v)->ui[coloroffset]; \
+ vc->blue = (c)[2]; \
+ vc->green = (c)[1]; \
+ vc->red = (c)[0]; \
Re: [Dri-devel] Re: Mach64 flatshading
On 17 Jul 2002, Michel Dänzer wrote: > On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote: > > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon > > and r200. > > Great job! The clipping problems I originally reported with the > xscreensaver gears hack and fsv are fixed. I've applied this fix to the mach64 FastRenderClippedPoly function and reverted my previous fix. I've tested the fix on r128 and it works there as well. It looks like it needs to be applied to all drivers with the FastRenderClippedPoly function, but I can't test any of the other drivers. There's another fix I made to the mach64 driver that I think needs to be applied to all drivers, and that's setting the read buffer equal to the draw buffer when switching draw buffers. This fixes software fallbacks when drawing on the front buffer. I've tested it on r128 and it works. Should I try my hand at combining these into a single patch for all the drivers? -- 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] Re: Mach64 flatshading
On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote: > I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon > and r200. Great job! The clipping problems I originally reported with the xscreensaver gears hack and fsv are fixed. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon and r200. Basically any driver with a 'fast_clipped_poly' function needs to check that the vertices are emitted preserving the PV order. I think most/all are wrong currently. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
Michel Dänzer wrote: > >AGP has become very stable here since the radeon driver doesn't update >the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING(). >Seems updating it 'too often' is no good, for whatever 'too often' may >mean. > Does this also involve the differences between the radeon_cp_* and r128_cce_* functions involving the dirty and discard bits, and DMA_COPY_FROM_USER's? Which versions of the kernel drivers are considered most current, dri CVS or kernel.org? Or is some merging possibly needed? --- 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] mmio size -- thanks everyone
OK, I've got enough info to get an idea of what hardware variation exists out there. Thanks to everyone who responded. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MACH64VT (264VT) vs. RAGE IIc
It also looks like bus-mastering capabilities were added starting with the 264VT-B and Rage II. That would include Rage IIc, but not plain 264VT. However, the 2D driver doesn't currently use bus mastering. On Wed, 17 Jul 2002, Leif Delgass wrote: > The Rage IIc is part of the more recent GT family and adds "improved video > filtering" (according to the programmer's guide) and some 3D features > (texturing, I think). Unfortunately, neither of these cards are supported > by the DRI driver since they don't have triangle setup. > > On Wed, 17 Jul 2002, Dieter [iso-8859-15] Nützel wrote: > > > Hello, > > > > I have both (PCI) for my fathers computer. > > Which one is better? > > Any docs? Specs? > > > > Thanks, > > Dieter > > > > > > --- > > 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
[Dri-devel] Re: radeon mmio area size
Hi Keith! Tuesday 16, at 01:58:29 PM you wrote: > Can someone out there check this quickly? > > In radeon.h in the 2d driver, the size of the radeon mmio area is defined > as 0x8 - however, on my r200 at least, /proc/pci shows the area as > being 1/8th that size: > > Bus 1, device 0, function 0: > ... (omitted) ... > Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. > > Can someone with a radeon installed make the same check? > > Keith > Bus 1, device 0, function 0: VGA compatible controller: PCI device 1002:5157 (ATI Technologies Inc) (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xd000 [0xd7ff]. I/O at 0x9000 [0x90ff]. Non-prefetchable 32 bit memory at 0xdd00 [0xdd00]. it's Radeon 7500 QW -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR This message was checked for viruses by RAV Antivirus (www.ravantivirus.com) --- 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: Mach64 flatshading
Michel Dänzer wrote: > On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: > >>On Tue, 16 Jul 2002, Keith Whitwell wrote: >> >> Well, it's not high on my list. I don't think flat-shading is used that often, and the changes don't have any effect on smooth shading. Actually, it _eliminates_ some saves/restores necessary for unfilled polygons with hardware flat-shading. Actually, I think the problem is larger than mach64. Rage128 has the same problem and it appears to have GL compliant flat-shading based on the primitive. The problem is that for clipped polygons, the primitive type changes, so flat-shading breaks down in that case (like with unfilled polygons). I think the templates would have to be changed to copy the provoking-vertex color of the polygon being clipped into the vertices of the triangles generated by clipping, rather than interpolating the color. >>>I'm surprised that this isn't working. Can you verify? I tested on the i810 >>>at the time & definitely got clipping working there... >>> >>Here's a couple screenshots with the r128 driver (20020629 build): >> >>http://www.retinalburn.net/linux/r128-unclipped-flat.png >>http://www.retinalburn.net/linux/r128-clipped-flat.png >> >>Allen's test program is attached. Maybe someone could check this on >>Radeon with software tcl as well? >> > > Broken, as expected. As we've both been reporting for some time, > software clipping is broken in the r128 and radeon drivers. I used to > suspect a Mesa problem, but the mga driver works. I wish I knew what to > look for about this problem... Sorry, I hadn't noticed the bug reports... I imagine the r200 is doing the same thing, so I can look into it today. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MACH64VT (264VT) vs. RAGE IIc
The Rage IIc is part of the more recent GT family and adds "improved video filtering" (according to the programmer's guide) and some 3D features (texturing, I think). Unfortunately, neither of these cards are supported by the DRI driver since they don't have triangle setup. On Wed, 17 Jul 2002, Dieter [iso-8859-15] Nützel wrote: > Hello, > > I have both (PCI) for my fathers computer. > Which one is better? > Any docs? Specs? > > Thanks, > Dieter > > > --- > 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
[Dri-devel] MACH64VT (264VT) vs. RAGE IIc
Hello, I have both (PCI) for my fathers computer. Which one is better? Any docs? Specs? Thanks, Dieter --- 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: r128 PPC patches
On Wed, 2002-07-17 at 16:50, Leif Delgass wrote: > On Tue, 16 Jul 2002, Leif Delgass wrote: > > > > These look very good to me, I'll commit them. Leif, can you verify they > > > don't break x86? I'd be very surprised, but it wouldn't be the first > > > time. :) > > > > I'll give these a try once I've updated my tree, I was testing from > > binaries before. > > The changes don't seem to break anything on x86. I tried with and without > the texutil.c changes. Thanks for testing. I've cleaned up the patch slightly to better fit into the existing code and added a kludge for HOST_BIG_ENDIAN_EN: http://www.penguinppc.org/~daenzer/DRI/r128-dri-endianness.diff Henry, if this works for you, I'll commit it. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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: r128 PPC patches
On Tue, 16 Jul 2002, Leif Delgass wrote: > > These look very good to me, I'll commit them. Leif, can you verify they > > don't break x86? I'd be very surprised, but it wouldn't be the first > > time. :) > > I'll give these a try once I've updated my tree, I was testing from > binaries before. The changes don't seem to break anything on x86. I tried with and without the texutil.c changes. -- 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: [Mesa3d-dev] Re: [Dri-devel] Re: Mach64 flatshading
On Wed, 17 Jul 2002, Leif Delgass wrote: > On 17 Jul 2002, Michel Dänzer wrote: > > > On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: > > > On Tue, 16 Jul 2002, Keith Whitwell wrote: > > > > > > > > Well, it's not high on my list. I don't think flat-shading is used that > > > > > often, and the changes don't have any effect on smooth shading. Actually, > > > > > it _eliminates_ some saves/restores necessary for unfilled polygons with > > > > > hardware flat-shading. > > > > > > > > > > Actually, I think the problem is larger than mach64. Rage128 has the same > > > > > problem and it appears to have GL compliant flat-shading based on the > > > > > primitive. The problem is that for clipped polygons, the primitive type > > > > > changes, so flat-shading breaks down in that case (like with unfilled > > > > > polygons). I think the templates would have to be changed to copy the > > > > > provoking-vertex color of the polygon being clipped into the vertices of > > > > > the triangles generated by clipping, rather than interpolating the color. > > > > > > > > I'm surprised that this isn't working. Can you verify? I tested on the i810 > > > > at the time & definitely got clipping working there... > > > > > > Here's a couple screenshots with the r128 driver (20020629 build): > > > > > > http://www.retinalburn.net/linux/r128-unclipped-flat.png > > > http://www.retinalburn.net/linux/r128-clipped-flat.png > > > > > > Allen's test program is attached. Maybe someone could check this on > > > Radeon with software tcl as well? > > > > Broken, as expected. As we've both been reporting for some time, > > software clipping is broken in the r128 and radeon drivers. I used to > > suspect a Mesa problem, but the mga driver works. I wish I knew what to > > look for about this problem... > > Actually, since mga uses DO_FLAT in the templates, the provoking-vertex > color gets copied to all vertices. I think the problem is with > interpolation and drivers that define DO_FLAT as zero. Keith said that > i810 worked, but it _doesn't_ set DO_FLAT, which is the define that > controls whether colors are copied. It sets HAVE_HW_FLATSHADE, but that > just causes colors to be saved and restored when working with unfilled > tris. Oops, I confused myself there. :) If i810 works with DO_FLAT defined as zero, that doesn't support this theory. Maybe there's some other differenece in the way it handles clipped polygons. -- 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: Mach64 flatshading
On 17 Jul 2002, Michel Dänzer wrote: > On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: > > On Tue, 16 Jul 2002, Keith Whitwell wrote: > > > > > > Well, it's not high on my list. I don't think flat-shading is used that > > > > often, and the changes don't have any effect on smooth shading. Actually, > > > > it _eliminates_ some saves/restores necessary for unfilled polygons with > > > > hardware flat-shading. > > > > > > > > Actually, I think the problem is larger than mach64. Rage128 has the same > > > > problem and it appears to have GL compliant flat-shading based on the > > > > primitive. The problem is that for clipped polygons, the primitive type > > > > changes, so flat-shading breaks down in that case (like with unfilled > > > > polygons). I think the templates would have to be changed to copy the > > > > provoking-vertex color of the polygon being clipped into the vertices of > > > > the triangles generated by clipping, rather than interpolating the color. > > > > > > I'm surprised that this isn't working. Can you verify? I tested on the i810 > > > at the time & definitely got clipping working there... > > > > Here's a couple screenshots with the r128 driver (20020629 build): > > > > http://www.retinalburn.net/linux/r128-unclipped-flat.png > > http://www.retinalburn.net/linux/r128-clipped-flat.png > > > > Allen's test program is attached. Maybe someone could check this on > > Radeon with software tcl as well? > > Broken, as expected. As we've both been reporting for some time, > software clipping is broken in the r128 and radeon drivers. I used to > suspect a Mesa problem, but the mga driver works. I wish I knew what to > look for about this problem... Actually, since mga uses DO_FLAT in the templates, the provoking-vertex color gets copied to all vertices. I think the problem is with interpolation and drivers that define DO_FLAT as zero. Keith said that i810 worked, but it _doesn't_ set DO_FLAT, which is the define that controls whether colors are copied. It sets HAVE_HW_FLATSHADE, but that just causes colors to be saved and restored when working with unfilled tris. -- 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] radeon mmio area size
On Tuesday 16 Jul 2002 8:58 pm, Keith Whitwell scribed numinously:" > Can someone out there check this quickly? > > In radeon.h in the 2d driver, the size of the radeon mmio area is defined > as 0x8 - however, on my r200 at least, /proc/pci shows the area as > being 1/8th that size: > >Bus 1, device 0, function 0: > ... (omitted) ... >Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. > > Can someone with a radeon installed make the same check? Radeon 7500 (QD) Bus 1, device 0, function 0: VGA compatible controller: PCI device 1002:5157 (ATI Technologies Inc) (rev 0). IRQ 9. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xe000 [0xe7ff]. I/O at 0x9000 [0x90ff]. Non-prefetchable 32 bit memory at 0xed00 [0xed00]. Looks the same as yours. -- Tim Smith ([EMAIL PROTECTED]) I do not suffer from insanity; I am enjoying every moment of it. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
Adam Duck wrote: >>"Michal" == Michal Bukovjan <[EMAIL PROTECTED]> writes: >> >> > >Michal> Keith Whitwell wrote: >>> Can someone out there check this quickly? >>> >>> In radeon.h in the 2d driver, the size of the radeon mmio area is >>> defined as 0x8 - however, on my r200 at least, /proc/pci shows the >>> area as being 1/8th that size: >>> >>> Bus 1, device 0, function 0: >>> ... (omitted) ... >>> Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. >>> >>> Can someone with a radeon installed make the same check? >>> >Michal> Here is mine (Radeon AIW - QD): > >Michal> Bus 1, device 0, function 0: >Michal> VGA compatible controller: ATI Technologies Inc Radeon QD (rev 0). >Michal> Non-prefetchable 32 bit memory at 0xdd00 [0xdd07]. > >Hey, why do you have that much??? >Mine also says - like the other's here: > > Bus 1, device 5, function 0: >VGA compatible controller: ATI Technologies Inc Radeon QL (rev 0). > Non-prefetchable 32 bit memory at 0xe900 [0xe900]. > >Bye, *disappointed* Adam. > Don't know ... Is it good or bad? Is there anything I can do about this? Is there any setting (in BIOS, or config file) that can adjust this? Anyway, I am using latest GATOS drivers + drm on this machine and both XVideo and 3d works flawlessly (RTCW, Rune, chromium B.S.D.) - although no TCL, of course. I wish DRI and GATOS would merge :-( Maybe someday... Michal --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 05:15, Henry Worth wrote: > Henry Worth wrote: > > > I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit > > set and with the PACK*LE macros. And, the 2-d stuff seems to be working > > and the textures do need the PACK*LE macros. So, perhaps the bit only > > impacts the DMA blits used to load the texture subimages? > > > > If someone with the docs can confirm what that bit is suppose to do, we > > may get be able to getaway with eliminating that bit. > > Found a big pro and con for running without that bit set--- XV! > > Xine playing a DVD requires 40% less cpu time on dual 450 G4's. That's > likely from reduced byte-swapping and would hold the promise of most G3's > with Rage 128's finally being able to play DVD's without dropped frames. (For the archives: As you've found out, that's not due to that bit but DMA transfers for Xv) > The con... it's very unstable and subject to server and system hangs. > Concurrently trying to move windows is impossibly slow and jerky, and > may cause artifacts and momentary (multi-second) hangs. In one case > the server and system (telnet session wouldn't respond) hung till I > moved the mouse. Trying to run glxgears causes an instant server hang. > > For comparison, with 4.2.0 I can load up the system with makes and > seti's to 99+% and then start xine and glxgears. And while xine is > dropping a lot of frames, playback has only a slight flutter and X is > still responsive enough to fireup and use mozilla. > > BTW, I'm in forced PCI mode, which has been needed for XV and DRI to run > concurrently, but will have to give AGP mode a try. AGP has become very stable here since the radeon driver doesn't update the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING(). Seems updating it 'too often' is no good, for whatever 'too often' may mean. > Looks like some nasty DMA contention problems, perhaps the kernel drivers > need some compensating changes? Something else which is done better in the radeon driver than in r128 is synchronization between the 2D and 3D streams. Lack of that can cause lockups. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 03:32, Henry Worth wrote: > Michel Dänzer wrote: > > >On Wed, 2002-07-17 at 02:10, Henry Worth wrote: > > > >>Attached are patches for r128 on ppc. Rather little change to the r128 code > >>was needed once I gave up on the char arrays for the vertex colors, and > >>embraced the hw specific ordered named fields provided in the *_color_t > >>provided by t_dd_vertex.h. > >> > >>1) Revert PACK*LE from texutil.c as per previous emails. > >> > > > >Thank you for breaking the radeon and mach64 drivers on big endian > >machines. ;) We've got to find a better solution here, I must confess I > >still don't understand how it can not work with PACK*LE though. Maybe > >the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in > >R128EngineInit() in the 2D driver) is interfering, causing the texture > >data to be byte-swapped in the HOST_DATA registers? If so, your changes > >should not be really correct for 16 bit anyway. I've been there while > >playing with the various possibilities of fixing endianness in the > >radeon driver, it looked mostly good but e.g. the floor texture in > >armagetron showed the problem. > > > You're welcome. > > At least with the mesa demos it works the same in 16 and 32 bpp... I > did see some oddness in 16bpp before fixing the copies in the t_dd_vbtmp.h > emit funcs. I was going to explain how 16 bit textures break with CONVERT_TEXEL instead of CONVERT_TEXEL_DWORD, but that was before APPEND16, which fixes the texel order. With this, it seems we could get away without PACK*LE in the radeon and r128, maybe even mach64 drivers. But can we assume that any chip can swap texel bytes? As chips likely will be little endian internally in the foreseeable future, I think defaulting to that is safest. > But, if it is due to a hw capability, then the sw arch needs to handle that, > i.e. make the PACK*LE configurable. Which would probably mean texutil > would need to be compiled at the driver level, rather than the common level. That would be a possibility, maybe a texutil driver template. I don't think the current code is really bad though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
> "Michal" == Michal Bukovjan <[EMAIL PROTECTED]> writes: Michal> Keith Whitwell wrote: >> Can someone out there check this quickly? >> >> In radeon.h in the 2d driver, the size of the radeon mmio area is >> defined as 0x8 - however, on my r200 at least, /proc/pci shows the >> area as being 1/8th that size: >> >> Bus 1, device 0, function 0: >> ... (omitted) ... >> Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. >> >> Can someone with a radeon installed make the same check? >> Michal> Here is mine (Radeon AIW - QD): Michal> Bus 1, device 0, function 0: Michal> VGA compatible controller: ATI Technologies Inc Radeon QD (rev 0). Michal> Non-prefetchable 32 bit memory at 0xdd00 [0xdd07]. Hey, why do you have that much??? Mine also says - like the other's here: Bus 1, device 5, function 0: VGA compatible controller: ATI Technologies Inc Radeon QL (rev 0). Non-prefetchable 32 bit memory at 0xe900 [0xe900]. Bye, *disappointed* Adam. -- Adam Duck ([EMAIL PROTECTED]) Bockenheimer Landstr. 135 / Zi. 211 60325 Frankfurt/Main __ Klingon multitasking systems do not support "time-sharing". When a Klingon program wants to run, it challenges the scheduler in hand-to-hand combat and owns the machine. --- Klingon Programmer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mach64 flatshading
On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: > On Tue, 16 Jul 2002, Keith Whitwell wrote: > > > > Well, it's not high on my list. I don't think flat-shading is used that > > > often, and the changes don't have any effect on smooth shading. Actually, > > > it _eliminates_ some saves/restores necessary for unfilled polygons with > > > hardware flat-shading. > > > > > > Actually, I think the problem is larger than mach64. Rage128 has the same > > > problem and it appears to have GL compliant flat-shading based on the > > > primitive. The problem is that for clipped polygons, the primitive type > > > changes, so flat-shading breaks down in that case (like with unfilled > > > polygons). I think the templates would have to be changed to copy the > > > provoking-vertex color of the polygon being clipped into the vertices of > > > the triangles generated by clipping, rather than interpolating the color. > > > > I'm surprised that this isn't working. Can you verify? I tested on the i810 > > at the time & definitely got clipping working there... > > Here's a couple screenshots with the r128 driver (20020629 build): > > http://www.retinalburn.net/linux/r128-unclipped-flat.png > http://www.retinalburn.net/linux/r128-clipped-flat.png > > Allen's test program is attached. Maybe someone could check this on > Radeon with software tcl as well? Broken, as expected. As we've both been reporting for some time, software clipping is broken in the r128 and radeon drivers. I used to suspect a Mesa problem, but the mga driver works. I wish I knew what to look for about this problem... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] 8500 & Xvideo
Hi, sorry if this is a dumb question :) I was wondering if it was possible to use Xvideo with the radeon 8500 drivers? I know gatos is more apropriate for such questions, but i would like to have 3D and Xvideo. For the moment i'm forced to use mplayer with the -noxv switch... Thanks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
Hi, here is mine: Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (rev 0). IRQ 10. Master Capable. Latency=66. Min Gnt=8. Prefetchable 32 bit memory at 0xd800 [0xdfff]. I/O at 0x2000 [0x20ff]. Non-prefetchable 32 bit memory at 0xd010 [0xd010]. Its a HP omnibook 6100. I also have the problem with look up when switching to a other vt and back. And crashes when i start a opengl app. On Tue, Jul 16, 2002 at 01:58:29PM -0600, Keith Whitwell wrote: > Can someone out there check this quickly? > > In radeon.h in the 2d driver, the size of the radeon mmio area is defined > as 0x8 - however, on my r200 at least, /proc/pci shows the area as > being 1/8th that size: > > Bus 1, device 0, function 0: > ... (omitted) ... > Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. > > Can someone with a radeon installed make the same check? > > Keith > > > > --- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Markus Benning Siemens AG I&S IT PS 51 Internetteam --- 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] segfault in r200InitIoctlFuncs->r200GetAllParams.
I built with -O3 -march=athlon, thought I'v been doing that for some time now. ddd reports the segfalut during the pushl of the fd, just befor calling drmCommandWriteRead. Dump of assembler code for function r200InitIoctlFuncs: 0x4054eba0 :push %ebp 0x4054eba1 : mov%esp,%ebp 0x4054eba3 : sub$0x8,%esp 0x4054eba6 : mov0x8(%ebp),%eax 0x4054eba9 : mov0x2ac(%eax),%ecx 0x4054ebaf : movl $0x4054dc20,0xe0(%eax) 0x4054ebb9 : movl $0x4054ea80,0xf0(%eax) 0x4054ebc3 : lea0x3444(%ecx),%edx 0x4054ebc9 : movl $0x4054e430,0xf4(%eax) 0x4054ebd3 : push $0x8 0x4054ebd5 : mov%edx,0xfffc(%ebp) 0x4054ebd8 : lea0xfff8(%ebp),%edx 0x4054ebdb : push %edx 0x4054ebdc : push $0x11 0x4054ebde : movl $0x1,0xfff8(%ebp) > 0x4054ebe5 : pushl 0x343c(%ecx) 0x4054ebeb : call 0x4040ca20 __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 01:04:38AM +0200, Michel Dänzer wrote: > On Tue, 2002-07-16 at 23:02, Charl P. Botha wrote: > > Option "AGPMode" "2" > > Does 1x make a difference? 1x makes no difference; still X freezes after a switch to VT and back. > > # Option "ForcePCIMode" "On" # not supported by DRI yet > > The code is there but not enabled on x86 yet. Can you try with it > enabled? You need to define PCIGART_ENABLED both in the DRM and the 2D > driver. It would also be interesting to know how it works besides VT > switching, see that other thread. Beware that it used to be unstable and > may still crash, but I guess you've gotten used to that. ;) Thanks to ext3 crashes aren't HALF as painful as they used to be. ;) I will try with PCIGART_ENABLED this evening when I get home (I don't have the laptop with me). I'm also planning to give 2.5.25 a shot at some stage to see if updates to the AGPGART change things. Thanks for your input! Best regards, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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
