Syren Baran wrote:
The CTM units are descriped. Including the instructions and their numerical values for PE, MC and the CO. The ALU OP codes dont have their numerical values noted. Strangely enough the fglrx package does not include any unusual ELF binaries. Given the information in the guides its easy enough to find the opcodes numerical values.
I'm guessing -- and this really is a *blind* guess -- that the ELF program described in the CTM guide is used to implement a "virtual accelerator", much like what was done with the TI 34020 (which used COFF) way way back in the day. A driver talks to the card by writing commands in an arbitrary format to some arbitrary location, which the loaded ELF program has arbitrarily defined. So I'd guess the fglrx package probably only knows some arbitrary interfaces, which it uses to talk to whatever ELF blob already resides on the card. All of this seems ironic to me. Back in the Stone Age, I had an NDA for the Mach 8 docs. To get the NDA, I had to call some guy in ATI developer relations. I mentioned this TI-based card I had, and he really went off bad-mouthing the whole concept, pointing out that the 34020 was really slow and primitive compared to all the hardwired logic in the Mach 8, and much more expensive to implement and support. Now here we are, and ATI has this RISC-based monster, which makes up for quality (lack of hardwired logic) with quantity (numerous parallel stream engines). And because of all this, we have trouble writing a basic driver with accelerated 2D and video. Personally, that's all I really care about, basic 2D and video acceleration. If *any* vendor would make a chipset with just that -- 2D and video, no 3D at all -- were it at all reasonable and could I get docs and/or source for it, that's what I'd use. 3D is an issue for me because of the problem it creates with accelerated 2D and video drivers. So, how many times have you heard this? There should be a counter somewhere.
They state the ctm sdk is longer availble publicly since 1. September. Less than one week prior to releasing the 2d specs. Of course that may just mean that amds polishing their new sdk before releasing it to a broader public, but i dont know.
Or it may mean they didn't attract enough interest to justify the support costs. It's all just window dressing to hype the stock, anyway. Maybe they now hope an open source project will eventually take up the slack with practically no cost.
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´m wondering if this ctm is the wrong track, or some way for serious performance improvements.
As above, I think an ELF blob is used to implement a "virtual accelerator". It's embedded on the card as a substitute for hardwired logic, and presents an arbitrary interface to the host. That's my guess. -- Jim Howard <jiho@c-zone.net> -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org