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.
Cheers
Antoine
[1] : https://www.opengl.org/sdk/docs/man2/xhtml/glXCreateContext.xml -- do it yourself http://antoine.villeret.free.fr
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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
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@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
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@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
yes with code from Git, I got "Direct Rendering enabled!" posted on window creation. by changing GL_TRUE to GL_FALSE in gemglxwindow.cpp:303 [1] I don't get this message again but the FPS stay at 60fps (@Cyrille : with pixel_liquide2_57.pd, 1920x1080, framebuffer rendering)
Moreover according to [2], Nvidia's driver are using GLX not DRI but I can't verify this yet. Note that the repo contains an example on how to share texture between 2 process on embedded hardware (EGL) using DRI, maybe this note only apply to embedded Nvidia's driver.
+ a
[1] : https://github.com/avilleret/Gem/blob/master/src/Output/gemglxwindow.cpp#L30... [2] : https://github.com/pcwalton/linux-drm-sharing-test/blob/master/README -- do it yourself http://antoine.villeret.free.fr
2014-10-27 19:17 GMT+01:00 Cyrille Henry ch@chnry.net:
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@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
Le 27/10/2014 19:30, Antoine Villeret a écrit :
yes
ok, if it's working, then everything is ok! cheers c
with code from Git, I got "Direct Rendering enabled!" posted on window creation. by changing GL_TRUE to GL_FALSE in gemglxwindow.cpp:303 [1] I don't get this message again but the FPS stay at 60fps (@Cyrille : with pixel_liquide2_57.pd, 1920x1080, framebuffer rendering)
Moreover according to [2], Nvidia's driver are using GLX not DRI but I can't verify this yet. Note that the repo contains an example on how to share texture between 2 process on embedded hardware (EGL) using DRI, maybe this note only apply to embedded Nvidia's driver.
a
[1] : https://github.com/avilleret/Gem/blob/master/src/Output/gemglxwindow.cpp#L30... [2] : https://github.com/pcwalton/linux-drm-sharing-test/blob/master/README -- do it yourself http://antoine.villeret.free.fr
2014-10-27 19:17 GMT+01:00 Cyrille Henry ch@chnry.net:
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@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
On 10/27/2014 10:41 AM, Antoine Villeret wrote:
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.
in order to do context sharing, you need to have a reference to an "original" context (with which you want to share). i do not see how you can achieve this between different "processes".
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 ?
yes, probably (once we have found out how to create such a shared context).
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)
not very advanced. PIMPL just stands for "Private IMPLementation" and is an idiom to hide implementation details from the public header files (by using a pointer to a private class): this basically means that you can change the private data (e.g. add new members), without having to touch the header files (great somebody else includes the header and you don't want to break binary compatibilty). it also allows to use class-local functions (in the PIMPL) without having to add new methods to the class (in the main class). it's really all about keeping the public interface of a class minimal.
CALLBACK4WIN is simply a macro that tries to get the handle to the "correct" gemglxwindow instance for a given glut-callback (glut will not provide any "user-data" in the context; however it's possible to find out which window emitted the callback; CALLBACK4WIN then uses a map to query the gemglxwindow instance for the given window id)...
what's more important: afaik, glut does not allow context sharing at all (there's nothing in the API that would handle such a case).
afaik, only glx and glfw3 have an API that allows context-sharing.
gfamdsr IOhannes
2014-10-27 18:09 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 10/27/2014 10:41 AM, Antoine Villeret wrote:
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.
in order to do context sharing, you need to have a reference to an "original" context (with which you want to share). i do not see how you can achieve this between different "processes".
isn't it possible to handle this original context in the first Gem instance and put it in a shared memory ? then in the second Gem, couldn't we use that first context in glXCreateContext() ?
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 ?
yes, probably (once we have found out how to create such a shared context).
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)
not very advanced. PIMPL just stands for "Private IMPLementation" and is an idiom to hide implementation details from the public header files (by using a pointer to a private class): this basically means that you can change the private data (e.g. add new members), without having to touch the header files (great somebody else includes the header and you don't want to break binary compatibilty). it also allows to use class-local functions (in the PIMPL) without having to add new methods to the class (in the main class). it's really all about keeping the public interface of a class minimal.
CALLBACK4WIN is simply a macro that tries to get the handle to the "correct" gemglxwindow instance for a given glut-callback (glut will not provide any "user-data" in the context; however it's possible to find out which window emitted the callback; CALLBACK4WIN then uses a map to query the gemglxwindow instance for the given window id)...
thanks for the explanation, you know, I learned C++ with Gem and those "not-so-advanced" uses are quite rare in Gem's code :-)
what's more important: afaik, glut does not allow context sharing at all (there's nothing in the API that would handle such a case).
with examples/14.multiple_windows/03.texture_sharing.pd and [gemglutwindow] I got a texture on both windows.
afaik, only glx and glfw3 have an API that allows context-sharing.
but [gemglfw3window] doesn't allow texture sharing yet.
+ a
gfamdsr IOhannes
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
On 10/27/2014 07:18 PM, Antoine Villeret wrote:
thanks for the explanation, you know, I learned C++ with Gem and those "not-so-advanced" uses are quite rare in Gem's code :-)
you know, I also learned C++ with Gem, and only introduced those "not-so-advanced" techniques recently when i learned about them :-)
what's more important: afaik, glut does not allow context sharing at all (there's nothing in the API that would handle such a case).
with examples/14.multiple_windows/03.texture_sharing.pd and [gemglutwindow] I got a texture on both windows.
yes, thats the idea. Gem should not only support "multiple windows" but also "multiple contexts" (that is: it ought to work even if two windows can NOT share textures, display-lists,...); this is what GemContextData is for: the problem is that two different contexts may choose to generate to different IDs for something (like a shader module). i'm currently thinking about having a map between t_atom (t_float really) and context-specific data, so we an object like [glsl_vertex] will only output a single ID and the consumer ([glsl_program]) can get the various context-specific IDs from this single number.
afaik, only glx and glfw3 have an API that allows context-sharing.
but [gemglfw3window] doesn't allow texture sharing yet.
yes. but we can add it (whereas we cannot add it with [gemglutwindow])
gdsr IOhannes
Am 27. Oktober 2014 19:18:06 MEZ, schrieb Antoine Villeret antoine.villeret@gmail.com:
isn't it possible to handle this original context in the first Gem instance and put it in a shared memory ? then in the second Gem, couldn't we use that first context in glXCreateContext() ?
I dont know off hand how a "glxcontext" is represented. If its a pointer we have a problem. If its POD it might just work.
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
GLXContext is defined on glx.h:165 as :
typedef struct __GLXcontextRec *GLXContext;
it seems to be a pointer to __GLXcontextRec struct then we have a problem right ?
+ a
-- do it yourself http://antoine.villeret.free.fr
2014-10-28 9:13 GMT+01:00 IOhannes zmölnig zmoelnig@iem.at:
Am 27. Oktober 2014 19:18:06 MEZ, schrieb Antoine Villeret < antoine.villeret@gmail.com>:
isn't it possible to handle this original context in the first Gem instance and put it in a shared memory ? then in the second Gem, couldn't we use that first context in glXCreateContext() ?
I dont know off hand how a "glxcontext" is represented. If its a pointer we have a problem. If its POD it might just work.
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
On 11/03/2014 05:49 PM, Antoine Villeret wrote:
GLXContext is defined on glx.h:165 as :
typedef struct __GLXcontextRec *GLXContext;
it seems to be a pointer to __GLXcontextRec struct then we have a problem right ?
most likely.
otoh, since the manpage you referred to explicitely mentioned context sharing across process, there ought to be a way to do it.
see [1]
fgmsdr IOhannes
[1] https://www.opengl.org/discussion_boards/showthread.php/156327-GLX-context-s...
it's nice to see that someone got it to work under linux
but quite discouraging to see that he did it almost 10 years ago while I'm looking for that for quite a while !
anyhow, thanks for the links, it looks promising
+ a
-- do it yourself http://antoine.villeret.free.fr
2014-11-04 10:08 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 11/03/2014 05:49 PM, Antoine Villeret wrote:
GLXContext is defined on glx.h:165 as :
typedef struct __GLXcontextRec *GLXContext;
it seems to be a pointer to __GLXcontextRec struct then we have a problem right ?
most likely.
otoh, since the manpage you referred to explicitely mentioned context sharing across process, there ought to be a way to do it.
see [1]
fgmsdr IOhannes
[1]
https://www.opengl.org/discussion_boards/showthread.php/156327-GLX-context-s...
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
-
Antoine Villeret -
Cyrille Henry -
IOhannes m zmölnig -
IOhannes zmölnig