Bug 27339

Summary:	Problem with stale cliprects from the classic r300 in r300g
Product:	Mesa	Reporter:	Mathias Fröhlich <Mathias.Froehlich>
Component:	Drivers/DRI/r300	Assignee:	Default DRI bug account <dri-devel>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Mathias Fröhlich 2010-03-27 00:09:26 UTC

Hi,

When using the classic r300 driver together with r300g in the same session, the cliprect registers used to clip the viewport in classic r300 seem to bleed into the r300g environment.
The problem I observe is that when I start an application with the classic r300 driver and stop that  application. Then switch to the r300g driver by setting the LIBGL_DRIVERS_PATH environment variable, the r300g context is always clipped to the viewport of the previous classic r300 viewport.
This happens on my mesa test account which uses non composited X11 on rawhide.

The attached patch fixes this by initializing these clip rects on context startup.
I am not sure which registers should be initialized by which different component, which means I am not sure if this is the right place to fix this. But I provide that here as a hopefully good hint what goes wrong.

Please fix

Mathias

Comment 1 Marek Olšák 2010-03-27 06:57:58 UTC

I think the classic driver shouldn't set those regs on KMS. Some time ago I removed the emission of the regs in classic and it didn't really add any regressions.

Please try this:
Change src/gallium/drivers/r300/r300_state_invariant.c:134 to:

    OUT_CS_REG(R300_SC_CLIP_RULE, 0);

and please let me know if it helps.

Comment 2 Mathias Fröhlich 2010-03-27 08:07:58 UTC

(In reply to comment #1)
> I think the classic driver shouldn't set those regs on KMS. Some time ago I
> removed the emission of the regs in classic and it didn't really add any
> regressions.

Hmm, looking again deeper into the code I just observed that r300 used R300_CLIPRECT* to do scissor clipping to viewport boundaries whereas r300g uses R300_SCISSOR*.

> Please try this:
> Change src/gallium/drivers/r300/r300_state_invariant.c:134 to:
> 
>     OUT_CS_REG(R300_SC_CLIP_RULE, 0);
> 
> and please let me know if it helps.
> 
I have reverted to master and applied that change but:
That does not help.
With that change the whole window is not painted at all - you just see stale buffer content.
I believe that this value is some kind of bitmask to tell the card which side of the R300_CLIPRECT* coordinate to clip away.
It appeared to me that you can not easily switch those off, rather than just 'clip the other side'. ... not looked into the documentation.

Don't know if r300 should or should not use these registers, but it seems to me that r300 just still uses them as well as the kms kernel lets r300 classic set those registers.

So altogether It would be good to have something that helps testing r300g as an alternative to r300 classic in an easy way.

Greetings

Mathias

Comment 3 Marek Olšák 2010-03-27 09:09:45 UTC

Could you please give me the exact steps how to reproduce this bug?

Comment 4 Nicolai Hähnle 2010-03-27 14:19:18 UTC

Clipping works like this:

You have four cliprects. Each pixel is compared to all of them. The pass/fail result gives you a bitmask which is interpreted as a number N between 0 and 15 (inclusive). Then you look at the N-th bit of the clip rule register. If it is 1, continue, if it is 0, discard the pixel.

Therefore, you need to set the clip rule register to 0xFFFF to disable this clipping functionality.

Comment 5 Marek Olšák 2010-03-27 14:49:00 UTC

Thanks Nicolai! I knew it would be either all zeros or all ones.. ;) I've pushed the fix to master.

I am closing the bug. Please reopen if it still regresses.

Comment 6 Mathias Fröhlich 2010-03-28 00:34:50 UTC

Works with your checkin.
Thanks!

Mathias

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.