Bug 788 - Display Artifacts at 1680x1050
Display Artifacts at 1680x1050
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: General
DRI git
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-21 15:07 UTC by sth
Modified: 2005-03-07 20:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Fix (1.65 KB, patch)
2004-06-21 17:51 UTC, Michel Dänzer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description sth 2004-06-21 15:07:57 UTC
(pasted together from some IRC snippets) 
 
There's a bug in the r200 driver when using >1600 pixels wide resolutions. 
See http://steffen-hein.de/misc/images/r200-dri-bug-1680.jpg 
On the left and right side - these areas only get partly updated 
 
q3 screen-mode: 
PIXELFORMAT: color(32-bits) Z(24-bit) stencil(8-bits) 
MODE: -1, 1680 x 1050 fullscreen hz:N/A 
GAMMA: hardware w/ 0 overbright bits 
 
<MrCooper> sth_: what does 'grep pitch /var/log/XFree86.0.log' say? 
<sth_> (--) RADEON(0): Virtual size is 1680x1050 (pitch 1680) 
<MrCooper> sth_: the depth buffer pitch may be invalid 
<MrCooper> sth_: it must be a multiple of 32 pixels, but it looks like the 
radeon 2D driver just takes the colour buffer pitch
Comment 1 sth 2004-06-21 15:41:26 UTC
<MrCooper> sth_: so, can you try rounding up the depth pitch to a multiple of 
32 pixels? (or maybe using a multiple of 32 horizontal width for a start) 
<MrCooper> sth_: I mean virtual width of course 
<sth_> MrCooper: Setting the XServer virtual resolution to something like 
1696? 
<MrCooper> sth_: exactly 
 
I added Virtual 1696 1050 to my XF86Config-4, restarted X11 and the problem 
disappeared. 
 
Comment 2 Michel Dänzer 2004-06-21 17:51:45 UTC
Created attachment 402 [details] [review]
Fix

I committed this patch to DRI CVS to fix the problem. Thanks for the report.
Comment 3 Michel Dänzer 2004-06-21 17:52:51 UTC
Fixed in DRI CVS.
Comment 4 Alex Deucher 2004-06-22 07:07:20 UTC
we should probably apply this to xorg cvs as well...
Comment 5 Mike A. Harris 2005-03-06 06:08:10 UTC
Reopening this, because it says "we should probably apply to xorg
CVS also" but no indication of wether that ever happened or not.
Comment 6 Mike A. Harris 2005-03-06 06:11:12 UTC
Comment on attachment 402 [details] [review]
Fix

Adding to 6.8.x approval request queue.
Comment 7 Michel Dänzer 2005-03-06 08:25:38 UTC
Comment on attachment 402 [details] [review]
Fix

DRI CVS was merged into X.org CVS a long time ago... this fix is on the 6.8
branch, as a little investigation would have shown.

However, it looks like this case might have been overlooked when support for
colour tiling was added on HEAD, Roland?
Comment 8 Michel Dänzer 2005-03-06 08:51:20 UTC
(In reply to comment #7)
> 
> However, it looks like this case might have been overlooked when support for
> colour tiling was added on HEAD, Roland?

Oops, this might be ambiguous... I mean Roland Scheidegger.
Comment 9 Roland Scheidegger 2005-03-06 14:30:54 UTC
I removed that since for color tiling displayWidth must be a multiple of 256
bytes (i.e. 64 pixels minimum at 32bpp, 128 pixels for 16bpp). Then I discovered
even without color tiling the requested pitchInc for mode validation is 64 *
pScrn->bitsPerPixel, i.e. 64 pixels too, so the additional check for z tiling
alignment is unnecessary. At least I think that is what this code does...
Comment 10 Michel Dänzer 2005-03-06 18:37:16 UTC
(In reply to comment #9)
> Then I discovered even without color tiling the requested pitchInc for mode
> validation is 64 * pScrn->bitsPerPixel, i.e. 64 pixels too, so the additional
> check for z tiling alignment is unnecessary.

That's only true for the cases when xf86ValidateModes() is used AFAICT.
Comment 11 Roland Scheidegger 2005-03-07 11:40:37 UTC
Are not all modes validated? If not at least color tiling would not work in
these cases. Or does mode validation not happen if you use fbdev? In that case
the check needs to be added back.
Comment 12 Michel Dänzer 2005-03-07 19:07:32 UTC
(In reply to comment #11)
> Are not all modes validated?

They are, but the radeon driver doesn't use xf86ValidateModes() in all cases but
has some of its own validation functions. Even when xf86ValidateModes() is used,
I'm not sure how it interacts with virtual resolutions e.g.? Have you tried
1680x1050 virtual resolution?
Comment 13 Roland Scheidegger 2005-03-08 07:40:58 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Are not all modes validated?
> 
> They are, but the radeon driver doesn't use xf86ValidateModes() in all cases but
> has some of its own validation functions.
I think they ALL call xf86ValidateModes though.

> Even when xf86ValidateModes() is used,
> I'm not sure how it interacts with virtual resolutions e.g.?
I believe that actually _only_ virtual resolutions are validated.

> Have you tried 1680x1050 virtual resolution?
I have tried virtual resolutions slightly larger than 1280x1024 (e.g. 1288x1024)
 they all result in a pitch of 1344, without problems.
However, I have also tried the same with UseFBDev, the indicated pitch was still
1344, but the results inconclusive to that specific problem, since the screen in
2d was a garbled mess anyway. All virtual resolutions which do not have a pitch
of 64 pixels simply do not work, maybe the modes used by fbdev and the modes
which xorg thinks get used (as per mode validation) are not quite the same or
something like that.

Comment 14 Roland Scheidegger 2005-03-08 08:04:50 UTC
(> > They are, but the radeon driver doesn't use xf86ValidateModes() in all
cases but
> > has some of its own validation functions.
> I think they ALL call xf86ValidateModes though.
Argh, that's apparently not true. This is sick, there are two dozens different
validation routines, and they don't validate all the same things.
So, I'll add that check back.
However, these modes which are not going through the xf86ValidateModes validator
and are thus not tested for a "valid" pitchInc are not going to work with color
tiling. Since the pitchInc is 64 pixels even without color tiling, I'm wondering
why those work at all?
Comment 15 Michel Dänzer 2005-03-08 09:01:53 UTC
Ignoring tiling, the strictest restriction for the pitch I can find in the specs
is that it has to be a multiple of 64 bytes (I think even multiples of 32 should
work, but the dedicated pitch registers (as opposed to the combined offset/pitch
ones) probably need to be used for that). Where do the 64 pixels come from?
Comment 16 Roland Scheidegger 2005-03-08 14:14:23 UTC
(In reply to comment #15)
> Ignoring tiling, the strictest restriction for the pitch I can find in the specs
> is that it has to be a multiple of 64 bytes (I think even multiples of 32 should
> work, but the dedicated pitch registers (as opposed to the combined offset/pitch
> ones) probably need to be used for that). Where do the 64 pixels come from?
That's a very good question. No idea. Those validatemode functions which do not
call xf86ValidateModes in fact only request a pitch of 64bytes (for 32bit and
16bit) and 128bytes (for 8bit modes). And in fact, I _did_ adjust this
RadeonSetPitch function to work correctly with color tiling, so this ought to
work (phew!). This only leaves the original problem (e.g. without color tiling,
depth pitch must be adjusted). I'll fix that in a minute. Maybe the requested
pitchInc for xf86ValidateModes is indeed more restrictive than necessary, but
I'm certainly not going to touch that...
Comment 17 Roland Scheidegger 2005-03-08 15:43:50 UTC
fixed in xorg cvs head.