[Bug 2504] Xorg CVS + DRm CVS = Radeon driver Display borked, garbled!!
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2504 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 04:04 --- Ya, you are right, Colortiling off, resolved the issue. One more thing, with the latest drm, with the driver radeon (ofcorse with Colortilinf off), i get +254 fps (730fps) on glxgears, (although the wheel almost don't seem rotate. I just hope R300 project become more stable :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Rationalise DRM Kconfig
Rationalise DRM Kconfig: - Move the Kconfig options from Character devices to Graphics support. - Move the sparc64 Kconfig options into drivers/char/drm now that drivers/char/drm/Kconfig gets picked up through drivers/video/Kconfig I think the drm directory should be moved from drivers/char to drivers/video, but it's more important to get the user's config experience right. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] Index: arch/sparc64/Kconfig === RCS file: /var/cvs/linux-2.6/arch/sparc64/Kconfig,v retrieving revision 1.22 diff -u -p -r1.22 Kconfig --- arch/sparc64/Kconfig22 Jan 2005 14:59:04 - 1.22 +++ arch/sparc64/Kconfig9 Feb 2005 15:49:55 - @@ -539,44 +539,6 @@ config UNIX98_PTY_COUNT endmenu -menu XFree86 DRI support - -config DRM - bool Direct Rendering Manager (XFree86 DRI support) - help - Kernel-level support for the Direct Rendering Infrastructure (DRI) - introduced in XFree86 4.0. If you say Y here, you need to select - the module that's right for your graphics card from the list below. - These modules provide support for synchronization, security, and - DMA transfers. Please see http://dri.sourceforge.net/ for more - details. You should also select and configure AGP - (/dev/agpgart) support. - -config DRM_FFB - tristate Creator/Creator3D - depends on DRM BROKEN - help - Choose this option if you have one of Sun's Creator3D-based graphics - and frame buffer cards. Product page at - http://www.sun.com/desktop/products/Graphics/creator3d.html. - -config DRM_TDFX - tristate 3dfx Banshee/Voodoo3+ - depends on DRM - help - Choose this option if you have a 3dfx Banshee or Voodoo3 (or later), - graphics card. If M is selected, the module will be called tdfx. - -config DRM_R128 - tristate ATI Rage 128 - depends on DRM - help - Choose this option if you have an ATI Rage 128 graphics card. If M - is selected, the module will be called r128. AGP support for - this card is strongly suggested (unless you have a PCI version). - -endmenu - source drivers/input/Kconfig source drivers/i2c/Kconfig Index: drivers/char/Kconfig === RCS file: /var/cvs/linux-2.6/drivers/char/Kconfig,v retrieving revision 1.26 diff -u -p -r1.26 Kconfig --- drivers/char/Kconfig22 Jan 2005 14:59:12 - 1.26 +++ drivers/char/Kconfig9 Feb 2005 15:49:57 - @@ -901,8 +901,6 @@ endmenu source drivers/char/agp/Kconfig -source drivers/char/drm/Kconfig - source drivers/char/pcmcia/Kconfig config MWAVE Index: drivers/char/drm/Kconfig === RCS file: /var/cvs/linux-2.6/drivers/char/drm/Kconfig,v retrieving revision 1.8 diff -u -p -r1.8 Kconfig --- drivers/char/drm/Kconfig12 Jan 2005 20:16:17 - 1.8 +++ drivers/char/drm/Kconfig9 Feb 2005 15:49:57 - @@ -96,3 +96,11 @@ config DRM_SIS chipset. If M is selected the module will be called sis. AGP support is required for this driver to work. +config DRM_FFB + tristate Creator/Creator3D + depends on DRM SPARC64 BROKEN + help + Choose this option if you have one of Sun's Creator3D-based graphics + and frame buffer cards. Product page at + http://www.sun.com/desktop/products/Graphics/creator3d.html. + Index: drivers/video/Kconfig === RCS file: /var/cvs/linux-2.6/drivers/video/Kconfig,v retrieving revision 1.20 diff -u -p -r1.20 Kconfig --- drivers/video/Kconfig 22 Jan 2005 14:59:38 - 1.20 +++ drivers/video/Kconfig 9 Feb 2005 15:50:00 - @@ -4,6 +4,8 @@ menu Graphics support +source drivers/char/drm/Kconfig + config FB bool Support for frame buffer devices ---help--- -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Rationalise DRM Kconfig
Kconfig matches the underlying kernel directory structure. If we do this we should also move the location of the DRM and fbdev in the kernel tree. Something like: drivers/video/drm drivers/video./fb This can be achieved with a few bk move commands and some makefile touch up. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
texturing performance local/gart on rv250
Some more numbers, this time from a 9000Pro (64MB). In contrast to the quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidth (128bit/275Mhz DDR). Not to mention the chip is certainly faster too. Test sytem is also faster though, A64 3000+ socket 754, 3.2GB/s system memory bandwidth. Desktop resolution 1280x1024, quake3 windowed 1024x768. The hacks required to disable the heaps are exactly the same as those used on r100 (except of course the nr_heaps assertion had to go..., yes this hack DOES break the client stuff). Local texture size is 35MB, unless otherwise noted (I just changed the allocation scheme in the ddx driver, so only 1 framebuffer worth of pixmap cache is used instead of 3, btw without really any noticeable impact on 2d performance). GART size is 32MB unless specifically stated. Desktop resolution 1280x1024, quake3 windowed 1024x768. AGP 4x, local: 125 fps AGP 4x, both: 80-123 fps AGP 4x, gart only: 68 fps AGP 1x, local: 115 fps AGP 1x, gart only: 21 fps Some rtcw (demo checkpoint) results too (fullscreen 1024x768). AGP 4x, local: 70 fps AGP 4x, local 45MB: 85 fps AGP 4x, both:62-77 fps AGP 4x, both, gart 64MB: 58-68 fps AGP 4x, gart only, 64MB:47 fps AGP 1x, local: 56 fps AGP 1x, gart only: 14 fps texdown AGP 4x gart: 230MB/s texdown AGP 4x local: 650MB/s! texdown AGP 1x gart: 117MB/s before q3, 89MB/s after q3 (?) texdown AGP 1x local: 265MB/s!!! There seemed to be a problem with gart texturing and AGP modes lower than 4x, agpgart reported Putting AGP V2 device at :00:00.0 into 0x mode, glxinfo still reported AGP 1x and 2x, respectively. 1x and 2x results were identical, and to put it simply, the results downright appalling. This may be a problem with agpgart (using the version from kernel 2.6.10). However, I was amazed at the texdown performance to local graphics memory, as it's VERY close to the theoretical limit. texdown performance with AGP 4x was also quite good. the rtcw checkpoint demo exceeds in-use texture size of 35MB, that's why I've put in some results with larger local texture size (as well as increased the gart size). 45MB is enough though, with 35MB you'd get some occasional drops to around 12fps (and 6fps with agp 1x), these are completely gone with 45MB. Performance with gart texturing, even in 4x mode, takes a big hit (almost 50%). I was not really able to get consistent performance results when both texture heaps were active, I guess it's luck of the day which textures got put in the gart heap and which ones in the local heap. But that performance indeed got faster with a smaller gart heap is not a good sign. And even if the maximum obtained in rtcw with 35MB local heap and 29MB gart heap was higher than the score obtained with 35MB local heap alone, there were clearly areas which ran faster with only the local heap. It seems to me that the allocator really should try harder to use the local heap to be useful on r200 cards, moreover it is likely that you'd get quite a bit better performance when you DO have to put textures into the gart heap when you revisit that later when more space becomes available on the local heap and upload the still-used textures from the gart heap to the local heap (in fact, should be even faster than those 650MB/s, since no in-kernel-copy would be needed, it should be possible to blit it directly). Some numbers just for fun, since those are the numbers everyone wants to see... Some other OS, rtcw: 120 fps Some other OS, q3: 137 fps (this one is a bit cheated. I'm pretty sure non-fullscreen does not use pageflip. Fullscreen score was 174 fps, whereas we only improved from 125 fps to 129 fps...) This ain't that bad. I'd be happy if we'd do that well in say, ut2k4 or doom3... Roland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2164] [ATI/radeon] Color corruption with DRI enabled on Radeon cards in xorg = 6.8.0
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2164 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1863||approval_X11R6.8.x? Flag|| --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 12:08 --- (From update of attachment 1863) This was committed on HEAD as revision 1.10. -- Configure bugmail: https://bugs.freedesktop.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. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texturing performance local/gart on rv250
Is there a tool for dumping stats on which textures are in which heap? -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Rationalise DRM Kconfig
I should have read it closer, I didn't notice that it was sparc specific. In general I would like to see drm moved from drivers/char and rationally organized with fbdev. On Wed, 9 Feb 2005 12:12:47 -0800, David S. Miller [EMAIL PROTECTED] wrote: On Wed, 9 Feb 2005 11:50:43 -0500 Jon Smirl [EMAIL PROTECTED] wrote: Kconfig matches the underlying kernel directory structure. If we do this we should also move the location of the DRM and fbdev in the kernel tree. Something like: drivers/video/drm drivers/video./fb This can be achieved with a few bk move commands and some makefile touch up. Ok, you guys fight it out how to do this, but as for having sparc64 get the drm Kconfig like everyone else I totally support that. -- Jon Smirl [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Zcache flush not needed for r100 chips ?
Hi,
I suspace zcache flushing before fast zclears is not needed on r100 (and
removing it adds a couple of q3 frames :).
This patch removes it for these chips. It works fine on rv100, but I
wonder if it does on r100/rv200 too.
So, testing is welcome !
Stephane
Index: shared/radeon_state.c
===
RCS file: /cvs/dri/drm/shared/radeon_state.c,v
retrieving revision 1.43
diff -u -r1.43 radeon_state.c
--- shared/radeon_state.c 7 Feb 2005 21:11:59 - 1.43
+++ shared/radeon_state.c 9 Feb 2005 19:15:28 -
@@ -832,14 +851,20 @@
clearmask = 0x0;
}
- BEGIN_RING( 8 );
+ if (dev_priv-microcode_version==UCODE_R100) {
+ BEGIN_RING( 6 );
+ } else {
+ BEGIN_RING( 8 );
+ }
RADEON_WAIT_UNTIL_2D_IDLE();
OUT_RING_REG( RADEON_RB3D_DEPTHCLEARVALUE,
tempRB3D_DEPTHCLEARVALUE);
/* what offset is this exactly ? */
OUT_RING_REG( RADEON_RB3D_ZMASKOFFSET, 0 );
- /* need ctlstat, otherwise get some strange black flickering */
- OUT_RING_REG( RADEON_RB3D_ZCACHE_CTLSTAT,
RADEON_RB3D_ZC_FLUSH_ALL );
+ if (dev_priv-microcode_version!=UCODE_R100) {
+ /* need ctlstat, otherwise get some strange black
flickering */
+ OUT_RING_REG( RADEON_RB3D_ZCACHE_CTLSTAT,
RADEON_RB3D_ZC_FLUSH_ALL );
+ }
ADVANCE_RING();
for (i = 0; i nbox; i++) {
Index: shared-core/radeon_state.c
===
RCS file: /cvs/dri/drm/shared-core/radeon_state.c,v
retrieving revision 1.48
diff -u -r1.48 radeon_state.c
--- shared-core/radeon_state.c 8 Feb 2005 04:17:14 - 1.48
+++ shared-core/radeon_state.c 9 Feb 2005 19:15:31 -
@@ -818,14 +844,20 @@
clearmask = 0x0;
}
- BEGIN_RING( 8 );
+ if (dev_priv-microcode_version==UCODE_R100) {
+ BEGIN_RING( 6 );
+ } else {
+ BEGIN_RING( 8 );
+ }
RADEON_WAIT_UNTIL_2D_IDLE();
OUT_RING_REG( RADEON_RB3D_DEPTHCLEARVALUE,
tempRB3D_DEPTHCLEARVALUE);
/* what offset is this exactly ? */
OUT_RING_REG( RADEON_RB3D_ZMASKOFFSET, 0 );
- /* need ctlstat, otherwise get some strange black flickering */
- OUT_RING_REG( RADEON_RB3D_ZCACHE_CTLSTAT,
RADEON_RB3D_ZC_FLUSH_ALL );
+ if (dev_priv-microcode_version!=UCODE_R100) {
+ /* need ctlstat, otherwise get some strange black
flickering */
+ OUT_RING_REG( RADEON_RB3D_ZCACHE_CTLSTAT,
RADEON_RB3D_ZC_FLUSH_ALL );
+ }
ADVANCE_RING();
for (i = 0; i nbox; i++) {
drm race fix for non-core
Hi,
Attached is a straight port of Eric's fix for the drm race to non-core drm.
Stephane
Index: shared/radeon_drv.h
===
RCS file: /cvs/dri/drm/shared/radeon_drv.h,v
retrieving revision 1.40
diff -u -r1.40 radeon_drv.h
--- shared/radeon_drv.h 26 Jan 2005 17:48:59 - 1.40
+++ shared/radeon_drv.h 9 Feb 2005 19:09:32 -
@@ -976,25 +976,26 @@
} while (0)
-#define OUT_RING_USER_TABLE( tab, sz ) do {\
+#define OUT_RING_TABLE( tab, sz ) do { \
int _size = (sz); \
- int __user *_tab = (tab); \
+ int *_tab = (int *)(tab); \
\
if (write + _size mask) { \
- int i = (mask+1) - write; \
- if (DRM_COPY_FROM_USER_UNCHECKED( (int *)(ring+write), \
- _tab, i*4 )) \
- return DRM_ERR(EFAULT); \
+ int _i = (mask+1) - write; \
+ _size -= _i;\
+ while (_i 0) {\
+ *(int *)(ring + write) = *_tab++; \
+ write++;\
+ _i--; \
+ } \
write = 0; \
- _size -= i; \
- _tab += i; \
+ _tab += _i; \
+ } \
+ while (_size 0) { \
+ *(ring + write) = *_tab++; \
+ write++;\
+ _size--;\
} \
- \
- if (_size DRM_COPY_FROM_USER_UNCHECKED( (int *)(ring+write), \
- _tab, _size*4 )) \
- return DRM_ERR(EFAULT); \
- \
- write += _size; \
write = mask; \
} while (0)
Index: shared/radeon_state.c
===
RCS file: /cvs/dri/drm/shared/radeon_state.c,v
retrieving revision 1.43
diff -u -r1.43 radeon_state.c
--- shared/radeon_state.c 7 Feb 2005 21:11:59 - 1.43
+++ shared/radeon_state.c 9 Feb 2005 19:09:34 -
@@ -64,21 +64,6 @@
return 0;
}
-static __inline__ int radeon_check_and_fixup_offset_user( drm_radeon_private_t
*dev_priv,
- drm_file_t *filp_priv,
- u32 __user *offset ) {
- u32 off;
-
- DRM_GET_USER_UNCHECKED( off, offset );
-
- if ( radeon_check_and_fixup_offset( dev_priv, filp_priv, off ) )
- return DRM_ERR( EINVAL );
-
- DRM_PUT_USER_UNCHECKED( offset, off );
-
- return 0;
-}
-
static __inline__ int radeon_check_and_fixup_packets( drm_radeon_private_t
*dev_priv,
drm_file_t *filp_priv,
int id,
@@ -86,18 +71,16 @@
switch ( id ) {
case RADEON_EMIT_PP_MISC:
- if ( radeon_check_and_fixup_offset_user( dev_priv, filp_priv,
-data[(
RADEON_RB3D_DEPTHOFFSET
--
RADEON_PP_MISC ) / 4] ) ) {
+ if (radeon_check_and_fixup_offset(dev_priv, filp_priv,
+ data[(RADEON_RB3D_DEPTHOFFSET - RADEON_PP_MISC) / 4])) {
DRM_ERROR( Invalid depth buffer offset\n );
return DRM_ERR( EINVAL );
}
break;
case RADEON_EMIT_PP_CNTL:
- if ( radeon_check_and_fixup_offset_user( dev_priv, filp_priv,
-data[(
RADEON_RB3D_COLOROFFSET
--
RADEON_PP_CNTL ) / 4] ) ) {
+ if (radeon_check_and_fixup_offset(dev_priv, filp_priv,
+ data[(RADEON_RB3D_COLOROFFSET - RADEON_PP_CNTL) / 4])) {
DRM_ERROR(
Re: DRM change for R300 DMA
On Wed, 2005-02-09 at 02:32 -0500, Vladimir Dergachev wrote: On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote: Could someone with knowledge of r200_dri explain how vertex buffer uploads are put into framebuffer memory on r200? AFAIK they aren't, the only data the radeon and r200 drivers upload to the framebuffer is textures. I was mistaken then. So the sizes that Xserver prints during startup is the result of partitioning of AGP memory ? Not sure which ones you mean exactly, but the answer is probably yes anyway. :) Is there are a reason why this could not have been allocated dynamically as needed ? I guess the lack of an appropriate memory manager is a reason... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texturing performance local/gart on rv250
Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger: Some more numbers, this time from a 9000Pro (64MB). In contrast to the quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidth (128bit/275Mhz DDR). Not to mention the chip is certainly faster too. Test sytem is also faster though, A64 3000+ socket 754, 3.2GB/s system memory bandwidth. Desktop resolution 1280x1024, quake3 windowed 1024x768. The hacks required to disable the heaps are exactly the same as those used on r100 (except of course the nr_heaps assertion had to go..., yes this hack DOES break the client stuff). Local texture size is 35MB, unless otherwise noted (I just changed the allocation scheme in the ddx driver, so only 1 framebuffer worth of pixmap cache is used instead of 3, btw without really any noticeable impact on 2d performance). GART size is 32MB unless specifically stated. Desktop resolution 1280x1024, quake3 windowed 1024x768. AGP 4x, local: 125 fps AGP 4x, both: 80-123 fps AGP 4x, gart only: 68 fps AGP 1x, local: 115 fps AGP 1x, gart only: 21 fps Some rtcw (demo checkpoint) results too (fullscreen 1024x768). AGP 4x, local: 70 fps AGP 4x, local 45MB: 85 fps AGP 4x, both:62-77 fps AGP 4x, both, gart 64MB: 58-68 fps AGP 4x, gart only, 64MB:47 fps AGP 1x, local: 56 fps AGP 1x, gart only: 14 fps Thanks for these numbers. They show that the current memory management strategies are far from perfect. Read on below for some ideas how to improve it. texdown AGP 4x gart: 230MB/s texdown AGP 4x local: 650MB/s! texdown AGP 1x gart: 117MB/s before q3, 89MB/s after q3 (?) texdown AGP 1x local: 265MB/s!!! There seemed to be a problem with gart texturing and AGP modes lower than 4x, agpgart reported Putting AGP V2 device at :00:00.0 into 0x mode, glxinfo still reported AGP 1x and 2x, respectively. 1x and 2x results were identical, and to put it simply, the results downright appalling. This may be a problem with agpgart (using the version from kernel 2.6.10). However, I was amazed at the texdown performance to local graphics memory, as it's VERY close to the theoretical limit. texdown performance with AGP 4x was also quite good. Keith committed a fastpath for Mesa's texstore functions that reduced the CPU-overhead of the rgba 32bit texture uploads significantly. the rtcw checkpoint demo exceeds in-use texture size of 35MB, that's why I've put in some results with larger local texture size (as well as increased the gart size). 45MB is enough though, with 35MB you'd get some occasional drops to around 12fps (and 6fps with agp 1x), these are completely gone with 45MB. Performance with gart texturing, even in 4x mode, takes a big hit (almost 50%). I was not really able to get consistent performance results when both texture heaps were active, I guess it's luck of the day which textures got put in the gart heap and which ones in the local heap. But that performance indeed got faster with a smaller gart heap is not a good sign. And even if the maximum obtained in rtcw with 35MB local heap and 29MB gart heap was higher than the score obtained with 35MB local heap alone, there were clearly areas which ran faster with only the local heap. It seems to me that the allocator really should try harder to use the local heap to be useful on r200 cards, moreover it is likely that you'd get quite a bit better performance when you DO have to put textures into the gart heap when you revisit that later when more space becomes available on the local heap and upload the still-used textures from the gart heap to the local heap (in fact, should be even faster than those 650MB/s, since no in-kernel-copy would be needed, it should be possible to blit it directly). The big problem with the current texture allocator is that it can't tell which areas are really unused. Texture space is only allocated and never freed. Once the memory is full it starts kicking textures to upload new ones. This is the only way of freeing memory. Using an LRU strategy it has a good chance of kicking unused textures first, but there's no guarantee. It can't tell if a kicked texture will be needed the next instant. So trying to move textures from GART to local memory would basically mean that you blindly kick the least recently used texture(s) from local memory. If those textures are needed again soon then performance is going to suffer badly. Therefore I'm proposing a modified allocator that fails when it needs to start kicking too recently used textures (e.g. textures used in the current or previous frame). Failure would not be fatal in this case, you just keep the texture in GART memory and try again later. Actually you could use the same allocator for normal texture uploads. Just specify the current texture heap age as the limit. If you try to move textures back to local memory
Re: texturing performance local/gart on rv250
Felix Kühling wrote: Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger: Some more numbers, this time from a 9000Pro (64MB). In contrast to the quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidth (128bit/275Mhz DDR). Not to mention the chip is certainly faster too. Test sytem is also faster though, A64 3000+ socket 754, 3.2GB/s system memory bandwidth. Desktop resolution 1280x1024, quake3 windowed 1024x768. The hacks required to disable the heaps are exactly the same as those used on r100 (except of course the nr_heaps assertion had to go..., yes this hack DOES break the client stuff). Local texture size is 35MB, unless otherwise noted (I just changed the allocation scheme in the ddx driver, so only 1 framebuffer worth of pixmap cache is used instead of 3, btw without really any noticeable impact on 2d performance). GART size is 32MB unless specifically stated. Desktop resolution 1280x1024, quake3 windowed 1024x768. AGP 4x, local: 125 fps AGP 4x, both: 80-123 fps AGP 4x, gart only: 68 fps AGP 1x, local: 115 fps AGP 1x, gart only: 21 fps Some rtcw (demo checkpoint) results too (fullscreen 1024x768). AGP 4x, local: 70 fps AGP 4x, local 45MB: 85 fps AGP 4x, both:62-77 fps AGP 4x, both, gart 64MB: 58-68 fps AGP 4x, gart only, 64MB:47 fps AGP 1x, local: 56 fps AGP 1x, gart only: 14 fps Thanks for these numbers. They show that the current memory management strategies are far from perfect. Read on below for some ideas how to improve it. texdown AGP 4x gart: 230MB/s texdown AGP 4x local: 650MB/s! texdown AGP 1x gart: 117MB/s before q3, 89MB/s after q3 (?) texdown AGP 1x local: 265MB/s!!! There seemed to be a problem with gart texturing and AGP modes lower than 4x, agpgart reported Putting AGP V2 device at :00:00.0 into 0x mode, glxinfo still reported AGP 1x and 2x, respectively. 1x and 2x results were identical, and to put it simply, the results downright appalling. This may be a problem with agpgart (using the version from kernel 2.6.10). However, I was amazed at the texdown performance to local graphics memory, as it's VERY close to the theoretical limit. texdown performance with AGP 4x was also quite good. Keith committed a fastpath for Mesa's texstore functions that reduced the CPU-overhead of the rgba 32bit texture uploads significantly. I think the radeon actually uses a rgba intnernal format, unlike the argb everything else does (which was the subject of the commit). That means mesa will upload GL_RGBA textures with a straight memcpy, though it still hits a very slow path with near miss texture formats. Keith --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2515] New: MGA: Several squares of progs/tests/crossbar rendered incorrectly
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2515
Summary: MGA: Several squares of progs/tests/crossbar rendered
incorrectly
Product: Mesa
Version: CVS
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Drivers/DRI/MGA
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
A few of the squares (most of them, actually) of progs/tests/crossbar are not
rendered correctly. Annoyingly, the square that is just GL_REPLACE of the 0.5
gray texture is one of the incorrectly rendered squares. It is slightly too
dark.This may be an artifact of specifying the textures as RGB888 and the
driver converting them to RGB565.
Regardless, the (1.0 - 0.5) square is too light, and the ((0.5 + 0.5) * 0.5) and
(0.25 + 0.25) * 1.0) squares are much too dark. The result in every square is
supposed to be RGB = {0.5, 0.5, 0.5}.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] New: texture border cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2516 Summary: texture border cause segfaults Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] the use of texture borders causes segfaults with the r200 driver. Not that anyone would use that feature, I just discovered that accidentally. Start texdown, hit b, boom. Actually, at one time I did not get a segfault, but a drm error instead ([drm:radeon_cp_dispatch_texture] *ERROR* EFAULT). Since texture borders should cause a fallback afaik, I'm not sure how that happened. As pretty much always when something goes wrong in the pixel fallback path, I can't get a backtrace from that neither since the segfault happens behind a LOCK_HARDWARE. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] some rasterization fallbacks cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2516 [EMAIL PROTECTED] changed: What|Removed |Added Summary|texture border cause|some rasterization fallbacks |segfaults |cause segfaults --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 17:57 --- Some more digging found this is not only related to texture borders, other rasterization fallbacks suffer from that as well (easily tested with texenv, just changed one of the texture wrap modes to GL_CLAMP_TO_BORDER which causes a rast fallback). Summary changed accordingly. It reaches the r200Fallback path just fine, and then strangely later dies in _tnl_run_pipeline called from r200WrapRunPipeline. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] some rasterization fallbacks cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2516 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 18:29 --- Simply calling UNLOCK_HARDWARE in r200SpanRenderStart was all that was needed to get this locally debuggable. That said, I have no idea what is going on... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 988616000 (LWP 8096)] _tnl_build_vertices (ctx=0x8060990, start=0, end=0, newinputs=0) at tnl/t_vertex.c:1379 1379 a[j].inputstride = vptr-stride; (gdb) bt #0 _tnl_build_vertices (ctx=0x8060990, start=0, end=0, newinputs=0) at tnl/t_vertex.c:1379 #1 0x3afb4fe3 in run_render (ctx=0x8060990, stage=0x0) at tnl/t_vb_render.c:296 #2 0x3afa5fde in _tnl_run_pipeline (ctx=0x8060990) at tnl/t_pipeline.c:159 #3 0x3af2a92f in r200WrapRunPipeline (ctx=0x8060990) at r200_state.c:2316 #4 0x3afc340a in _tnl_flush_vtx (ctx=0x8060990) at tnl/t_vtx_exec.c:282 #5 0x3afbe8a8 in _tnl_FlushVertices (ctx=0x8060990, flags=1) at tnl/t_vtx_api.c:838 #6 0x3af3ca4c in r200FlushVertices (ctx=0x8060990, flags=1) at r200_swtcl.c:906 #7 0x3af8d6af in _mesa_TexImage2D (target=3553, level=0, internalFormat=6407, width=258, height=258, border=1, format=6407, type=5121, pixels=0x41180008) at main/teximage.c:2096 #8 0x08049321 in MeasureDownloadRate () at texdown.c:163 #9 0x080495b2 in Display () at texdown.c:256 #10 0x3aaeafa1 in fghcbDisplayWindow () from /usr/lib/libglut.so.3 #11 0x3aaee36a in fgEnumWindows () from /usr/lib/libglut.so.3 #12 0x3aaeb2ef in glutMainLoopEvent () from /usr/lib/libglut.so.3 #13 0x3aaebbf5 in glutMainLoop () from /usr/lib/libglut.so.3 #14 0x0804999c in main (argc=1, argv=0xa1c4) at texdown.c:384 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL apps causes frequent system locks
I'm using the new prebuilt debs that include an Xorg server and I get a hardlock just after mode swich, befour the desktop shows. There is no usefull debuging I have been able todo, exept to say commenting out the dri Xmod stopes the problem. 2005.01.26-2 from John Lightsey [EMAIL PROTECTED]. Untill now I thought it was just me and my r200. --- Geller Sandor [EMAIL PROTECTED] wrote: On Sun, 6 Feb 2005, Richard Stellingwerff wrote: On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dänzer [EMAIL PROTECTED] wrote: Does it also happen without either or all of the options in the radeon device section? I just removed the AGPFastWrite and DynamicClocks options. The crashes still happen though. Looks like not only I have problems with the radeon driver. I update the X.org, drm, Mesa CVS once a week, but haven't found a working combination since 4-5 months... I don't intend to start a flame-war, but is there anybody who can use the r200 driver without X crashes? I'm testing X.org CVS regularly (almost on every weekend) with my RV280, with the latest linux 2.6 kernel. I checked out X.org on last Saturday, played with Descent3 for some minutes, it didn't crashed. Good. Restarted X, started Descent3 again, it crashed almost immediately, as expected :(( That's why I have a 'shutdown -r 5' in the background, when I test X.org CVS... Compiled Mesa CVS, installed the libraries and the driver, started D3. (Descent3 looks great, textures are visible, thanks to Eric Anholt's projected texture patch which is in Mesa CVS) The game crashed X in a few seconds. This was expected too :(( I tried out other OpenGL-based games, unfortunately, I can crash X with almost every game I have - it is only a matter of time. I tried setting color depth to 16 bit, changed the AGP to 1x in the system BIOS, none of these helped. Last time I used the 2.6.11-rc3 linux kernel, X.org CVS (updated on 20050205), Mesa CVS (20050205, linux-x86-dri target). I didn't built the drm module, I used the kernel's radeon drm module. I used to test the drm compiled from the CVS version, but I found out, that it is only a matter of time to crash the X server, so I skipped the drm CVS test. Of course the real tests will be these: 1. build and install everything from CVS, if the X server can be crashed, go to step 2, otherwise be happy :)) 2. use the X.org CVS version with the stock kernel's drm, if X still crashes, go to step 3. Otherwise use the X.org CVS, live without projected textures... 3. use the X.org and Mesa CVS versions. If X still crashes, then the bug can be in X.org or Mesa or in drm - I'm not able to trace down the problem. Unfortunately all 3 scenarios give the same result: X crashes. Is there any way I can help to track down the problem(s)? My machine doesn't have network connection, so I can use only scripts which run in the background. With expect and gdb maybe it is possible to get at least a backtrace from my non-local-interactive machine. Regards, Geller Sandor [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 on PPC problem
Hi ! An interesting issue with current X.org CVS and current Linux bk is that on r300, the DRI module now loads, and 2D is broken. It looks like an endian issue (like pixels are horizontally flipped), I can post a snapshot later I suppose. Preventing the kernel module from loading fixes it, so I suspect it's an issue with the 2D CCE accel for r300. Is this a known problem ? Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
On Monday 07 February 2005 15:33, Felix K=FChling wrote: Am Montag, den 07.02.2005, 15:12 +0100 schrieb=20 [EMAIL PROTECTED]: Hardware: Toshiba Libretto L2 Tm5600 with: :00:04.0 VGA compatible controller: S3 Inc. 86C270-294=3D20 Savage/IX-MV (rev 13) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device 0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=3D Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=3D3Dmedium TAbort- =3D TAbort- MAbort- SERR- PERR- Latency: 248 (1000ns min, 63750ns max), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=3D3D128=3D M] Expansion ROM at 000c [disabled] [size=3D3D64K] Capabilities: available only to root Software: Gentoo current with Gentoo supplied X Window System Version 6.8.1.903 (6.8.=3D 2 RC 3) Release Date: 25 January 2005 X Protocol Version 11, Revision 0, Release 6.8.1.903 Build Operating System: Linux 2.4.29-rc3-mhf239 i686 [ELF]=3D20 Current Operating System: Linux mhfl4 2.4.29-rc3-mhf239 #2 Tue Jan 18 17:43=3D :33 CET 2005 i686 Build Date: 05 February 2005 Installed snapshot from savage-20050205-linux.i386.tar.bz2. On starting X: [snip] So, driver in snapshot still reports 1.0. Seems to be quite old (2001). The new Savage DRM 2.0.0 (in fact 2.2.0 by now) is only available for Linux 2.6.=20 Tested with 2.6.11-rc3. DRM functional with glxgears. tuxkart and tuxracer work most the time but sometimes=20 painting occurs outside of games window. Parts of the image=20 appear (sometime mirrored) outside game window or random=20 patterns appear. Cursor and numeric display in game window=20 appear as random patterns. Sometimes above games mess up the screen but restart Game a=20 few times fixes it. =46lighgear messes up the entire screen and would never work. BTW, the games work on i810 HW with 2.6.11-rc3. Since Linux 2.4 is no longer=20 open for new features there is not much point back-porting it to Linux 2.4.=20 See=20 http://dri.freedesktop.org/wiki/S3Savage for more information about the savage driver status. I just added a note about Linux 2.4 to that page. Sorry, have not found any reference to 2.4 being unsupported=20 on that page.=20 Are there any test programs available to systematically test=20 DRM/GL functionality? Regards Michael --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
