/* set scissor to the first clip box*/
If GL_SCISSOR_TEST is off, this has no effect. If GL_SCISSOR_TEST is on,
it overrides the applications scissor and also causes incorrect
clipping because savageDDScissor takes coordinates that are drawable
relative (like glScissor), not screen relative like the clip rects.
There seems to be quite a lot of rotted code around clipping in the
savage driver; I'm still trying to figure out how things are supposed
to work and what the correct fix is.
Here's some further results from my investigation:
- In general, the savage driver *is not clipping* primitives.
This means that drawing to the front buffer is not clipped properly,
and multiple clients drawing to overlapping areas in the back buffer
can also interfere.
- Even if you ignore the above, just commenting out the stray scissoring call
doesn't completely get scissoring working - it doesn't respond properly
to moving the window. This should be easy to fix.
- I'm not sure if the savage hardware supports more than a single
scissor rectangle. The algorithm used by the i810, unichrome,
etc, drivers for clipping primitives by drawing them repeatedly in
chunks of the number of supported clip rectangles would work with
only one clip rectangle, but could be really inefficient, if you
say, overlapped 'xeyes' over the window
- As noted above, there is a lot of rotted code around clipping. I think
the right approach would either to be;
A) Accept that we can't clip on the savage, remove all the
B) Implement the standard draw-repeatedly algorithm referencing
one of the other drivers using a single clip rectangle. If more
powerful hardware clip facilities come to light, it should be
easy to adapt.
I tend to think B) is right, if moving xeyes over your GL window slows
things to a crawl, move xeyes off.
Note that I'm not promising to do the above work, just writing down the
results of my investigation.
(In reply to comment #0)
> There seems to be quite a lot of rotted code around clipping in the
> savage driver; I'm still trying to figure out how things are supposed
> to work and what the correct fix is.
You're right, clipping has never worked correctly in the Savage driver. I didn't
bother fixing it so far since I was going to rewrite the code that sends
vertices to the hardware to use DMA buffers. In fact I'm starting to work on it
now. Eventually I'll get down to the clipping issues and fix them.
Created attachment 1189 [details] [review]
Fix scissoring, ignore window clipping
Ignoring the clip-list issues, the attached patch seems to get scissoring
working right for me. It handles changing the hardware scissor rectangle
when the window is moved, and when scissoring is enabled/disabled.
It might be useful in the short term, though if you are working on redoing
vertex emission and clipping now, there may be no point.
(In reply to comment #3)
> Created an attachment (id=1189) 
> Fix scissoring, ignore window clipping
Oops, I never took a closer look at this patch. Anyway, I believe the clipping
and scissoring issues are fixed in latest CVS. Could you confirm this with
whatever application you were testing your patch?
Unfortunately, the current code locks my machine solid as soon as it
tries to render anything.(glxinfo info works but no more.) I want to
try and debug that, but it is going to involve getting together:
- An environment with more than one machine
The code in CVS doesn't *look* right to me ... it's still saving
the scissor in screen coordinates, and doesn't seem to update it
on window move. But I could be missing something.
(In reply to comment #5)
> Unfortunately, the current code locks my machine solid as soon as it
> tries to render anything.(glxinfo info works but no more.) I want to
> try and debug that, but it is going to involve getting together:
make sure you enable "shadowstatus" in your config.
OK, tested with vdma off which works around the lockup and as expected there
still are some residual problems with moving windows ... try adding
glScissor (20, 20, 100, 100);
to init() in Mesa/progs/redbook/hello.c and you'll see that the scissor doesn't
move with the window.
Seems the easiest fix would just to create a temporary rectangle to
pass to savageIntersectClipRects in savageFlushCmdBufLocked from
ctx->Scissor and the current window position. There also looks like there
is a lot of dead code in savage_state.c about scissoring that could be
I did some cleanup of the scissors code and removed some dead code. It passes
the glean scissor test now as well as your patched hello.c. I'm closing this bug
now. If you find something else scissor-related feel free to reopen it.
Mass version move, cvs -> git
on Mar 25, 2017 at 03:51:22.
(provided by the Example extension).