Re: Module Proposal: GNOME Shell

On Mon, 2010-04-19 at 11:48 +0000, Michael wrote:
> Thanks for your answers.
> Emmanuele Bassi <ebassi <at>> writes:
> > sorry, reply split in two - my allergies are making me less coherent
> > today.
> No problem, I will just split my answer!
> > On Fri, 2010-04-16 at 21:51 +0000, Michael wrote:
> > with my Clutter maintainer hat firmly on: we are not interested in
> > supporting a software backend in Clutter, and we're not targeting the
> > Mesa software rasterizer. Clutter assumes you have basic hardware
> > acceleration for the OpenGL 1.3 command set - which is a specification
> > almost 10 years old. we have fallbacks in places, but mostly to cope
> > with GL and GLES differences.

> After posting that I realised that the renderer was probably the right place
> for the sort of "fixes" I had in mind, not Clutter.  You say though that Clutter
> will never target the software renderer.

no: I said that I won't implement a software-based rasterizer inside
Clutter itself. been there, experimented that.

if the software rasterizer in Mesa gets better then by all means we
won't prevent it - though Clutter is actively trying to move around Mesa
in some areas, for instance by submitting our own programs to the GPU
since we control/know the state (Mesa, on the other hand, has to rebuild
a massive program and has to recalculate the state for that from many
more variables than Clutter). I've gone on record multiple times saying
that people concerned with the level of support for OpenGL and asking
for a software fallback should start looking into Mesa first.

>   Does this mean that you take
> explicit action to prevent it, or just that the software renderer doesn't
> implement everything you need?

it's the latter.

>   I am strongly assuming the latter, but
> asking just in case.  Any idea whether this will be different with llvmpipe
> whenever it becomes usable?

currently, we are not looking at Gallium3D. if everything in Mesa is
transparently going through that, I don't particularly care.

as I said: Clutter is targeting real, hardware accelerated OpenGL (and
OpenGL|ES); if a software rasterizer - *any* software rasterizer - is
provided as a fallback, and doesn't lie about its capabilities - *cough*
GLX 1.3 *cough* - then we will use those capabilities. if the
capabilities are slow then it's the software rasterizer that needs to be
fixed - or, better yet, it's the 3D driver that needs to be fixed.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]