[Dri-devel] Re: COMMIT_RING patches for r128
I've been doing some more testing. With, and without, the commit_ring patches, even in pci mode, I can get X to hang without too much effort by firing up several glx demos and then x11perf. One of the glx programs will hang holding hw locks in r128WaitForFrameCompletion() from r128CopyBuffer(). The other glx programs are in the drmGetLock() ioctl from one of the r128render* functions, and x11perf in select from _XWaitForWritable(). Once the glx programs and x11perf are killed, the X server hang clears, but any attempt to start a glx program will hang the X server in the same r128WaitForFrameCompletion() from r128CopyBuffer() condition on it's first frame. A restart of X is required to reset drm. 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
[Dri-devel] Re: COMMIT_RING patches for r128
Henry Worth wrote: > > > BTW, I do see quite a few "128(0): Idle timed out, resetting engine..." > being logged by r128_accel.c's R128WaitForIdle() routine when running > x11perf with both the old and new drivers. Tripped a different hang running xine in agp mode with XV dma disabled. With xine running, started glxgears and X hung. Killed glxgears and kde appeared to be restarting the desktop and then xine stuttered a few times before X hung again. During this, the cpu monitor showed high system cycles and lots of the following messages where being logged by r128_accel.c's R128CCEGetBuffer: (EE) R128(0): R128CCEGetBuffer: CCE GetBuffer -1002 (EE) R128(0): GetBuffer timed out, resetting engine... And the kernel log has this a few thousand times: kernel: [drm:r128_freelist_get] *ERROR* returning NULL! I could kill X from a telnet session, but the screen wouldn't clear and the kybd didn't seem responsive, had to reboot. Introduced by the COMMIT_RING changes, an example of the sync problems, or a bit of both? I think I've seen a few of these messages in the past, but don't recall a flood of them. 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] COMMIT_RING patches for r128
Michel Dänzer wrote:
>On Thu, 2002-07-18 at 16:40, Keith Whitwell wrote:
>
>>Henry Worth wrote:
>>
>>>
>>I have no idea why there is a need for the RING_SPACE_TEST macro. It's
>>disabled in the r200 branch.
>>
>
>Besides, I've never hit the added code there.
>
Ok, I won't worry about that.
>>>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?
>>>
>>What does the r128 currently do to synchronize access to the framebuffer?
>>
>
>XAA handles that, and both drivers provide WaitForIdle() as the Sync
>function.
>
>>It may be that 2d & 3d are synchronized by the hardware automatically,
>>
>
>I doubt that, e.g. the texture blit ioctl also flushes the pixel cache.
>Maybe there's more to do with the PC_{,N}GUI_* registers?
>
>>but you'll always need to do something before accessing the framebuffer
>>directly.
>>
>
>I don't see where direct framebuffer access is involved when using DMA
>transfers for Xv.
>
So where to go from here? I can only spend a couple more days on this in
the near
term, so I don't have time to deal with the NDA and digging thru the
docs. Unless
someone else has a good recommendation, I'll try to flesh out some sync code
based on the radeon code and maybe someone else can correct the details
later.
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
[Dri-devel] Re: COMMIT_RING patches for r128
Michel Dänzer wrote: >On Thu, 2002-07-18 at 09:47, Henry Worth wrote: > >>Henry Worth wrote: >> >>>Digging thru the X logs, I see that agp is failing to map the ring >>>buffer with >>>this drm module. It does with kernel module built from BenH's linuxppc >>>dev >>>tree, but I haven't tried the dri CVS before, so I don't know yet if >>>it even works >>>without the COMMIT_RING changes. [...] >>> >>Decided to do a quick compile and check before calling it a night. >>Without the >>patch, agp also fails to map the ring buffer. I'll take a look at merging >>in whatever fixes are in BenH's src tree tomorrow. >> > >Like http://www.penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff ? :) > Exactly like that... AGP is mapping the ring now. So to the results -- again this is with dual 450 G4's with SMP linux 2.4.19-rc1-ben0, DRI CVS from Monday on top of XFre86 2.4.0 with the Michel's XV dma patch, indirect buffering patch, ioremap patch, the r128 endiness patches and the COMMIT_RING changes. While it is still possible to hang X in any combination of PCI/AGP mode and XV dma enabled/disabled by mixing various pairs of XV, DRI, and concurrent X activity, like x11perf, in general it takes more effort. When it does hang I've yet to see a hard hang of the X server or of the system, as was common before. In all hang cases the offending processes could be killed and X would continue, if I was lucky enough to kill the right process, other processes would restart. Previously enabling XV dma, xine starting play would almost always hang in a very short time with SMP kernels. On occasions it did play for a while, trying to move another window was extremely jerky and slow, dispite a very low CPU load (10-15%), and would always result in an eventual hang. Hangs almost always required a reboot to recover. Now, xine with XV dma will play as long as there isn't much other X activity. X remains responsive with windows moving fairly smoothly. I was even able to run X11perf for a couple of minutes before problems occured. But, I've yet to see a literal hang, except when starting a GLX program, and killing the GLX program allowed xine to continue. The problem I now see repeatedly with XV dma is that eventually X11perf or moving a window will cause video sync to go haywire. Xine is playing audio and the keyboard is responsive, and I can ctl-alt-del. But video sync does not recover when X exits or is restarted, a reboot is required to reset the video card. Previously I had somethimes seen a problem like this, but never had keyb responsiveness and attempts to recover from a telnet session often resulted in a system hang when trying to kill X or perform a shutdown. Overall, pci mode and XV dma disabled is still the most stable mode, but agp mode with XV dma disabled is more usable. I was able to run the Mesa terrain demo with texture, two gears demos and x11perf in agp mode for 20minutes, with frequent moving and raising of windows, before a deadlock that was cleared by killing the glx processes. BTW, I do see quite a few "128(0): Idle timed out, resetting engine..." being logged by r128_accel.c's R128WaitForIdle() routine when running x11perf with both the old and new drivers. 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
[Dri-devel] Re: COMMIT_RING patches for r128
Henry Worth wrote: > > Digging thru the X logs, I see that agp is failing to map the ring > buffer with > this drm module. It does with kernel module built from BenH's linuxppc > dev > tree, but I haven't tried the dri CVS before, so I don't know yet if > it even works > without the COMMIT_RING changes. [...] Decided to do a quick compile and check before calling it a night. Without the patch, agp also fails to map the ring buffer. I'll take a look at merging in whatever fixes are in BenH's src tree tomorrow. 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
[Dri-devel] Re: COMMIT_RING patches for r128
Henry Worth wrote: > > 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. Digging thru the X logs, I see that agp is failing to map the ring buffer with this drm module. It does with kernel module built from BenH's linuxppc dev tree, but I haven't tried the dri CVS before, so I don't know yet if it even works without the COMMIT_RING changes. Anyway, let me know if there are any obvious problems/omissions in that patch. Thanks, 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
[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
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: 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: 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]; \
[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] Re: r128 PPC patches
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! Ack, I'll have to retract both the pro and con. I forgot that I was working from a fresh src tree that didn't have Michel's indirect buffering and XV dma fixes that are required for stable XV with SMP linuxppc. Stablility with SMP linuxppc kernels requires disabling XV dma and forcing PCI mode. With the patches performance and stability are back where they were before. --- 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
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. 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. Looks like some nasty DMA contention problems, perhaps the kernel drivers need some compensating changes? Henry --- 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
[Dri-devel] Re: r128 PPC patches
Michel Dänzer wrote: > >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. > 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. --- 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
[Dri-devel] Re: r128 PPC patches
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 don't have the HW docs, so someone else will have to address that. Any byteswapping at that level would have to be aware of the texel size or it'd also be swapping sub-32bpp texels out of order. 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. --- 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
Re: [Dri-devel] r128 textures
Leif Delgass wrote: >On 17 Jul 2002, Michel Dänzer wrote: > I just updated to today's build and texture colors look fine on r128 in x86. Also, we had reports that the changes made in Mesa on the trunk (which we merged into the mach64 branch) fixed textures on ppc for mach64, which has a choose texture function based on r128. >>>Since the merge, the radeon PPC fixes added an additional swap in the >>>texture path for BE systems. >>> >>If I understand correctly, the endianness fixes are the Mesa changes >>Leif referred to. >> > >Right. The merge from the trunk to the mach64 branch was done June 26 -- >after the endianess fixes. > 1> I can find no extra byte swapping being done to textures in the r128 code and dword swaps at later point in the pipeline would break 16 and 8 bpp textures. 2> The r128 texture code works without PACK*LE works on both LE and BE systems in both 32bpp and 16bpp. None of the code I had to change except the PACK*LE would affect textures. 3> Any change that I can see to make to work with the PACK*LE would have to be conditional on endiness to not break x86. But that would be redundant! 4> Something is wrong, but where? --- 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
[Dri-devel] r128 PPC patches
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. 2) t_dd_vbtmp.h has color assignments in the emit functions that use char arrays for non-RGBA without attention to endiness. Changed to use the correctly ordered named fields from the t_dd_vertex.h definition of the hw vertex color_t. Added VERTEX_COLOR_T macro so hw driver can pass in its hw vertex *_color_t; so the assignments can be made in correct order. Added macro definition to *_vb.c of the various drivers. 3) Changed r128_tris.c VERT_* macros for t_dd_tritmp.h to use the named fields instead of an char array. 4) Added some casts to r128_ioctl.c to eliminate compile warnings. r128-ppc-diffs.gz Description: GNU Zip compressed data
Re: [Dri-devel] r128 textures
Leif Delgass wrote: >On Tue, 16 Jul 2002, Henry Worth wrote: > >>Have there been any reports of r128 texture color problems on x86 with >>recent CVS? Or that it even works? >> > >I just updated to today's build and texture colors look fine on r128 in >x86. Also, we had reports that the changes made in Mesa on the trunk >(which we merged into the mach64 branch) fixed textures on ppc for mach64, >which has a choose texture function based on r128. > Since the merge, the radeon PPC fixes added an additional swap in the texture path for BE systems. But, the texutil code already appear to have been endian aware and the radeon patches also appear to be fighting the endiness, and color ordering, neutral formating in tnl_dd_vertex.h by using arrays instead of the named color fields. Since x86 r128 is working, I'm going to prep my patches with the PACK*LE changes reverted. --- 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
[Dri-devel] r128 textures
I'm in the process of finishing up some patches for r128 on PPC. One problem I've run into that conflicts with the radeon PPC fixes is the choosing and loading of textures. For radeon the PACK_COLOR* macros in extra/Mesa/src/texutil.c were changed to PACK_COLOR*LE versions. With the *LE versions in the colors are not ordered correctly for r128 on PPC . The problem appears that the r128 chooser is selecting ARGB textures which when swapped on transfer would be the required BGRA format. But on x86 they whouldn't get swapped and should be resulting in incorrect texture colors on x86. I suspect the chooser code was cut-n-pasted from radeon and not changed to reflect the r128's BGRA mode. I intend to try reconfiguring the chooser if no one sees a problem with that. But first I'd like to know: Do the exisiting texture generators support a full set of BGRA formats? Have there been any reports of r128 texture color problems on x86 with recent CVS? Or that it even works? Henry --- 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
