[Arm-netbook] arm-netbook Digest, Vol 20, Issue 11

lkcl luke luke.leighton at gmail.com
Thu Feb 9 16:30:02 GMT 2012


On Thu, Feb 9, 2012 at 2:46 PM, Alec Ari <neotheuser at ymail.com> wrote:
>> Date: Thu, 9 Feb 2012 01:46:46 +0000
>> From: lkcl luke <luke.leighton at gmail.com>
>> Subject: Re: [Arm-netbook] [review] SoC proposal
>
>>  if you've got direct first-hand experience of the types of
>> low-level
>> operations involved in 3D i could... damn, i could really
>> have used
>> your help last year: i put out a call on the various mailing
>> lists for
>> some help in evaluating what was needed at the assembly
>> level for 3D
>> primitives and got no response.
>
> Actually, the main part I'm most oblivious to is the assembly level 3D instructions themselves. I have a much better understanding of GL/GLSL programming, but when it comes to asm instructions of how the GPU works and low-level decoding / rendering, that's what I don't understand, at least not yet. OpenGL and GLSL have a lot of documentation, tutorials, sample / example code, but all the low-level stuff is covered in the docs for the hardware itself. Might I add that my assembly programming skills are still very poor and would be useless in anything remotely this advanced.

 well that's a benchmark, right there, that says "assembly ain't good
enough", so that should be entirely taken care of at a lower-level.

 ok, the approach that i had in mind was to go, ok, gallium3d with
mesa and llvmpipe can actually do a fair performance using MMX
instructions on x86, if you have an SMP multi-core processor.  so...
what the heck, why not optimise the living shit out of the XTensa
instruction set so that it does an acceptable software-driven
performance?

 i mean, you've seen what X-Burst can do, on the Ingenic MIPS, right?
that's an 8-stage pipelined FPU that they just recompiled mesagl and
actually got somewhere.

 now imagine 8 cores each with their own SIMD FPU.

 so forgetting how these systems "hand over control to a GPU which
gets on with it", what's the *actual* low-level inner loops, in
*c-code*?  i mean i'd love to trust the MIPS-3D-ASE paper and
analysis, but i'd rather have a 2nd opinion.

l.



More information about the arm-netbook mailing list