Hi,
On Thursday 28 February 2008 16:49:15 Ian Romanick wrote:
> Brian Paul wrote:
> | [EMAIL PROTECTED] wrote:
> |> Hello Ian,
> |>
> |> Am Donnerstag 28 Februar 2008 01:40:40 schrieb Ian Romanick:
> |>> [EMAIL PROTECTED] wrote:
> |>> | I tried the gallium branch on my ps3. Unfortunately, all opengl
> |>>
> |>> programs segfault. I'm not sure, but I remember that SDK 3.0 (on fc8)
> |>> was not supported - is this still the case?
> |>>
> |>> To build with SDK 3.0 you need to add "-DSPU_MAIN_PARAM_LONG_LONG" to
> |>> the SPU_CFLAGS.
> |>
> |> yes - this works!
> |>
> |> Now I'm wondering what are the expected fps in gears. With all (6) spu's
> |> running with 100% (from spu-top), I get 24 fps. This may be ok,
>
> because the
>
> |> driver is still in development. What I'm wondering is, what the spu
>
> are doing
>
> |> all the time...
>
> Compiling with -O should just about double that.
even three times with "-O2 -ffast-math -ftree-vectorize". My gcc-4.3
miscompiles something with -O3, so glxinfo crashes in tgsi. Maybe this is
related to this warning:
gcc -mcpu=cell -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../include -g -O2 -ftree-vectorize -ffast-math -Wall -Winline -fPIC
-m32 -mabi=altivec -maltivec -I.
-I/opt/ibm/cell-sdk/prototype/sysroot/usr/include -DGALLIUM_CELL
util/tgsi_build.c -o util/tgsi_build.o
util/tgsi_build.c: In function ‘tgsi_compare_instruction_ext_nv’:
util/tgsi_build.c:851: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:851: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c: In function ‘tgsi_compare_instruction_ext_label’:
util/tgsi_build.c:910: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:910: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c: In function ‘tgsi_compare_instruction_ext_texture’:
util/tgsi_build.c:951: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:951: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c: In function ‘tgsi_compare_src_register_ext_swz’:
util/tgsi_build.c:1074: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:1074: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c: In function ‘tgsi_compare_src_register_ext_mod’:
util/tgsi_build.c:1145: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:1145: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c: In function ‘tgsi_compare_dst_register_ext_concode’:
util/tgsi_build.c:1291: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:1291: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c: In function ‘tgsi_compare_dst_register_ext_modulate’:
util/tgsi_build.c:1349: warning: dereferencing type-punned pointer will break
strict-aliasing rules
util/tgsi_build.c:1349: warning: dereferencing type-punned pointer will break
strict-aliasing rules
> | There's a few things going on.
> |
> | First, vertex transformation is pretty darn slow. Initially, it was
> | being done on the PPU using a vertex program interpeter. More recently,
> | Ian has been moved vertex transformation to the SPUs, but it's still
> | interpreted code. I think it's actually slower than PPU-based
> | transformation because gears was running around 30 fps the other week.
thanks Brian for explanation, though I didn't understood much ;-)
> This is true. Running vertex programs on the SPUs adds communication
> overhead to the interpreter overhead. There's a lot that can be done to
> fix that, and I hope to get to it soon.
In fact, spu-top show 100% system-load on the spu's, so I don't think they do
anything stressful (beside waiting for something). On the other hand, the
examples programs (like matrix_mul) show 100% user-load.
> The SPU shaders act like a remote procedure call for the 'shader->run'
> call in draw_vertex_shader_queue_flush. After the vertex data makes one
> round trip through the SPUs, it is sent back up for rasterization. This
> is clearly a poor architecture for Cell.
>
> We really want to move the whole draw elements call onto the SPUs. The
> SPUs would process a few vertices at a time in the vertex shader and
> broadcast the results for rasterization. I'm still doing research on
> intra-SPU communication. Once I understand that a bit better, I should
> be able to come up with a good architecture.
Thanks for working on the cell port!
Greetings
Marvin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
