[Mesa-dev] [PATCH 0/11] Post-processing infrastructure / gsoc work

Christoph Bumiller e0425955 at student.tuwien.ac.at
Wed Aug 17 12:55:49 PDT 2011

On 17.08.2011 18:56, Lauri Kasanen wrote:
> On Wed, 17 Aug 2011 09:13:24 -0600
> Brian Paul <brianp at vmware.com> wrote:
>> I don't know if this is possible, but could the post-processor be 
>> constructed as another gallium driver that wraps other drivers?  For 
>> example, the rbug driver is a wrapper driver that intercepts most of 
>> the context/screen methods and then passes them through to the wrapped 
>> driver.
>> If the post-processor could be a wrapper, it would seem to be more 
>> flexible and easily used with any winsys or state tracker.
I this instance, post-processing is applied to the dri2 buffer when the
drawable is flushed. To me this makes no sense in a driver, it's state
tracker business. You don't want to apply it after a specific driver
function (draw) call ...

> Someone who knows gallium better than I do will have to answer that. My guess would be not, since it needs access to the hw accel (and respective config infrastructure; that is, driconf for the dri st), but as said, I don't know gallium that well.
> It is not a lot of work to add it for a different state tracker as is; calls to init, shutdown, and run are enough.
>> I spotted one other thing.  In some places you're declaring variables 
>> after code.
> My understanding is that Mesa is c99 (with such includes for some systems included in the tree). Are there really c99 compilers that would choke on that?
> Thanks,
> - Lauri
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list