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

[Matthias Hopf]

On Oct 08, 07 23:53:12 +0200, Syren Baran wrote:
> Am Montag, den 08.10.2007, 15:08 +0200 schrieb Matthias Hopf:
> > 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

MMU.
That's what I said, AFAIK the graphics card includes an MMU. I think it
can only be programmed from the command processor. set_inst_fmt seems to
program a virtual address. Given that the addresses the chip has to be
programmed to use already differ from the ones of the PCIe bridge, I
tend to believe that it has a read MMU.

> MC is somewhat unclear, but it does specify that system memory can be
> accessible.

And the description also say, that they have virtual memory, because
otherwise those huge register files of >1000 threads couldn't be
handled.

> > Only a very tiny bit: output programming, and even there some bits are
> > still missing.
> Think its a bit more.

Not really. Read it. :-(
Even pixel clock PLL docs are missing in public ATM.

It's

2.1 Memory Controller
2.2 Bus Interface
2.3 PCIE
2.4 Clock Generator
2.5 I2C
2.6 VGA
2.7 Display Controller (Graphics, Overlay, Color Matrix, Hardware
    Cursor, Multi-VPU, Display/Memory Control)
2.8 CRTC
2.9 Display Output

This is only initialization (which you want to do with AtomBIOS anyways,
because it very much differs from chip to chip, and there are literally
hundreds of them) and output programming.

> > > 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.

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.

> Due to your statements i just have to ask. You signed a NDA over the no
> longer publicly available CTM SDK?

Nope. In that case your knowledge could be very well better than mine.
We have an NDA, but I don't really know the CTM SDK, except from
SigGraph and public docs.

> > 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?

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.

An assembler for their own CTM language (which I think is what you are
proposing, but I might have misunderstood you) would have to do the
same, but CTM syntax has no relevance in graphics. 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.

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