Finishing up renderbuffer changes in DRI drivers

I'm trying to tie up some loose ends from the 
GL_EXT_framebuffer_object work I did a while back.

I previously updated the span functions so they'd take a 
gl_renderbuffer pointer and now I'm making the code actually use that 
parameter.  The idea is to use the fields of the gl_renderbuffer 
parameter to determine where to read/write the pixels, instead of 
using per-context state which is set in the SetBuffer routine.

I'm checking in the updated radeon and r200 drivers and I'll do the 
mach64 and r128 drivers next.  I've tested the radeon changes, but not 
the r200.  If someone could run the reflect demo on r200 and use the 
a/s/d/f/c keys to exercise the span routines, that would be good.  The 
readpix and singlebuffer demos are good tests too.

In the r200 code, I've left in the old code surrounded by #ifdef 000 / 
#endif to make it obvious what I changed.  I'll remove the #ifdef 000 
code later.  It would be nice if other driver maintainers could take a 
look and carry over the changes.

The basic idea is to:
1. Remove the SetBuffer() routine.
2. In the span routines, cast the gl_renderbuffer pointer into a 
driRenderbuffer pointer and use its offset/pitch/cpp fields instead of 
the per-context offset/pitch/cpp fields.
3. Clean-up other code related to offset/pitch/cpp elsewhere as needed.

After this is done, I can remove a bunch of unneeded code from the 
swrast module.

[Bug 4331] New: 16 Bits per Channel Compile on GL_EXT_texture_compression_fxt1

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=4331          

           Summary: 16 Bits per Channel Compile on
                    GL_EXT_texture_compression_fxt1
           Product: Mesa
           Version: CVS
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: roy.walmsley <at> chemringcm.com

I set CHAN_BITS to 16 in config.h. Then using MSVC6 I compiled the mesa 
project. On compilation there were 11 warnings of which 9 related to the 
summary above. I will detail the first one - the next 3 are similar.

On line 180 of file texcompress_fxt1.c there is a function call to 
fxt1_decode_1. The last arguments, texel, is a GLchan *, which due to my 
setting of CHAN_BITS, is typedef'd to unsigned short *. However, in the 
function declaration on line 49 and definition on line 1638 of the same file 
the final argument rgba is defined as GLubyte *. These types are therefore 
incompatible.

Re: Finishing up renderbuffer changes in DRI drivers

Brian Paul wrote:
> I'm checking in the updated radeon and r200 drivers and I'll do the 
> mach64 and r128 drivers next.  I've tested the radeon changes, but not 
> the r200.  If someone could run the reflect demo on r200 and use the 
> a/s/d/f/c keys to exercise the span routines, that would be good.  The 
> readpix and singlebuffer demos are good tests too.

It looks like some r200_screen.c changes got missing. After patching 
that, it still doesn't quite work correctly.

- Pageflipping is completely broken. Looks like stuff gets drawn to the 
right place only every second frame or something like that (i.e. heavy 
flicker).

- Without pageflip, reflect partly works. a/d/f/c look good (though c 
looks the same as f), but s is hosed beyond recognition. readpix works, 
as does zreaddraw and singlebuffer.

Roland

Index: r200_screen.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_screen.c,v
retrieving revision 1.44
diff -u -r1.44 r200_screen.c
--- r200_screen.c	15 Aug 2005 06:59:25 -0000	1.44
+++ r200_screen.c	1 Sep 2005 13:25:19 -0000
 <at>  <at>  -173,7 +173,7  <at>  <at> 

Re: Finishing up renderbuffer changes in DRI drivers

Brian Paul wrote:
> I'm checking in the updated radeon and r200 drivers and I'll do the 
> mach64 and r128 drivers next.  I've tested the radeon changes, but not 
> the r200.  If someone could run the reflect demo on r200 and use the 
> a/s/d/f/c keys to exercise the span routines, that would be good.  The 
> readpix and singlebuffer demos are good tests too.

It looks like some r200_screen.c changes got missing. After patching
that, it still doesn't quite work correctly.

- Pageflipping is completely broken. Looks like stuff gets drawn to the
right place only every second frame or something like that (i.e. heavy
flicker).

- Without pageflip, reflect partly works. a/d/f/c look good (though c
looks the same as f), but s is hosed beyond recognition. readpix works,
as does zreaddraw and singlebuffer.

I should add, that stencilbuffer problem only exists with color tiling. 
It works without color tiling.

Roland

Index: r200_screen.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_screen.c,v
retrieving revision 1.44
diff -u -r1.44 r200_screen.c
--- r200_screen.c	15 Aug 2005 06:59:25 -0000	1.44

Re: Finishing up renderbuffer changes in DRI drivers

Roland Scheidegger wrote:
> Brian Paul wrote:
> 
>> I'm checking in the updated radeon and r200 drivers and I'll do the 
>> mach64 and r128 drivers next.  I've tested the radeon changes, but not 
>> the r200.  If someone could run the reflect demo on r200 and use the 
>> a/s/d/f/c keys to exercise the span routines, that would be good.  The 
>> readpix and singlebuffer demos are good tests too.
> 
> 
> It looks like some r200_screen.c changes got missing. After patching 
> that, it still doesn't quite work correctly.
> 
> - Pageflipping is completely broken. Looks like stuff gets drawn to the 
> right place only every second frame or something like that (i.e. heavy 
> flicker).

What's the trick for enabling/testing page flipping?  I thought I had 
it going with the radeon, but I guess not.

> - Without pageflip, reflect partly works. a/d/f/c look good (though c 
> looks the same as f), but s is hosed beyond recognition. readpix works, 
> as does zreaddraw and singlebuffer.

's' should show a white quad for the 'table' surface representing the 
stencil buffer values.  'f' toggles front/back rendering - it'll look 
flickery and especially so when using a/s/d to show the alpha channel, 
stencil buffer or depth buffer.

Can you check if 's' worked before I changed the driver?

Re: Re: Finishing up renderbuffer changes in DRI drivers

Brian Paul wrote:
>> - Pageflipping is completely broken. Looks like stuff gets drawn to 
>> the right place only every second frame or something like that (i.e. 
>> heavy flicker).
> 
> 
> What's the trick for enabling/testing page flipping?  I thought I had it 
> going with the radeon, but I guess not.
Option "EnablePageFlip" "true"
somewhere in the xorg.conf device section. It is still problematic 
though, just yesterday I've noticed that detection if it has to be 
disabled is pretty broken now (e.g. starting two opengl apps it seemed 
to miss to disable it 3 out of 4 times .

> 
>> - Without pageflip, reflect partly works. a/d/f/c look good (though c 
>> looks the same as f), but s is hosed beyond recognition. readpix 
>> works, as does zreaddraw and singlebuffer.
> 
> 
> 's' should show a white quad for the 'table' surface representing the 
> stencil buffer values.  'f' toggles front/back rendering - it'll look 
> flickery and especially so when using a/s/d to show the alpha channel, 
> stencil buffer or depth buffer.
Not sure why I didn't notice the flicker before  it's pretty obvious.

> Can you check if 's' worked before I changed the driver?
Yes, it works correctly (even with color tiling) with a checkout from 
yesterday. Strange that depth works but stencil doesn't...
(btw the readbacks really suck. reflect gets down to 15fps when viewing 

Re: Mesa port

Hello Philippe, I was wondering something.  Did you have an issue concerning glFlush?  For some reason,
glFlush does not draw anything to the screen.  I inserted printf calls into my code and I found that glFlush
is not making it's way down to my driver's Flush code.  Any ideas on why that's happening?

-Dee

__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Finishing up renderbuffer changes in DRI drivers

Roland Scheidegger wrote:
> Brian Paul wrote:
> 
>>> - Pageflipping is completely broken. Looks like stuff gets drawn to 
>>> the right place only every second frame or something like that (i.e. 
>>> heavy flicker).
>>
>>
>>
>> What's the trick for enabling/testing page flipping?  I thought I had 
>> it going with the radeon, but I guess not.
> 
> Option "EnablePageFlip" "true"
> somewhere in the xorg.conf device section. It is still problematic 
> though, just yesterday I've noticed that detection if it has to be 
> disabled is pretty broken now (e.g. starting two opengl apps it seemed 
> to miss to disable it 3 out of 4 times .

It seems to be working fine for me now (get latest check-ins).

>> Can you check if 's' worked before I changed the driver?
> 
> Yes, it works correctly (even with color tiling) with a checkout from 
> yesterday. Strange that depth works but stencil doesn't...
> (btw the readbacks really suck. reflect gets down to 15fps when viewing 
> the depth buffer, much slower than sw rendering .)

I've added an assertion to the r200 span depth/stencil code to check 
that the offset parameter is correct.  Try again and let me know what 
happens.

Re: [Mesa3d-dev] Re: Finishing up renderbuffer changes in DRI drivers

Brian Paul wrote:
>> Option "EnablePageFlip" "true"
>> somewhere in the xorg.conf device section. It is still problematic 
>> though, just yesterday I've noticed that detection if it has to be 
>> disabled is pretty broken now (e.g. starting two opengl apps it seemed 
>> to miss to disable it 3 out of 4 times .
> 
> 
> It seems to be working fine for me now (get latest check-ins).
Yes indeed, working now.
(well the two app detection for disabling pageflip still doesn't work, 
but that's more of an X problem I guess...)

>> Yes, it works correctly (even with color tiling) with a checkout from 
>> yesterday. Strange that depth works but stencil doesn't...
>> (btw the readbacks really suck. reflect gets down to 15fps when 
>> viewing the depth buffer, much slower than sw rendering .)
> 
> 
> I've added an assertion to the r200 span depth/stencil code to check 
> that the offset parameter is correct.  Try again and let me know what 
> happens.
Just broken output as before. No assertion failure. Actually, you can 
guess the output somewhat, it's just "tiled".

Roland

Re: Re: Finishing up renderbuffer changes in DRI drivers

Roland Scheidegger wrote:
> Brian Paul wrote:
> 
>>> Option "EnablePageFlip" "true"
>>> somewhere in the xorg.conf device section. It is still problematic 
>>> though, just yesterday I've noticed that detection if it has to be 
>>> disabled is pretty broken now (e.g. starting two opengl apps it 
>>> seemed to miss to disable it 3 out of 4 times .
>>
>>
>>
>> It seems to be working fine for me now (get latest check-ins).
> 
> Yes indeed, working now.
> (well the two app detection for disabling pageflip still doesn't work, 
> but that's more of an X problem I guess...)
> 
>>> Yes, it works correctly (even with color tiling) with a checkout from 
>>> yesterday. Strange that depth works but stencil doesn't...
>>> (btw the readbacks really suck. reflect gets down to 15fps when 
>>> viewing the depth buffer, much slower than sw rendering .)
>>
>>
>>
>> I've added an assertion to the r200 span depth/stencil code to check 
>> that the offset parameter is correct.  Try again and let me know what 
>> happens.
> 
> Just broken output as before. No assertion failure. Actually, you can 
> guess the output somewhat, it's just "tiled".