[virglrenderer-devel] Some question about running a GLES backend for virgl

[Lepton Wu]

On Wed, Mar 21, 2018 at 7:23 PM, Jakob Bornecrantz <jakob at collabora.com> wrote:
> On 2018-03-22 01:38, Lepton Wu wrote:
>>
>> Hi Jakob,
>>
>> I have seen you sent some CL to run virglrenderer with GLES backend.
>> I am also interested in this and tried it and it doesn't work well for
>> me. I have some questions:
>>
>> 1.  The current virgl code is using some functions which is not
>> available in GLES, for example, it's using glFramebufferTexture2DEXT
>> and glBindBufferARB,  I can't find them in header files from GLES,
>> then how it works with GLES backend?
>
>
> Virgl is using libepoxy so it can use both GLES and desktop GL. We have
> added several checks to not call functions that are not available. Libepoxy
> will sometimes map a EXT function to a ARB function or a core function. If
> you are building virglrender make sure you have master of libepoxy.
>
> It should all work as is, tho we have only tested on 3.2 and the many
Thanks. How likely the current code will work on some old GLES backend like 3.0?
Would there be lots of stuff missing or need to be fixed? Just want to
have some rough
idea before I put time on it.
> extensions that a Mesa driver gives. So there can be functions missing from
> angle.
>
>>
>> 2. Any rough estimation for how long would it take for virgl work with
>> a pure GLES backend?  basically I'd like to run virglrenderer on
>> windows host and it seems it's easy to get GLES on windows with angle.
>> So if virglrenderer can work with GLES backend, than perhaps it's not
>> far away to get qemu+virgl works under windows.
>
> We have it running now on Linux Mesa intel GLES 3.2 drier, if you are using
> the master branch of virgl.
>
> What is not upstreamed right now is getting QEMU to give you a GLES context.
> Search and replace SDL_GL_CONTEXT_PROFILE_CORE with
> SDL_GL_CONTEXT_PROFILE_ES in ui/sdl2-gl.c in the QEMU source.
>
> It should just work on Windows if you give virgl a GLES context, modulo
> different functions being available.
>
> Cheers, Jakob.