WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
Am Tuesday 13 October 2009 21:20:40 schrieb Ian Romanick:
> Here is the initial version of the assembly extension that was discussed
> at XDC. This is a very early alpha version, and some parts are not yet
> complete. At this point, I am mainly looking for two things in a review:
Looks good from a very cursory look.
> - Are there any issues marked "RESOLVED" where you disagree with the
> resolution? I'm especially interested in issues 2, 4, and 19.
Note: The following replies are based on my understanding of the hardware.
There may still be some missing or unclear information in the docs by AMD. If
this is the case, then it can hopefully be clarified in the course of this
1) R500 supports unstructured branching in fragment programs but not in vertex
programs, so I'm happy about leaving it out.
2) R500 supports address registers as described in vertex programs (including
input/output offsets), but has no address registers at all in fragment
programs. A loop address register can be used as offsets in loops, but the
values loaded into this register must be determined at compile time.
Issue 4: Agreed. R500 does not support address register math.
Issue 6 (predicate registers):
Is it correct that there is only a PSEQ instruction and not the full
orthogonal set? The grammar includes the full orthogonal set, but the
instruction list seems to be missing something.
I assume predicate registers can be used to mask writes of ordinary ALU
instructions. Can they also mask TEX instructions? (R500 supports both, and
it's easy to emulate, but see caveat).
I think we can do everything you throw at us on R500. The only difficulty is
that R500 is a bit schizophrenic in that vertex programs are very different
from fragment programs, but we can emulate things. The only stupid weakness is
that swizzling predicates in fragment programs is essentially impossible (the
only natively supported swizzles are .rgba and the smears .rrrr, .gggg, .bbbb,
.aaaa). Obviously we can emulate this.
R500 supposedly supports relative addressing of temporary registers in vertex
programs, and also in fragment programs (but only using loop indices). I have
never tested whether it actually works, though.
Similar to issue 2, R500 fragment programs support unstructured everything but
vertex programs don't, so not overlapping sounds good to me.
I know R500 fragment programs can support a CONT, but I'm not so familiar with
the R500 vertex programs, and they seem generally less flexible.
I would *expect* negative addressing offsets to work on R500, but somehow I
haven't been able to get them to work. I'll see if I can look into it again.
I don't see any support for an address register stack on R500, or anything
else to provide for a subroutine stack.
Thanks for working on this!
> - Are there any issues marked "UNRESOLVED" that you have an opinion on
> or data to support a resolution? I'm especially interested in issues 7,
> 11, 15, and 34 (resolution may be related to 4).
> - Are there any instructions listed that cannot be trivially supported
> on some relevant hardware? Some instructions expand to multiple real
> instructions (e.g., NRM). As long as the expansion is trivial and only
> adds one or two extra instructions, this is okay.
> - Is there some important SM3 feature that's missing? I plan to
> circulate this around the Wine community after the next revision.
> There is some goofy formatting and issue numbering. This is done to
> minimize the diffs with GL_NV_gpu_program4. The output of 'diff -d
> --side-by-side -W 165 MESA_gpu_program3 NV_gpu_program4' is pretty
> readable and useful.
> http://people.freedesktop.org/~idr/MESA_gpu_program3.txt >
>--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference > _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
Mesa3d-dev mailing list