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

[Matthias Hopf]

On Oct 09, 07 16:28:10 +0200, Syren Baran wrote:
> It also states that it uses a 32bit address range. This 32bit range is
> virtual, so knowing where $address points to physicly gives know sure
> knowledgle as to where $address+1 points to. So 0x00000000-0x0fffffff
> could point to graphics memory while other addresses above to point to
> system memory. Once this has been set up, how do you prevent a program
> from accesing these memory locations. 

If this setup is available to a trusted manager (Xserver or kernel
module) only, you get user-space security for free. The graphics card
will have to report access violations to the manager, of course.

> Actually i was refering to the ctm guide. And yes after some grepping i
> could not find any registers responsible for loading code.

Ok, missunderstood. Loading code won't be enough, though, we need DMA,
initialization, and raster engine setup as well. For 3D graphics
rasterization and texturing is also typically more demanding than for
GPGPU.

> > Some things? Sorry, I read this differently. You don't even know whether
> > this is the actual command language understood by the graphics card. It
> > could very well be transformed by the CTM layer.
> The CTM units are descriped. Including the instructions and their
> numerical values for PE, MC and the CO.

Yes, so what? The do not necessarily have to correspond to the machine
language, that's what I try to tell you all the time. If their
abstraction model is so bad that it is identical to the real opcodes,
well, good for us, but I wouldn't count on that. Given that r5xx and
r6xx are vastly different, I still doubt that.

Hm, further reading "This chapter describes the functional behavior of
the ATI X1K Fragment Processor (X1K FP)." it seems like it really
describes the r5xx model. Eeek. Still, we have no information about
r6xx, and that's where the fun actually starts.

> The ALU OP codes dont have their numerical values noted.

You might find them in the header files. Might.

> They state the ctm sdk is longer availble publicly since 1. September.
> Less than one week prior to releasing the 2d specs.

Hm. The two groups actually don't correlate much with each other. So I
guess, this is just by accident.

> Of course that may just mean that amds polishing their new sdk before
> releasing it to a broader public, but i dont know.

Very well possible.

> > Binary blob. That what the card can actually run. This is to be created
> > by the backend, which is provided by the driver. As I said, we currently
> > have no clue how this command string has to actually look like, just
> > some hints how the commands in this command string *probably* look like.
> This "backend" IS the assembler.

So different wording, talking about the same :)
As the input to this thing is most likely a tree structure, and not some
text file, I'd call it a backend.

> The ELF header is described in the ctm guide. Even a simple binary
> should be sufficient to figure the numerical values for the opcodes.
> Having access to a compiler would be ideal, just compile a single
> command and look at the executables hexdump.

I doubt that we need to reverse engineer that. As we need additional
docs anyway, the command language is probably included in that
(hopefully upcoming) docs.

> >  would have to do the
> > same, but CTM syntax has no relevance in graphics.
> Please define "graphics" in this context. Something along the line of

Interactive 3D graphics, i.e. accelerated OpenGL/DirectX/whatever.
Right. Definitions are sometimes worthwhile.

> >  An open CTM
> > implementation would be nice, of course, but even nicer would be an open
> > CUDA implementation for AMD chips, which probably won't be done by AMD
> > anyways (because it's NVIDIA), and which is much further with respect to
> > machine abstraction etc.
> Hmm, we are talking about the sdk´s here?
> Having used neither i dont what the differences are.

CTM is pretty much low level. CUDA is a high level abstraction layer,
and already widely used in research. You write everything in a C-like
language, and AFAIR even inputs/outputs are pretty much abstracted away.
Don't think I can say that about CTM.

> But one thing puzzling me now. If the fglrx package does not include an
> ati specific elf, they must be doing something differently.
> Maybe embedded in some other file?

I must admit I haven't understood this elf thing in this context :-/
I assume it is used as a file format in CTM user space, for being able
to store assembled/compiled instructions, in order to link them during
application runtime before downloading them to the graphics card.

CU

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de