On Oct 08, 07 11:02:05 +0200, Syren Baran wrote:
As long as the command processor cannot be programmed from user space, this scenario can be made secure for complete user space programming. While the security advantages of this approach are obvious it severly limits the GPUs use. Quite a few applications could find this massive computing power usefull.
Like... graphics? I don't see the limitation here. Remember, only talking about the command processor, not the SPUs.
A completely programmable GPU changes things a lot. ATI/AMD should really open their specs on this, this is not only interresting for a X-driver. Actually the specs were released November 06.
Only a very tiny bit: output programming, and even there some bits are still missing.
Waiting for 3D docs will result in an infinite loop (at least if you are looking for registers to write something like "turn this object by x degrees"). The relevant document is http://ati.amd.com/companyinfo/researcher/documents/ATI_CTM_Guide.pdf
No information about command tables, no information about memory access, no information about assembler to memory conversion, no information how to initialize the chip. You also only have docs about the "high level" (speak: application) language - while you can assume that it is similar to the hardware interface, you cannot be sure, and there are probably subtle differences.
I may be able to write an assembler. Except for flow control its basicly a search and replace.
The assembler is the most trivial aspect, and actually unnecessary. Mesa already has a ARB_fragment_program and _shader assembler, and a OpenGL 2.1 GLSL compiler. Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org