[Mesa-dev] [PATCH 0/8] gallium: create a generic way to validate fb params

[Marek Olšák]

On Fri, Oct 4, 2013 at 6:39 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Fri, Oct 4, 2013 at 10:02 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> Wouldn't it be more flexible for you to just change the depth buffer
>> format internally by reallocating the depth buffer in the driver
>> whenever it's incompatible with the colorbuffer? I think you should be
>> able to do that easily without changing the pipe_resource structure.
>> If a depth buffer cannot be used by set_framebuffer_state, just create
>> a new one with an appropriate format, then blit from the old depth
>> buffer to the new one, so that you won't lose its content, and delete
>> the old one. For transfers, you just need to blit to convert the depth
>> buffer to the format the state tracker expects.
>
> It would indeed be more flexible. There are two reasons why I didn't
> do it that way
>
> (a) I'm very new to gallium, I'm not comfortable with such trickery.

I recommend reading p_state.h, p_context.h and p_screen.h. Make sure
you understand most of it. Textures can be blitted using
pipe_context::blit.

> (I don't even know how to blit between textures.) Also, wouldn't you
> have to blit the new texture back to the old texture? Or is there
> sufficient magic to take care of the format difference? What if the
> requested zsbuf was 24-bit but the cbufs were 16-bit? Would you
> suggest upgrading the cbufs or downgrading the zsbuf -- downgrading
> the zsbuf could also cause some application weirdness, no?

No, the old texture would be completely replaced by the new texture.
The old texture would be deleted. There is no magic to help you here,
but sometimes we have to jump through hoops to support our hardware.
r300g and r600g are full of workarounds and trickery, but at the end
of the day, the drivers work better for everybody.

If your driver supports only 1 render target, then feel free to
upgrade the colorbuffer instead. However It wouldn't be a very good
idea if the driver supported multiple render targets.

>
> (b) If that were the preferred approach, wouldn't the same approach
> have been taken with MIXED_COLORBUFFER_FORMATS? The preference seemed
> to be to reject things the driver didn't like rather than accepting
> every possible input and converting back and forth. Perhaps the cbufs
> are somehow different from depth in a way I don't understand though.

MIXED_COLORBUFFER_FORMATS is a feature first introduced in R500 and
DX9.0c, therefore I expect older games not to break if we disallow
mixed formats on older ASICs. Also, apps using mixed formats are not
very common, if they exist at all.

If you don't want to implement my suggestion above, then I suggest
adding a hw-specific CAP, e.g. PIPE_CAP_FRAMEBUFFER_RESTRICTIONS_NV30,
and doing whatever you need in st/mesa if the CAP is advertised. That
would a lot less invasive than your current patch series.

Marek