On Thu, Feb 10, 2011 at 11:06 PM, Tim Bird <[email protected]> wrote:
> On 02/10/2011 01:37 PM, Luke Kenneth Casson Leighton wrote:
>>  hmmm... much as i'd like to be the one to do that, having researched
>> it for quite a while, i think it best if i take a step back on that
>> one, but... yeah if anyone _does_ want to begin, independently, you
>> really only have to look here:
>>
>>   http://en.wikipedia.org/wiki/List_of_PowerVR_products#Series5_.28SGX.29
> You should add that link to the proposal page.
>
> ...
>>  then, you just do a search "free software SGX driver" and you get,
>> once you have sifted through the confusion over the "shim" kernel
>> driver 
>> "what-do-you-mean-it's-obviously-free-software-there's-a-GPL-linux-kernel-driver-what-are-you-talking-about-fool"
>> misunderstandings, you find that there are actually a hell of a lot of
>> people who want a *true* free software PowerVR SGX library.
>
> People wanting something for their own purposes is
> not a compelling argument for why a trade association
> should fund this work.

 *click*.  good point! :)

> Christien Reis' presentation discusses some good reasons
> that a free driver would be preferable to a proprietary
> driver.  I don't want an exposition on the value
> proposition of the whole free software movement, but
> it would be good to call out some specific benefits,
> *for CE vendors*, for this work.


> Like: reduced maintenance, easier bug fixing,
> more control over SoC-specific optimizations, etc.
> that result in reduced cost or greater customer
> satisfaction.

 ok.  right.  got it.

 ok, such aaas...

1) SoC-specific companies, esp. multi-core, can benefit from the
multiple cores performing work in parallel to keep the GPU optimally
(and maximally) occupied.  we simply don't _know_ if the proprietary
vendors have taken short-cuts in order to "get the damn thing
working", but you can bet, simply on sheer cynicism alone, that the
implementation is less than optimal.  with a free software
implementation, you can at least pay *someone* to optimise the code,
rather than be reliant on the proprietary vendor as your "Gods To Whom
Thou Shalt Payyyy Homagge". [the classic free software argument,
specifically targetted at a GPU + multi-core SoC context, with my own
annoying "euww" twist.  can't help it, sorry]

2) you can see from the blog and reviews of the Gallium3D software
implementation that even a port of MesaGL to LLVMpipe gave a whopping
8x performance increase (3fps up to 25fps).  and the proprietary 3D
embedded vendors are cutting themselves off from this kind of
technologyyyy...why??

3) you can also see that even intel has struggled for years to produce
a stable, reliable 3D GPU hardware-software engine, gave up and
licensed powervr (because the software's better!) for Poulsbo (2009+
Atom Chipset) and CE41xx.  if intel can't get it right, but the free
software community can (in the form of Gallium3D), that should tell
you something.

4) FIMD-3D, samsung's OpenGL 3D engine + library (in the S3C6410 and
S5PC100) is unusable - not because of the hardware, but because of the
library!  if you call two well-known opengl initialisation functions
in the wrong order, the application segfaults!  can you, i, or anybody
get this fixed? no.  can you even REPORT that there is a problem? no.
can you find out WHO to report the problem to? no.  even if you had
tons of money, should you spend it on samsung, pay them to get the
library fixed? of course not! it would be easier to redesign the
product to use an alternative CPU, and you cannot guarantee that there
will be other errors.  variant on 1) above, with a specific real-world
example.

hmmm... i'm running out of ideas, but that's off the top of my head.
*scratch*....  oh yes:

5) some people might find OpenGL ES 1.1 appropriate (small,
easy-to-review, for secure minimalist embedded and real-time,
mission-critical applications).  some people might find OpenGS ES 2.0
appropriate (medium-sized, good overall characteristics, good
features).  others might find a full-on, all-bells-and-whistles with
knobs and a cherry on top OpenGL 3.0 an appropriate choice.  has
Imagination Technologies provided all three?  mmmm... no.

6) some people might want to pay money to implement the latest
khronos.org standards, or sponsor universities (which would be
cheaper), or they might want to have other uses and other standards
implemented... will they get absolutely fleeced by The Gods That
Imagination Technologies Have Set Themselves Up To Be?  you bet your
ass they will.  oh - that's if Imagination bother to answer their
calls.

7) some people might wish to utilise the raw power of the GPU, which
in combination with it being on massively lower-power CPUs than any
ATI, NVidia or other GPU, would mean a much higher bang-per-buck ratio
for a supercomputer.  but... can you do so, right now? mmmm.... no.

8) some companies may wish to set themselves up as experts providing
supercomputer services and software porting and optimisation,
utilising the PowerVR GPU in ways that Imagination never dreamed off
and are too paranoid and focussed on "mass-market money" to let any
business do anything else with quotes their quotes technology.  can
such companies do that right now? mmm.... no.

you have to remember that GPUs aren't just 3D engines, they're
whopping-great ginormous floating-point parallel processors, because,
duh, if you're doing 3D, that's what you need.  in the case of
PowerVR, look at the diagram on their behemoth: to optimally feed the
beast, you even need an embedded RISC processor right next door to the
Vector Floating Point Units, which even has its own on-board memory!
that's incredibly valuable and powerful for performing all kinds of
scientific calculations, research, and so on, and it's being....
wasted, on doing pretty whizzy pictures and enturtaynmunt. ok, i'm
playing the fool here but you can see clearly what i'm getting at.

ok, now i'm out of ideas, honest.

l.

p.s. aand another thing ... no, just kidding :)
_______________________________________________
Celinux-dev mailing list
[email protected]
http://tree.celinuxforum.org/mailman/listinfo/celinux-dev

Reply via email to