[Mesa-dev] [PATCH] virgl: clear render state before submitting clear command
Dave Airlie
airlied at gmail.com
Tue May 8 06:38:18 UTC 2018
On 8 May 2018 at 16:26, Gert Wollny <gert.wollny at collabora.com> wrote:
> Am Montag, den 07.05.2018, 18:25 -0700 schrieb Gurchetan Singh:
>> In vrend_clear, we already save and restore colormasks and stencils:
>>
>> https://cgit.freedesktop.org/virglrenderer/commit/?id=b75e0a1dabdfbda
>> 44c310a69026a9dbd7d980294
>> https://cgit.freedesktop.org/virglrenderer/commit/?id=252b00d77c30ce3
>> 9608c1a9de18523cbdcaca623
>>
>> It would be nice if we can put everything on the host side.
> Okay, I can see your point, but may instead of going through all these
> states one by one we could something on the host side that does
>
> - push the state
> - set clean state
> - glClear
> - pop state
>
> and especially, factoring out these steps into different functions,
> because the host clear function is getting quite messy.
>
> The alternative would be to not do anything about these states on the
> host side and just send a clear state :). IMHO the whole clear
> implementation is a performance disaster anyway, but I'm afraid that
> within the limits of gallium it can't be solved in a better way.
Care to elaborate here? Nothing in gallium or virgl is really set in stone
we should be able to engineer new interfaces if needed, they just might
take some time.
>
> dEQP-
> GLES3.functional.shaders.indexing.moredynamic.with_value_from_indexing_
> expression_fragment
>
> and since I never really looked into that test, I don't yet know which
> rasterization state this one might enable and not disable on the host
> before clear.
>
> Anyway, If you confirm that we should do it on the host side, then I
> will retract this patch and prepare something for virglrenderer.
I think since we've fixed similiar on the host side we should continue to do so.
Dave.
More information about the mesa-dev
mailing list