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 thread. Issue 2: 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. Issue 11: 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. Issue 13: Similar to issue 2, R500 fragment programs support unstructured everything but vertex programs don't, so not overlapping sounds good to me. Issue 15: 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. Issue 17: 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. Issue 34: 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! cu, Nicolai > > - 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@lists.sourceforge.net > 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! http://p.sf.net/sfu/devconference _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
