On 19 November 2013 20:47, Paul Berry wrote:
> From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
>
> When the Clear or ClearBuffer* commands are used to clear a
> layered framebuffer attachment, all layers of the attachment are
> cleared.
>
> This patch fixes meta clears
I currently work on a simpler solution for Gallium. I'm using
AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
though):
void main()
{
gl_Position = gl_Vertex;
gl_TexCoord[0] = MultiTexCoord0; // clear color
gl_Layer = gl_InstanceID;
}
Then I render the quad with Draw
On 21 November 2013 05:21, Marek Olšák wrote:
> I currently work on a simpler solution for Gallium. I'm using
> AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
> though):
>
> void main()
> {
> gl_Position = gl_Vertex;
> gl_TexCoord[0] = MultiTexCoord0; // clear color
>
Considering you're the only user of meta_clear who cares about it,
it's all up to you. If your hardware can do AMD_vertex_shader_layer,
you won't ever have to implement any other code path.
It's silly to have multiple GLSL shaders for different versions of the
API. I think this should be API-indep
On 20 November 2013 01:28, Chris Forbes wrote:
> If I'm reading this right, there is now *always* a GS in the clear
> program, if the driver can support it -- is this possibly silly, given
> that most clears will be nonlayered?
>
> My understanding is that switching the GS stage on and off carrie
If I'm reading this right, there is now *always* a GS in the clear
program, if the driver can support it -- is this possibly silly, given
that most clears will be nonlayered?
My understanding is that switching the GS stage on and off carries
pretty severe penalties on some hardware.
It might be t
>From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes meta clears to properly clear all layers of a layered
framebuffer att
