[Dev] Common/Generic profile images usability

VanCutsem, Geoffroy geoffroy.vancutsem at intel.com
Mon May 26 16:00:43 GMT 2014



> -----Original Message-----
> From: Stanislav Vorobiov [mailto:s.vorobiov at samsung.com]
> Sent: Monday, May 26, 2014 3:14 PM
> To: VanCutsem, Geoffroy; Yu, Max A;
> stephane.desneux at open.eurogiciel.org
> Cc: dev at lists.tizen.org; Bartosh, Eduard
> Subject: Re: [Dev] Common/Generic profile images usability
> 
> On 05/26/2014 04:33 PM, VanCutsem, Geoffroy wrote:
> >
> >
> >> -----Original Message-----
> >> From: Stanislav Vorobiov [mailto:s.vorobiov at samsung.com]
> >> Sent: Monday, May 26, 2014 8:38 AM
> >> To: Yu, Max A; VanCutsem, Geoffroy;
> >> stephane.desneux at open.eurogiciel.org
> >> Cc: dev at lists.tizen.org; Bartosh, Eduard
> >> Subject: Re: [Dev] Common/Generic profile images usability
> >>
> >> Hi,
> >>
> >> What kind of upstream are we talking about exactly ? emulator-yagl is
> >> a user-mode OpenGL implementation which we use in qemu, it has no
> >> upstream, it's a project of it's own. There're upstreams for qemu and
> >> kernel however and we haven't tried to push anything there, but what
> >> difference does it make ?
> > For the parts that have an upstream project, it would make our life easier
> when we're upgrading any of these in the stack. At the moment, the
> emulator image is typically a bit behind the image for 'real' hardware
> because we need to port all the drivers, etc. to the latest components such
> as the kernel.
> >
> >> Even if qemu and kernel parts of YaGL/VIGS were in upstream, you
> >> would still had to manage emulator-yagl package as you do now.
> > That's understood, pushing things upstream is only one part of the solution.
> Yet I feel it would be a good step in the right direction and would make the
> maintenance of the 'emulator' images simpler.
> Before trying to "push it upstream" I think we must first answer one question
> - what features do we need for upstream ? This solution provides DRM
> graphics stack with OpenGL ES 1.0, 2.0 and 3.0 support. This is embedded
> GPU virtualization, we don't provide desktop OpenGL support or Direct X
> support. Our initial goal was to create a solution that could be used to run
> different tizen profiles in QEMU, such as mobile, gear, ivi, etc. with large
> variety of host OSes and host GPUs. If we want to send this upstream, we'll
> probably need to provide "full blown" GPU virtualization solution which will
> include Direct X and full OpenGL support and this is currently out of the scope
> of this project.
Is this true? I mean that we would *have to* have DirectX and full OpenGL support before it could get accepted upstream?

By the way, I agree with the scope as defined above, really just trying to explore if we couldn't make this whole thing less cumbersome to maintain moving forward. It may require some more work/effort/time now but that's how it goes when you adopt an 'upstream first' approach and there are tangible benefits to doing it that way.

> 
> >
> >>
> >>> it seems to me that patching the various components is creating a
> >>> number
> >> of issues that could be avoided.
> >> IMHO for emulator user-space we only need to install emulator-yagl
> >> instead of mesa, what else do we need to patch ?
> > My (perhaps naïve) question below really was: do we really need this
> package? Could we not use Mesa instead for the emulator image? Perhaps
> another way of formulating this question is: shouldn't the upstream
> emulator-yagl project be Mesa?
> If you look at emulator-yagl package sources you'll notice that it's not
> related to mesa at all, this is not mesa source patched to run on emulator,
> it's a separate OpenGL ES implementation. Kind of like ARM has their own
> OpenGL implementation for Mali, Imagination technologies for PowerVR,
> etc. Yes, it could have been implemented inside mesa source tree I guess, but
> the way it is now is that it's a separate project.
I understand that it's a different codebase than Mesa... and I understand that's how it's been developed so far. My question is what would prevent us from changing that? It would be so much easier from a build perspective to *not* have this dedicated repo for the emulator images. Having a different provider for OpenGL ES is just making things more complicated than they should be in my opinion.

Thanks,
Geoffroy

Intel Corporation NV/SA
Kings Square, Veldkant 31
2550 Kontich
RPM (Bruxelles) 0415.497.718. 
Citibank, Brussels, account 570/1031255/09

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


More information about the Dev mailing list