Re: [2/5] WineD3D: Implement loops with the NV extensions

[Allan Tong]

> +    if(vshader)
> +    {
> +        struct shader_arb_ctx_priv *priv = ins->ctx->backend_data;
> +        struct list *e = list_head(&priv->control_frames);
> +        struct control_frame *control_frame = LIST_ENTRY(e, struct control_frame, entry);
> +
> +        if(priv->loop_depth > 1) shader_addline(buffer, "PUSHA aL;\n");
> +
> +        shader_addline(buffer, "ARLC aL, %s.xywz;\n", src_name);
> +        shader_addline(buffer, "BRA loop_%u_end (LE.x);\n", control_frame->loop_no);
> +        shader_addline(buffer, "loop_%u_start:\n", control_frame->loop_no);
> +    }

Nested loops still don't work here.  You need NV_vertex_program3 in
order to use PUSHA and POPA.

 - Allan

[2/5] WineD3D: Implement loops with the NV extensions

[Stefan Dösinger]

Am 10.06.2009 um 15:20 schrieb Allan Tong:

>> +    if(vshader)
>> +    {
>> +        struct shader_arb_ctx_priv *priv = ins->ctx->backend_data;
>> +        struct list *e = list_head(&priv->control_frames);
>> +        struct control_frame *control_frame = LIST_ENTRY(e, struct  
>> control_frame, entry);
>> +
>> +        if(priv->loop_depth > 1) shader_addline(buffer, "PUSHA aL; 
>> \n");
>> +
>> +        shader_addline(buffer, "ARLC aL, %s.xywz;\n", src_name);
>> +        shader_addline(buffer, "BRA loop_%u_end (LE.x);\n",  
>> control_frame->loop_no);
>> +        shader_addline(buffer, "loop_%u_start:\n", control_frame- 
>> >loop_no);
>> +    }
>
> Nested loops still don't work here.  You need NV_vertex_program3 in
> order to use PUSHA and POPA.
Well, I enable NV_vertex_program3 if available. I don't check for it  
because if the app uses nested loops and it is not supported, then  
there isn't anything I can do anyway, and we advertised the wrong  
shader version or something else went wrong. (e.g. we get a 3.0  
shader, only support 2.0 and don't return an error, or we get a broken  
shader and don't check it properly)

[2/5] WineD3D: Implement loops with the NV extensions

[Allan Tong]

On Wed, Jun 10, 2009 at 6:45 PM, Stefan Dösinger<stefan(a)codeweavers.com> wrote:
> Am 10.06.2009 um 15:20 schrieb Allan Tong:
> > > +    if(vshader)
> > > +    {
> > > +        struct shader_arb_ctx_priv *priv = ins->ctx->backend_data;
> > > +        struct list *e = list_head(&priv->control_frames);
> > > +        struct control_frame *control_frame = LIST_ENTRY(e, struct
> > > control_frame, entry);
> > > +
> > > +        if(priv->loop_depth > 1) shader_addline(buffer, "PUSHA aL;\n");
> > > +
> > > +        shader_addline(buffer, "ARLC aL, %s.xywz;\n", src_name);
> > > +        shader_addline(buffer, "BRA loop_%u_end (LE.x);\n",
> > > control_frame->loop_no);
> > > +        shader_addline(buffer, "loop_%u_start:\n",
> > > control_frame->loop_no);
> > > +    }
> >
> > Nested loops still don't work here.  You need NV_vertex_program3 in
> > order to use PUSHA and POPA.
>
> Well, I enable NV_vertex_program3 if available. I don't check for it because
> if the app uses nested loops and it is not supported, then there isn't
> anything I can do anyway, and we advertised the wrong shader version or
> something else went wrong. (e.g. we get a 3.0 shader, only support 2.0 and
> don't return an error, or we get a broken shader and don't check it
> properly)

Maybe I'm missing something here, but I would have thought that
shader_arb_generate_vshader should have something along the lines of:

if (GL_SUPPORT(NV_VERTEX_PROGRAM3)) {
    shader_addline(buffer, "OPTION NV_vertex_program3;\n");
    ...
}

Right now there's just a line for "OPTION NV_vertex_program2", and
even when running on hardware that supports NV3, you still get an
error trying to use a shader that uses PUSHA/POPA.

 - Allan

[2/5] WineD3D: Implement loops with the NV extensions

[Stefan Dösinger]

> Maybe I'm missing something here, but I would have thought that
> shader_arb_generate_vshader should have something along the lines of:
> Hmm, indeed, that ended up in my texldl patch. It should not matter  
> too much because we don't advertise SM 3.0 yet. I might send the  
> texldl patch today.

I guess that happened because originally the loop patch was behind the  
texldl patch in my tree, and I reordered them after the texldl patch  
had a problem.

Currently sending further patches is blocked by the loop unrolling  
patch - I need to write a test that actually uses the aL value to see  
if it works properly, but I don't have a windows machine to validate  
the test at the moment.