Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Alex Deucher]

On 6/21/05, Aapo Tahkola [EMAIL PROTECTED] wrote:
 On Thu, 16 Jun 2005 14:22:36 +0200
 Nicolai Haehnle [EMAIL PROTECTED] wrote:
 
  On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
   Update of /cvsroot/r300/r300_driver/r300
   In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
  
   Modified Files:
   r300_reg.h r300_state.c
   Log Message:
   Use depth tiling.
 
  Will this work with software fallbacks?
 
 Im not quite sure but more recent r200_span.c has few words about it.
 Attached patch enables color tiling in case someone wants to play with it.
 
 --
 Aapo Tahkola
 
 
 

I've done some looking into tiling on r3/4xx hardware, and this patch
isn't quite right.  this works as long as the offset is 0, however, if
you adjust the frame certain offsets don't work.  they actually made
tiling work much easier on r3/4xx hardware.  when tiling is enabled,
crtc_offset is used to hold the address of the surface and a new
x_y_tile reg is used for the actual offset.  all you need to do is
plug in the x and y values and the hardware takes care of the rest, no
moer complicated tile address calculations.

Here's the working version of doadjustframe() (to be used in
conjunction with your patch:
void RADEONDoAdjustFrame(ScrnInfoPtr pScrn, int x, int y, int clone)
{
RADEONInfoPtr  info   = RADEONPTR(pScrn);
unsigned char *RADEONMMIO = info-MMIO;
intreg, Base, regcntl, crtcoffsetcntl, xytilereg, crtcxytile;
#ifdef XF86DRI
RADEONSAREAPrivPtr pSAREAPriv;
XF86DRISAREAPtr pSAREA;
#endif

Base = pScrn-fbOffset;

  /* note we cannot really simply use the
info-ModeReg.crtc_offset_cntl value, since the
 drm might have set FLIP_CNTL since we wrote that. Unfortunately
FLIP_CNTL causes
 flickering when scrolling vertically in a virtual screen,
possibly because crtc will
 pick up the new offset value at the end of each scanline, but the
new offset_cntl value
 only after a vsync. We'd probably need to wait (in drm) for vsync
and only then update
 OFFSET and OFFSET_CNTL, if the y coord has changed. Seems hard to fix. */
if (clone || info-IsSecondary) {
reg = RADEON_CRTC2_OFFSET;
regcntl = RADEON_CRTC2_OFFSET_CNTL;
xytilereg = R300_CRTC2_TILE_X0_Y0;
} else {
reg = RADEON_CRTC_OFFSET;
regcntl = RADEON_CRTC_OFFSET_CNTL;
xytilereg = R300_CRTC_TILE_X0_Y0;
}
crtcoffsetcntl = INREG(regcntl)  ~0xf;

/* try to get rid of flickering when scrolling at least for 2d */
#ifdef XF86DRI
if (!info-have3DWindows)
#endif
crtcoffsetcntl = ~RADEON_CRTC_OFFSET_FLIP_CNTL;
if (info-tilingEnabled) {
if (IS_R300_VARIANT) {
/* On r300/r400 when tiling is enabled crtc_offset is set to the 
address of
 * the surface.  the x/y offsets are handled by the X_Y tile reg for 
each crtc
 * Makes tiling MUCH easier.
 */
crtcxytile = x | (y  16);
Base = ~0x7ff;
} else {
int byteshift = info-CurrentLayout.bitsPerPixel  4;
/* crtc uses 256(bytes)x8 half-tile start addresses? */
int tile_addr = (((y  3) * info-CurrentLayout.displayWidth +
x)  (8 - byteshift))  11;
Base += tile_addr + ((x  byteshift) % 256) + ((y % 8)  8);
crtcoffsetcntl = crtcoffsetcntl | (y % 16);
}
}
else {
   Base += y * info-CurrentLayout.displayWidth + x;
   switch (info-CurrentLayout.pixel_code) {
   case 15:
   case 16: Base *= 2; break;
   case 24: Base *= 3; break;
   case 32: Base *= 4; break;
   }
}

Base = ~7; /* 3 lower bits are always 0 */

#ifdef XF86DRI
if (info-directRenderingEnabled) {
/* note cannot use pScrn-pScreen since this is unitialized when called 
from
   RADEONScreenInit, and we need to call from there to get mergedfb +
pageflip working */
pSAREAPriv = DRIGetSAREAPrivate(screenInfo.screens[pScrn-scrnIndex]);
/* can't get at sarea in a semi-sane way? */
pSAREA = (void *)((char*)pSAREAPriv - sizeof(XF86DRISAREARec));

if (clone || info-IsSecondary) {
pSAREAPriv-crtc2_base = Base;
}
else {
pSAREA-frame.x = (Base  / info-CurrentLayout.pixel_bytes)
% info-CurrentLayout.displayWidth;
pSAREA-frame.y = (Base / info-CurrentLayout.pixel_bytes)
/ info-CurrentLayout.displayWidth;
pSAREA-frame.width = pScrn-frameX1 - x + 1;
pSAREA-frame.height = pScrn-frameY1 - y + 1;
}

if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
}
}
#endif

OUTREG(reg, Base);

if (IS_R300_VARIANT) {
OUTREG(xytilereg, crtcxytile);
} else {
OUTREG(regcntl, crtcoffsetcntl);
}

}

And here are the relevant new bitfields:

#define RADEON_CRTC_OFFSET_CNTL 0x0228
#   define RADEON_CRTC_TILE_LINE_SHIFT  0
# 

Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Aapo Tahkola]

On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:

 On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
  Update of /cvsroot/r300/r300_driver/r300
  In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
  
  Modified Files:
  r300_reg.h r300_state.c 
  Log Message:
  Use depth tiling.
 
 Will this work with software fallbacks?

Im not quite sure but more recent r200_span.c has few words about it.
Attached patch enables color tiling in case someone wants to play with it.

-- 
Aapo Tahkola
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Tue Jun 21 18:13:31 2005
@@ -4745,10 +4745,6 @@
xf86DrvMsg(pScrn-scrnIndex, X_INFO, Color tiling disabled for 2nd 
head\n);
info-allowColorTiling = FALSE;
 }
-else if ((info-allowColorTiling)  (info-ChipFamily = 
CHIP_FAMILY_R300)) {
-   xf86DrvMsg(pScrn-scrnIndex, X_INFO, Color tiling disabled for r300 
and newer chips\n);
-   info-allowColorTiling = FALSE;
-}
 else if ((info-allowColorTiling)  (info-FBDev)) {
xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
   Color tiling not supported with UseFBDev option\n);
@@ -5631,6 +5627,11 @@
 if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
 
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+   unsigned char *RADEONMMIO = info-MMIO;
+   OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
 if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
@@ -6133,7 +6134,12 @@
drmRadeonSurfaceAlloc drmsurfalloc;
drmsurfalloc.size = bufferSize;
drmsurfalloc.address = info-frontOffset;
-   drmsurfalloc.flags = swap_pattern | (width_bytes / 16) | 
color_pattern;
+
+   if (IS_R300_VARIANT)
+   drmsurfalloc.flags = swap_pattern | (width_bytes / 8) | 
color_pattern;
+   else
+   drmsurfalloc.flags = swap_pattern | (width_bytes / 16) | 
color_pattern;
+
retvalue = drmCommandWrite(info-drmFD, DRM_RADEON_SURF_ALLOC,
drmsurfalloc, sizeof(drmsurfalloc));
if (retvalue  0)
@@ -6172,7 +6178,10 @@
/* we don't need anything like WaitForFifo, no? */
if (!info-IsSecondary) {
if (info-tilingEnabled) {
-   surf_info = swap_pattern | (width_bytes / 16) | color_pattern;
+   if (IS_R300_VARIANT)
+  surf_info = swap_pattern | (width_bytes / 8) | color_pattern;
+   else
+  surf_info = swap_pattern | (width_bytes / 16) | 
color_pattern;
}
OUTREG(RADEON_SURFACE0_INFO, surf_info);
OUTREG(RADEON_SURFACE0_LOWER_BOUND, 0);
@@ -7088,10 +7097,16 @@
 save-crtc_offset  = 0;
 save-crtc_offset_cntl = INREG(RADEON_CRTC_OFFSET_CNTL);
 if (info-tilingEnabled) {
-   save-crtc_offset_cntl |= RADEON_CRTC_TILE_EN;
+   if (IS_R300_VARIANT)
+  save-crtc_offset_cntl |= 0x8e00;
+   else
+  save-crtc_offset_cntl |= RADEON_CRTC_TILE_EN;
 }
 else {
-   save-crtc_offset_cntl = ~RADEON_CRTC_TILE_EN;
+   if (IS_R300_VARIANT)
+  save-crtc_offset_cntl = ~0x8e00;
+   else
+  save-crtc_offset_cntl = ~RADEON_CRTC_TILE_EN;
 }
 
 save-crtc_pitch  = (((pScrn-displayWidth * pScrn-bitsPerPixel) +
@@ -7273,10 +7288,16 @@
 save-crtc2_offset  = 0;
 save-crtc2_offset_cntl = INREG(RADEON_CRTC2_OFFSET_CNTL)  
RADEON_CRTC_OFFSET_FLIP_CNTL;
 if (info-tilingEnabled) {
-   save-crtc2_offset_cntl |= RADEON_CRTC_TILE_EN;
+   if (IS_R300_VARIANT)
+  save-crtc2_offset_cntl |= 0x8e00;
+   else
+  save-crtc2_offset_cntl |= RADEON_CRTC_TILE_EN;
 }
 else {
-   save-crtc2_offset_cntl = ~RADEON_CRTC_TILE_EN;
+   if (IS_R300_VARIANT)
+  save-crtc2_offset_cntl = ~0x8e00;
+   else
+  save-crtc2_offset_cntl = ~RADEON_CRTC_TILE_EN;
 }
 
 /* this should be right */

Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Nicolai Haehnle]

On Tuesday 21 June 2005 18:06, Aapo Tahkola wrote:
 On Thu, 16 Jun 2005 14:22:36 +0200
 Nicolai Haehnle [EMAIL PROTECTED] wrote:
 
  On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
   Update of /cvsroot/r300/r300_driver/r300
   In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
   
   Modified Files:
r300_reg.h r300_state.c 
   Log Message:
   Use depth tiling.
  
  Will this work with software fallbacks?
 
 Im not quite sure but more recent r200_span.c has few words about it.
 Attached patch enables color tiling in case someone wants to play with it.

You *will* have to update radeon_span.c accordingly. I haven't looked into 
how this surface business works, that might help a bit, but I doubt you get 
away without changing anything in radeon_span.c

In fact, enabling the depth tiling did break software fallbacks, which 
includes depth readbacks. So stuff like glean and Cube (which uses depth 
readback to figure out your line of fire) is broken with depth tiling, 
which is why I backed that change out.

We really, really need a working fallback path. I can't stress this enough.

cu,
Nicolai


pgpmdHNtAmguB.pgp
Description: PGP signature

Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Rune Petersen]

Aapo Tahkola wrote:

On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:



On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:


Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333

Modified Files:
	r300_reg.h r300_state.c 
Log Message:

Use depth tiling.


Will this work with software fallbacks?




*snip*

+if (info-ChipFamily = CHIP_FAMILY_R300) {
+   unsigned char *RADEONMMIO = info-MMIO;
+   OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+

0x180 is defined as R300_MC_INIT_MISC_LAT_TIME in r300_reg.h.
This seams unrelated to tiling. Also I remember seeing that the values 
are different depending on chip family. Is this safe?



Rune Petersen


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Nicolai Haehnle]

On Tuesday 21 June 2005 21:15, Rune Petersen wrote:
 Aapo Tahkola wrote:
 *snip*
  +if (info-ChipFamily = CHIP_FAMILY_R300) {
  + unsigned char *RADEONMMIO = info-MMIO;
  + OUTREG(0x180, INREG(0x180) | 0x1100);
  +}
  +
 0x180 is defined as R300_MC_INIT_MISC_LAT_TIME in r300_reg.h.
 This seams unrelated to tiling. 

I agree that
a) the appropriate #defines should be added in the 2D driver instead of 
putting magic values everywhere when we can do better and
b) this should be split out into a different patch (note that you can do 
this kind of splitting with a simple editor; you just have to make sure 
that you do not modify the patch chunks themselves, be especially with the 
whitespace)

 Also I remember seeing that the values  
 are different depending on chip family. Is this safe?

Well, I have tested this on three different chips (R300, rv350 (mobile) and 
R420, which is quite a nice sample), and:
- fglrx sets this on all the chips and
- setting it in our driver caused no regressions.

Of course, it would be even better if people could test it on their hardware 
(use hw_script from r300 CVS to query the register value while fglrx is 
running, as well as test the patch).

cu,
Nicolai


pgp66TLxvo7vs.pgp
Description: PGP signature

Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Nicolai Haehnle]

On Wednesday 22 June 2005 03:09, Rune Petersen wrote:
 Nicolai Haehnle wrote:
 Also I remember seeing that the values  
 are different depending on chip family. Is this safe?
  
  
  Well, I have tested this on three different chips (R300, rv350 (mobile) 
and 
  R420, which is quite a nice sample), and:
  - fglrx sets this on all the chips and
  - setting it in our driver caused no regressions.
  
  Of course, it would be even better if people could test it on their 
hardware 
  (use hw_script from r300 CVS to query the register value while fglrx is 
  running, as well as test the patch).
  
 I just had a quick try, it doesn't seam to cause any regressions.
 Am I right in assuming that it should reduce lockups on Radeon 9800?

No. At least it didn't for me, and it didn't help for Jerome either if I 
recall correctly.

However, it apparently fixes some display issues (white horizontal lines?) 
that some people were seeing.

cu,
Nicolai


pgpbVIuyR9kTA.pgp
Description: PGP signature

Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113

[Nicolai Haehnle]

On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
 Update of /cvsroot/r300/r300_driver/r300
 In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
 
 Modified Files:
   r300_reg.h r300_state.c 
 Log Message:
 Use depth tiling.

Will this work with software fallbacks?

cu,
Nicolai


pgpV14VXQ7uoa.pgp
Description: PGP signature