Mailinglist Archive: radeonhd (353 mails)
| < Previous | Next > |
Re: [radeonhd] Re: Updated R5xx 3D Programming Guide
- From: Jerome Glisse <glisse@xxxxxxxxxxxxxxx>
- Date: Wed, 9 Apr 2008 01:24:40 +0200
- Message-id: <20080409012440.7995d2f0.glisse@xxxxxxxxxxxxxxx>
On Wed, 09 Apr 2008 00:36:28 +0200
Syren Baran <sbaran@xxxxxx> wrote:
I think you miss my point, you can't have too much depth in loop or
procedure call on r5xx gpu. See section 7.6.2 or section 3.5 of ATI
CTM guide.
That's an uneasy part, this need a lot of basic infrastructure, lot
of code for doing this.
I just want to be sure that you are aware of the limitation of GPU
hw, it should not be seen as CPU and so not be tackle like a CPU.
Compiler we are aiming for should be able to translate TGSI in
GPU opcode. I am yet not sure on win we could get from using llvm
too for producing the byte code.
Cheers,
Jerome Glisse <glisse@xxxxxxxxxxxxxxx>
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
Syren Baran <sbaran@xxxxxx> wrote:
Am Dienstag, den 08.04.2008, 19:39 +0200 schrieb Jerome Glisse:
True, thats still the main problem i see.
GPU are not a CPU, programming them is far more complexe than programming
CPU, you have to handle things that CPU do for you. For instance you have
setup how data are routed to GPU.
Also GPU are not intended to run usualWell, a normal CPU doesnt have any conditional statements like "if,
program, ie program with if, swith, jump, and others alike instructions.
GPU could handle such instructions but your often limited in the depth you
can have (for instance no more than 16 nested for, if statement).
switch, while etc" either, just the jz, jnz etc on assembly level.
The conditional jumps described in the R5xx guide arent all too
different (Section 7.6 Flow control and 7.6.3.1 in special).
I´m pretty sure this is the most tricky part, since ideally the
conditional jumps should only occur when either all or no stream units
want to jump, otherwise the gpu will mask a lot of units.
I think you miss my point, you can't have too much depth in loop or
procedure call on r5xx gpu. See section 7.6.2 or section 3.5 of ATI
CTM guide.
This part need to be designed with GPU specificity
in mind. This why i don't think a compiler, at least in the sense you seems
to think about, is of any use with a GPU.
Dont think so, otherwise nvidias CUDA would be useless as well.
Being able to send a program to the GPU will be usefull for benchmarking
as i already pointed out.
Compiler might be a bit overdoing it for the time being. Assembling the
opcodes into a binary seems like the obious first step. And then loading
the program into GPU memory and starting it.
Or, to be more specific,
a normal cpu program creates a buffer and loads the GPU binary,
then sends the gpu the instruction to load and execute the program.
The GPU should be able to send some results into a buffer in main
memory.
That's an uneasy part, this need a lot of basic infrastructure, lot
of code for doing this.
I just want to be sure that you are aware of the limitation of GPU
hw, it should not be seen as CPU and so not be tackle like a CPU.
Compiler we are aiming for should be able to translate TGSI in
GPU opcode. I am yet not sure on win we could get from using llvm
too for producing the byte code.
Cheers,
Jerome Glisse <glisse@xxxxxxxxxxxxxxx>
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
| < Previous | Next > |