Hi, since i´m not too deep into X, could someone tell me which functions have to be implemented before its possible to get a kernel module going? BTW, are there already any documents released which document the necessary registers? Thanks, Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Syren Baran wrote:
Hi, since i´m not too deep into X, could someone tell me which functions have to be implemented before its possible to get a kernel module going? BTW, are there already any documents released which document the necessary registers?
Thanks, Syren
Kernel module isn't the only things you need to have 3D. Anyway i believe that with minimum hack you can use the radeon(r300) drm driver and mesa r300 driver to have 3D, things is that this need that you add all dri initialization in radeonhd which is bit painful (my personal taste here :)) On side note my opinion on this is that we should start a brand new gallium driver with ttm from the ground but this might not fit Suse plan which likely need to support older X & kernel (i am so sorry for you ;)). Cheers, Jerome Glisse -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 01, 07 11:25:16 +0200, Jerome Glisse wrote:
Syren Baran wrote:
since i´m not too deep into X, could someone tell me which functions have to be implemented before its possible to get a kernel module going? BTW, are there already any documents released which document the necessary registers?
No. Waiting for them here as well. The DRM module is probably the smallest thing, and deeply interwoven with the X module and the Mesa driver. With the ATI architecture it might be that we could even work w/o a kernel module and be secure (I have some ideas for that), but this is pure guesswork w/o register documentation.
Anyway i believe that with minimum hack you can use the radeon(r300) drm driver and mesa r300 driver to have 3D,
Let's wait and see what type of 3D engine r5xx and r6xx use. Maybe it's related, maybe it's completely new.
things is that this need that you add all dri initialization in radeonhd which is bit painful (my personal taste here :))
?
On side note my opinion on this is that we should start a brand new gallium driver with ttm from the ground but this might not fit Suse plan which likely need to support older X & kernel (i am so sorry for you ;)).
We haven't decided on a memory manager yet. ttm is certainly something
to consider, but I haven't looked much at it (or alternatives) yet.
Whether Gallium is an option or not is also not decided yet. But that
could be changed later on as well. But until some 3D sees the light of
the day, it's probably decided by the community.
My 2 cents
Matthias
--
Matthias Hopf
Am Dienstag, den 02.10.2007, 17:58 +0200 schrieb Matthias Hopf:
On Oct 01, 07 11:25:16 +0200, Jerome Glisse wrote:
Syren Baran wrote:
since i´m not too deep into X, could someone tell me which functions have to be implemented before its possible to get a kernel module going? BTW, are there already any documents released which document the necessary registers?
No. Waiting for them here as well. The DRM module is probably the smallest thing, and deeply interwoven with the X module and the Mesa driver. I already figured that out by myself. With the ATI architecture it might be that we could even work w/o a kernel module and be secure (I have some ideas for that), but this is pure guesswork w/o register documentation. Interresting. I personaly dont know how the ATI architecture differs that a kernel module might be unnecesarry. Fglrx also uses a kernel module. That said i havent looked that deep into the existing modules to give a qualified opinion.
On side note my opinion on this is that we should start a brand new gallium driver with ttm from the ground but this might not fit Suse plan which likely need to support older X & kernel (i am so sorry for you ;)).
We haven't decided on a memory manager yet. ttm is certainly something to consider, but I haven't looked much at it (or alternatives) yet.
Whether Gallium is an option or not is also not decided yet. But that could be changed later on as well. But until some 3D sees the light of the day, it's probably decided by the community.
I´ll invest a couple of hours now and then. Been a while since i last did low level gfx card stuff and 3D, but i hope i´ll be able to contribute a bit more than just some pci-ids.
My 2 cents
Matthias
Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 05, 07 00:22:09 +0200, Syren Baran wrote:
I personaly dont know how the ATI architecture differs that a kernel module might be unnecesarry. Fglrx also uses a kernel module.
It has a completely programmable command processor (Tom's Hardware has a pretty good overview in this case), and all memory accesses (from the hardware side) seem to be virtual, so it might have a MMU. As long as the command processor cannot be programmed from user space, this scenario can be made secure for complete user space programming. I have *no* idea ATM, whether this works with the current DRI architecture or not, so this is probably something for later improvements, but not for the beginning.
Whether Gallium is an option or not is also not decided yet. But that could be changed later on as well. But until some 3D sees the light of the day, it's probably decided by the community.
I´ll invest a couple of hours now and then. Been a while since i last did low level gfx card stuff and 3D, but i hope i´ll be able to contribute a bit more than just some pci-ids.
Cool :)
Thanks, but don't follow that road too far ATM. It'll be quite a while
until we will see 3D docs. At least that's my estimation.
CU
Matthias
--
Matthias Hopf
On Fri, 2007-10-05 at 14:15 +0200, Matthias Hopf wrote:
It'll be quite a while until we will see 3D docs. At least that's my estimation.
Does it mean buying an r6xx now is of no use ? I mean, r7xx could be out before the radeonhd driver can run compiz. Xav -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 05, 07 14:21:42 +0200, Xavier Bestel wrote:
On Fri, 2007-10-05 at 14:15 +0200, Matthias Hopf wrote:
It'll be quite a while until we will see 3D docs. At least that's my estimation.
Does it mean buying an r6xx now is of no use ? I mean, r7xx could be out before the radeonhd driver can run compiz.
It certainly will be. It's not too long until r7xx will be pushed. A 3D
driver is a complex beast, especially if done from the ground up. No,
r4xx code won't help, r6xx has a completely different engine.
Matthias
--
Matthias Hopf
On Fri, 2007-10-05 at 15:47 +0200, Matthias Hopf wrote:
On Oct 05, 07 14:21:42 +0200, Xavier Bestel wrote:
On Fri, 2007-10-05 at 14:15 +0200, Matthias Hopf wrote:
It'll be quite a while until we will see 3D docs. At least that's my estimation.
Does it mean buying an r6xx now is of no use ? I mean, r7xx could be out before the radeonhd driver can run compiz.
It certainly will be. It's not too long until r7xx will be pushed. A 3D driver is a complex beast, especially if done from the ground up. No, r4xx code won't help, r6xx has a completely different engine.
Now the obvious question: do you know if AMD & Novell have plans to have radeonhd work on new cards the day they are out, say from r8xx on ? Thanks, Xav -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 05, 07 17:33:45 +0200, Xavier Bestel wrote:
Now the obvious question: do you know if AMD & Novell have plans to have radeonhd work on new cards the day they are out, say from r8xx on ?
We would love to have a long-term commitment, but obviously I cannot
speak for the AMD side, and I cannot comment on current negotiations.
Sorry, this is getting too political, I think I stretched as far as I
can go in public.
Matthias
--
Matthias Hopf
On Fri, 2007-10-05 at 18:17 +0200, Matthias Hopf wrote:
On Oct 05, 07 17:33:45 +0200, Xavier Bestel wrote:
Now the obvious question: do you know if AMD & Novell have plans to have radeonhd work on new cards the day they are out, say from r8xx on ?
We would love to have a long-term commitment, but obviously I cannot speak for the AMD side, and I cannot comment on current negotiations.
Sorry, this is getting too political, I think I stretched as far as I can go in public.
Oh, thanks a lot already. I was just trying to extort some (hard to find) information for a selfish buying decision. I guess the r300 driver will be good enough for a while yet. Thanks again, Xav -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 05, 07 00:22:09 +0200, Syren Baran wrote:
I personaly dont know how the ATI architecture differs that a kernel module might be unnecesarry. Fglrx also uses a kernel module.
It has a completely programmable command processor Neat. I thought that idea had died with TIGA ( http://en.wikipedia.org/wiki/Texas_Instruments_Graphics_Architecture ) until i read about NVidia´s CUDA (http://en.wikipedia.org/wiki/CUDA ). (Tom's Hardware has a pretty good overview in this case), A link would be nice. and all memory accesses (from the hardware side) seem to be virtual, so it might have a MMU. As long as the command processor cannot be programmed from user space, this scenario can be made secure for complete user space programming. I have *no* idea ATM, whether this works with the current DRI architecture or not, so this is probably something for later improvements, but not for the beginning. 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. Ever heard of coupling 4 SLI cards in a system without adding a output connector to any of them? ( http://www.heise.de/newsticker/meldung/91374 , article in german) Still, the best bang for the buck if single precision computational
Am Freitag, den 05.10.2007, 14:15 +0200 schrieb Matthias Hopf: power is sufficent.
I´ll invest a couple of hours now and then. Been a while since i last did low level gfx card stuff and 3D, but i hope i´ll be able to contribute a bit more than just some pci-ids.
Cool :) Thanks, but don't follow that road too far ATM. It'll be quite a while until we will see 3D docs. At least that's my estimation. Now i got a different hunch. But writing a compiler is nothing i have knowledge of.
CU
Matthias
Greets, Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Am Freitag, den 05.10.2007, 14:15 +0200 schrieb Matthias Hopf:
On Oct 05, 07 00:22:09 +0200, Syren Baran wrote:
I personaly dont know how the ATI architecture differs that a kernel module might be unnecesarry. Fglrx also uses a kernel module.
It has a completely programmable command processor Neat. Well, on slashdot it would probably be tagged something like itsaprocessorjimbutnotasweknowit . It´s a massivly parallel risc chip, centered mainly around the mad command and a couple other math functions. and all memory accesses (from the hardware side) seem to be virtual, so it might have a MMU. It does, its called MC. 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
Am Sonntag, den 07.10.2007, 00:05 +0200 schrieb Syren Baran: limits the GPUs use. Quite a few applications could find this massive computing power usefull.
I have *no* idea ATM, whether this works with the current DRI architecture or not, so this is probably something for later improvements, but not for the beginning. True, more pressing matters to get this thing going. 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.
I´ll invest a couple of hours now and then. Been a while since i last did low level gfx card stuff and 3D, but i hope i´ll be able to contribute a bit more than just some pci-ids.
Cool :) Thanks, but don't follow that road too far ATM. It'll be quite a while until we will see 3D docs. At least that's my estimation. Now i got a different hunch. 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 . As far as i can tell by now, it contains all information necesarry to write an assembler. But writing a compiler is nothing i have knowledge of. I may be able to write an assembler. Except for flow control its basicly a search and replace. On the other hand, did i mention i HATE assembly language. It´s not that really hate reading assembly or hate writing it, but i REALLY HATE debugging it.
Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, 2007-10-08 at 11:02 +0200, Syren Baran wrote:
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 . As far as i can tell by now, it contains all information necesarry to write an assembler. Doesn't this fit fairly nice in the LLVM-based Gallium effort?
Nicolas
Am Montag, den 08.10.2007, 11:17 +0200 schrieb Nicolas Trangez:
On Mon, 2007-10-08 at 11:02 +0200, Syren Baran wrote:
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 . As far as i can tell by now, it contains all information necesarry to write an assembler. Doesn't this fit fairly nice in the LLVM-based Gallium effort?
Hmm, somehow i doubt it. The Sparc and x86 architecture actually appear very similiar compared to this beast. The R580 has (depending on modell) 48 processors each executing the same command on different memory locations (though some may be sleeping, depending on flow control). The instruction set is very different from architectures i know. A Sparcs RISC set is more or less a subset of x86 CISC set, but this ... hmm, i still consider it wierd, but maybe it just takes time getting used to. LLVM docs state it can produce code for Sparc and x86 (and intermediate byte code) and mentions all kinds of optimisation strategies. I doubt these strategies were developed with such a processor in mind. The VM approach doesnt really make any sense, unless we are planning to write a VM for booth ATI and Nvidia GPU´s. And even then interpreting an intermediate code isn´t what a driver would want to do, due to performance penalties.
Nicolas
Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, 2007-10-08 at 12:35 +0200, Syren Baran wrote:
The R580 has (depending on modell) 48 processors each executing the same command on different memory locations (though some may be sleeping, depending on flow control). The instruction set is very different from architectures i know. A Sparcs RISC set is more or less a subset of x86 CISC set, but this ... hmm, i still consider it wierd, but maybe it just takes time getting used to.
LLVM docs state it can produce code for Sparc and x86 (and intermediate byte code) and mentions all kinds of optimisation strategies. I doubt these strategies were developed with such a processor in mind.
Ask Zack Rusin, he's working precisely on that: http://www.nabble.com/Vector-swizzling-and-write-masks-code-generation-t4528... Xav -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Syren Baran wrote:
Am Montag, den 08.10.2007, 11:17 +0200 schrieb Nicolas Trangez:
On Mon, 2007-10-08 at 11:02 +0200, Syren Baran wrote:
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 . As far as i can tell by now, it contains all information necesarry to write an assembler. Doesn't this fit fairly nice in the LLVM-based Gallium effort?
Hmm, somehow i doubt it. The Sparc and x86 architecture actually appear very similiar compared to this beast. The R580 has (depending on modell) 48 processors each executing the same command on different memory locations (though some may be sleeping, depending on flow control). The instruction set is very different from architectures i know. A Sparcs RISC set is more or less a subset of x86 CISC set, but this ... hmm, i still consider it wierd, but maybe it just takes time getting used to.
LLVM docs state it can produce code for Sparc and x86 (and intermediate byte code) and mentions all kinds of optimisation strategies. I doubt these strategies were developed with such a processor in mind. The VM approach doesnt really make any sense, unless we are planning to write a VM for booth ATI and Nvidia GPU´s. And even then interpreting an intermediate code isn´t what a driver would want to do, due to performance penalties.
Nicolas
Syren
I am convinced AMD & NVidia are using things similar to LLVM to optimize shader before translating it to hw, so it's definitely way to go. As side note i don't think anybody will accept security flow just to allow few apps to play with the GPU. I believe we could in the future provide with the help of gallium some nice interface for letting application taking advantage of GPU without the need for the application to know anythings about the card. Cheers, Jerome Glisse -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
As side note i don't think anybody will accept security flow just to allow few apps to play with the GPU. Well, i heard rumors of people using PC´s and even connecting them to
Am Montag, den 08.10.2007, 18:23 +0200 schrieb Jerome Glisse: the interweb instead of placing it in a safe and dumping it at the bottom of the ocean...
I believe we could in the future provide with the help of gallium some nice interface for letting application taking advantage of GPU without the need for the application to know anythings about the card. If the applications memory range can be checked before execution that sure wouldnt be a bad idea. Or are you talking about an intermediate language with references instead of pointers, ala java?
Cheers, Jerome Glisse
Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
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 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
Am Dienstag, den 09.10.2007, 12:58 +0200 schrieb 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. 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.
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. Actually i was refering to the ctm guide. And yes after some grepping i could not find any registers responsible for loading code.
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.
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. 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.
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.
I found some code samples on sourceforge, no more. But know whats strange. 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.
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.
This "backend" IS the assembler. 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.
An assembler for their own CTM language (which I think is what you are proposing, but I might have misunderstood you)
See above. The assembler creates the binary (elf) blob, you call it backend.
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 "using mesa soft-rendering or a gpu has no relevance on the resulting image"? 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.
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. Didnt someone mention the r300 module might be usuable with minor modifications. Possibly there´s a legacy layer to communicate with the GPU for the now.
Matthias
Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
Syren Baran wrote:
Am Dienstag, den 09.10.2007, 12:58 +0200 schrieb Matthias Hopf: Hmm, we are talking about the sdk´s here? Having used neither i dont what the differences are.
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. Didnt someone mention the r300 module might be usuable with minor modifications. Possibly there´s a legacy layer to communicate with the GPU for the now.
Matthias
Syren
Take r300 dri source and use ctm to update fragprog field see r300_reg.h (all swizzle handle natively plus some others additions) and you should be near to some usable 3d driver. Jerome Glisse -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 09, 07 17:44:36 +0200, Jerome Glisse wrote:
Take r300 dri source and use ctm to update fragprog field see r300_reg.h (all swizzle handle natively plus some others additions) and you should be near to some usable 3d driver.
But that's the thing: we want docs first, in order to completely
understand the hardware, and program after that. You will end up with
pretty different code, I guess, if you do that. Also, we don't have
anything for the r6xx.
Unfortunately, you guys had to cope with not having docs at all, so you
didn't have that luxury...
Matthias
--
Matthias Hopf
Unfortunately, you guys had to cope with not having docs at all, so you didn't have that luxury... I know this is off topic ..., but to much luxury tends to soften
Am Dienstag, den 09.10.2007, 18:01 +0200 schrieb Matthias Hopf: people. ;) And if you ever spend a week chasing a bug in you own code just to figure out its an error in the docs ... well, guess the rest.
Matthias
Syren -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 09, 07 18:38:59 +0200, Syren Baran wrote:
Unfortunately, you guys had to cope with not having docs at all, so you didn't have that luxury... I know this is off topic ..., but to much luxury tends to soften
Am Dienstag, den 09.10.2007, 18:01 +0200 schrieb Matthias Hopf: people. ;)
Believe me - at the moment it isn't :-P We have enough undocumented stuff, and if it is how PLLs actually behave...
And if you ever spend a week chasing a bug in you own code just to figure out its an error in the docs ... well, guess the rest.
Been there, done that ;)
Matthias
--
Matthias Hopf
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
participants (6)
-
Jerome Glisse -
jiho＠c-zone.net -
Matthias Hopf -
Nicolas Trangez -
Syren Baran -
Xavier Bestel