[GEM-dev] sharing texture between process

Cyrille Henry ch at chnry.net
Mon Oct 27 19:17:58 CET 2014


how did you get hardware acceleration without DRI?

cheers
c

Le 27/10/2014 18:04, Antoine Villeret a écrit :
>
> why ? how huge ?
>
> I understand that direct rendering could improve performances but
> I can run very GPU expensive patchs you made without direct rendering
> and without noticable difference.
>
> So it may be worth a try...
>
> a
> --
> do it yourself
> http://antoine.villeret.free.fr
>
>
> 2014-10-27 11:11 GMT+01:00 Cyrille Henry <ch at chnry.net>:
>>
>>
>> Le 27/10/2014 10:41, Antoine Villeret a écrit :
>>>
>>> hello,
>>>
>>> since texture sharing seems to work between context inside one Gem's
>>> instance, I'm now wondering how we can introduce texture sharing
>>> between process.
>>> According to [1], texture (and more generally display list) can be
>>> shared between process if direct rendering is disabled and process are
>>> using the same X server.
>>> If I understand correctly, the only thing to do is to share the
>>> display list structure over process.
>>> Could we use shared memory to do that ?
>>>
>>> I look into the [gemglxwindow] and [gemglutwindow] code and it looks a
>>> bit obscure to me, it uses advanced C++ idioms (PIMPL for the former
>>> and CALLBACK4WIN for the latter) that I don't understand well yet. So
>>> I want to know if this texture sharing between process is feasible
>>> before going deeper.
>>
>>
>> direct rendering disable?
>> that's look like a huge problem...
>>
>> cheers
>> c
>>
>>>
>>> Cheers
>>>
>>> Antoine
>>>
>>> [1] : https://www.opengl.org/sdk/docs/man2/xhtml/glXCreateContext.xml
>>> --
>>> do it yourself
>>> http://antoine.villeret.free.fr
>>>
>>> _______________________________________________
>>> GEM-dev mailing list
>>> GEM-dev at lists.iem.at
>>> http://lists.puredata.info/listinfo/gem-dev
>>>
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at lists.iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>



More information about the GEM-dev mailing list