----- Original Message -----
> Am 28.01.2014 23:08, schrieb Zack Rusin:
> > gallivm soa code supported only a single level of nesting for
> > control flow opcodes (if, switch, loops...) but the d3d10 spec
> > clearly states that those are nested within functions. To support
> > nesting of conditionals inside functions we need to store the
> > nesting data inside function contexts and keep a stack of those.
> > Furthermore we make sure that if nesting for subroutines is deeper
> > than 32 then we simply ignore all subsequent 'call' invocations.
> Hmm I thought nesting worked just fine, except for the fact that when
> using just one stack we'd have needed a much larger one. Wasn't that
> true? (Not arguing about using per-function stacks, just curious.)

The issue is that d3d10 spec is very specific about the nesting requirement 
being per-subroutine. So just increasing those nesting levels wouldn't really 
work, because 63 levels in one subroutine and 65 in another doesn't necessarily 
equal code path that has 64 levels in two subroutines (even both have 
technically 64 levels) - we get away with it for conditionals but not for 
function calls.
It's also worth noting that the patch handles overflows which whck explicitly 
tests for and we were just crashing on those. The overflow behavior is 
unidentified only for conditionals, subroutine calls above the level 32 /have/ 
to be ignored (again whck tests for it). 

> > +   ctx->loop_stack[ctx->loop_stack_size].loop_block = ctx->loop_block;
> > +   ctx->loop_stack[ctx->loop_stack_size].cont_mask = mask->cont_mask;
> > +   ctx->loop_stack[ctx->loop_stack_size].break_mask = mask->break_mask;
> I am confused why some assignments use the variables from ctx and some
> from mask here.

The masks are in general global (the 'call' opcode could have been inside 
switch'es, loops or/and conditionals) so the function contexts push/pop the 
global masks and need to operate on those. Things that are not masks are in 
general per-function-context, which means that we can just store them in 
function contexts.

> As mentioned inline, I don't quite get when the values from mask or ctx
> are used. This might well be correct as this is tricky stuff and the
> diff is difficult to understand.
> Otherwise this looks good to me. Would that also help when we'd switch
> to not always inline all functions?

Yea, I think it would, but then we would need a lot of other changes (storing 
those masks in some struct inside some global object that each function can 
reference). But yea, this code isn't the cleanest but function calls, 
conditionals, loops and switches are inherently difficult in SoA mode so 
there's not a lot we can do. We need to store the nesting data inside something 
that resembles function context because d3d is very clear that that's what it 
wants so everything else we'll be a hack where we just try to imitate that 
behavior that's going to be uglier than this code.

z
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to