CTM: was Re: [radeonhd] Necessary for 3D

Syren Baran sbaran at gmx.de
Mon Oct 8 14:53:12 PDT 2007


Am Montag, den 08.10.2007, 15:08 +0200 schrieb Matthias Hopf:
> 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?
My first thought was video encoders.
Graphics related, yes. X related, no.
> I don't see the limitation here. Remember, only talking about the
> command processor, not the SPUs.
And how do you prevent an executing program from accessing system
memory? The set_inst_fmt sets a base address. The description about the
MC is somewhat unclear, but it does specify that system memory can be
accessible.
> 
> > > 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.
Think its a bit more.

> 
> > 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.
True, some things are missing. The most relevant part being the
initilisation.
> 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.
You know. It took me QUITE a while to figure out what you are saying.
The document is missing only one, admitadly crucial part here. The
numerical values for the opcodes.
After finding some freely available source examples for CTM i was able
to figure out what you mean.
The samples included asm commands such as ADD, which are implemented via
MAD (again, if the CTM_Guide is correct).
Due to your statements i just have to ask. You signed a NDA over the no
longer publicly available CTM SDK?

> 
> > 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.
Unnecesarry?
And what are those things supposed to output?
My PC cant run Sparc, ARM, PowerPC etc.. code.
What are you trying to tell me?
> 
> Matthias
> 
Syren



More information about the xorg-driver-ati mailing list