-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Anholt wrote:
> On Fri, 2009-09-11 at 10:37 -0700, Ian Romanick wrote:
>> Eric Anholt wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: 7c0152fbaeb21ab423a9de339b85c54d1713432b
>>> URL:
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=7c0152fbaeb21ab423a9de339b85c54d1713432b
>>>
>>> Author: Eric Anholt <e...@anholt.net>
>>> Date: Thu Sep 10 09:44:30 2009 -0700
>>>
>>> i965: Enable loops in the VS.
>>>
>>> Passes piglit glsl-vs-loop testcase.
>>>
>>> Bug #20171
>> I see this went into master. Is this also a candidate for 7.5 or 7.6?
>> If so, it should have gone there first. I can take care of the
>> cherry-picking and merging while you're on vacation.
>
> For the record, I hate that development model. It means that I have to
> first identify the earliest branch a change could apply to before
> working. Or I have to do a dance more complicated than just
> cherry-picking after the fact to land my change after I develop it on
I somewhat agree. However, this analysis needs to be done at some point
anyway. Right? It either gets done up-front, or it gets done when
trying to determine whether to cherry-pick back.
> master. It hurts the idle, "how hard will this little thing be"
> experimenting that I do a lot. And given the number of commits of
> merges with conflicts we're seeing, I'm doubting that the merges forward
> are seeing much testing.
I agree with the testing comment 100%.
Testing in Mesa has always been weak, and the branch juggling is just
exacerbating the issue. Perhaps we should have a session at XDC to
discuss this.
> I much prefer periodically analyzing my area and cherry-picking many
> patches after they've had a chance to settle, regression testing the
> batch all at once, and giving stable something that works.
This echoes the arguments that I made when the branching discussion
first happened. The counter-argument that was made, which does have
merit, is that this analysis and cherry-picking either doesn't happen or
happens eons after the code was originally committed. By that time
nobody knows if it should be brought back or not. There were several
patches that I asked people about for 7.5, and nobody had any idea.
>>> ---
>>>
>>> src/mesa/drivers/dri/i965/brw_vs_emit.c | 53
>>> ++++++++++++++++++++++---------
>>> 1 files changed, 38 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_vs_emit.c
>>> b/src/mesa/drivers/dri/i965/brw_vs_emit.c
>>> index 584fdbd..1638ef8 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_vs_emit.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_vs_emit.c
>>> @@ -1270,9 +1270,27 @@ post_vs_emit( struct brw_vs_compile *c,
>>> }
>>>
>>> static uint32_t
>>> -get_predicate(uint32_t swizzle)
>>> +get_predicate(const struct prog_instruction *inst)
>>> {
>>> - switch (swizzle) {
>>> + if (inst->DstReg.CondMask == COND_TR)
>>> + return BRW_PREDICATE_NONE;
>>> +
>>> + /* All of GLSL only produces predicates for COND_NE and one channel per
>>> + * vector. Fail badly if someone starts doing something else, as it
>>> might
>>> + * mean infinite looping or something.
>>> + *
>>> + * We'd like to support all the condition codes, but our hardware
>>> doesn't
>>> + * quite match the Mesa IR, which is modeled after the NV extensions.
>>> For
>>> + * those, the instruction may update the condition codes or not, then
>>> any
>>> + * later instruction may use one of those condition codes. For gen4,
>>> the
>>> + * instruction may update the flags register based on one of the
>>> condition
>>> + * codes output by the instruction, and then further instructions may
>>> + * predicate on that. We can probably support this, but it won't
>>> + * necessarily be easy.
>>> + */
>>> + assert(inst->DstReg.CondMask == COND_NE);
>> Is there a way we could fall back to software TNL here instead of asserting?
>
> Nothing uses any other CC yet, so no need afaict.
Okay... but the NV stuff is coming soon. :) I'm going to try and have
NV_fragment_program_option, NV_fragment_program2, and
NV_vertex_program2_option in Mesa 7.7.
> For the NV stuff, I need to look at what instructions can update CCs
> (everything?) and look more into what can use CCs (not much, it looks
> like?). If we just scan forward and compute which CC we need to
> produce, will that be good enough? Do we save off temps and recompute a
> different CC from the same update if someone uses it? Or, have the CC
> updating instruction produce all of them and save the flags off to temps
> for later use?
Just about any instruction can update the condition codes. There's a
table in NV_fragment_program_option and NV_vertex_program2_option. It's
around line 260 in the NV_fpo spec. Any instruction with an X in the C
modifier column can modify the condition codes. It looks like only the
flow control instructions (KIL, BRA, etc.) and the pack instructions
(PK2H, etc) cannot modify the condition codes.
Almost all instructions can use the condition codes via condition
write-masks. The only instructions that make direct use of the
condition codes are KIL and the flow-control instructions.
> Some things, like the CAL implementation, will be broken in the presence
> of CCs because it does jumps with no execution masking, so we'll take
> the path for two verts at a time even if only one passes. I'm kind of
> thinking of just dumping them back to single program flow in that case.
Could we fake it by surrounding the CAL with an IF? Note that the
assembly shaders don't provide CAL for vertex programs until
NV_gpu_program4. This extension also removes the unstructured branches.
In any case, it will be some time before I get to that extension. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqqntUACgkQX1gOwKyEAw+5awCgjUM28axwtdpT2J7XOhpSANZr
bTIAoIQqFaqlB2YRfPs2DhqPmraef8Uf
=pBRO
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
