Re: SDL2 + POGL2 + PDL confluence
On 2013-08-19, at 7:43 PM, Mason James wrote: > > On 2013-08-19, at 4:20 AM, Kartik Thakore wrote: > >> There is no need to. I made a PDL to SDL_surface work before. And in SDL2 >> you can create template from surface. > > awesome, thanks Kartik > > > and slightly off-topic but… > has anyone managed to build POGL on debian-wheezy lately? i'm getting a > segfault :/ > > hi All i had another go at this, and fixed my build problem (some missing GL libraries) i managed to sort a working travis buildbot for the repo too - using xvfb, a virtual X11 framebuffer tool this 'xvfb' technique should allow us to get a passing build of the framebuffer tests on the SDL2 repo :) https://github.com/KohaAloha/POGL/commit/3feb44a192f8b35625daf4c2fc74615d55883c0f https://travis-ci.org/KohaAloha/POGL/builds/10618263 cheers, Mason
Re: SDL2 + POGL2 + PDL confluence
On 2013-08-19, at 4:20 AM, Kartik Thakore wrote: > There is no need to. I made a PDL to SDL_surface work before. And in SDL2 you > can create template from surface. awesome, thanks Kartik and slightly off-topic but… has anyone managed to build POGL on debian-wheezy lately? i'm getting a segfault :/ -- root@vbox1:~# git clone git://git.code.sf.net/p/pogl/code pogl-code Cloning into 'pogl-code'... Resolving deltas: 100% (667/667), done. root@vbox1:~# cd pogl-code/ root@vbox1:~/pogl-code# perl Makefile.PL interface=FREEGLUT verbose $verbose set to 1 found libs: GL = 'GL' GLU = 'GLU' GLUT = 'glut' Testing for OpenGL Extensions Testing GLUT version glversion: cd utils;make -f Makefile GLUT_LIB=glut GLUT_DEF=HAVE_GLUT clean;make -f Makefile GLUT_LIB=glut GLUT_DEF=HAVE_GLUT OpenGL Warning: XGetVisualInfo returned 0 visuals for 0x85e72c0 OpenGL Warning: Retry with 0x8002 returned 0 visuals Segmentation fault make: *** [glversion.txt] Error 139 rm -f glversion.txt rm -f glversion rm -f glversion.o cc -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/usr/openwin/include -DHAVE_GLUT -c glversion.c cc glversion.o -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -L/usr/openwin/lib -L/usr/lib/xorg/modules -L/usr/X11R6/lib/modules -L/usr/lib/xorg/modules/extensions -L/usr/X11R6/lib/modules/extensions -lGL -lglut -lGLU -lXi -lXmu -lXext -lX11 -lm -o glversion chmod u+x glversion ./glversion > glversion.txt get_extensions: no extensions found in utils/glversion.txt -- > > hi Chris, > > i was looking at elmex's construder code recently, and noticed that the > passing of an SDL surface to OpenGL was done by dumping the SDL surface to a > BMP temp file (via File::Temp), then loading the BMP with OpenGL. > > obviously this solution is a little slower than others, but... it should > 'just work' without much effort > > we could always use this lazy technique for initial testing, until a more > 'correct' solution is sorted with SDL_Texture :) > > > Mason >
Re: SDL2 + POGL2 + PDL confluence
There is no need to. I made a PDL to SDL_surface work before. And in SDL2 you can create template from surface. On Sun, Aug 18, 2013 at 12:33 AM, Mason James wrote: > > On 2013-08-17, at 1:37 AM, Chris Marshall wrote: > > > On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore > > wrote: > >> > >> I am definitely interested in helping with this. Perhaps we should make > a > >> test module that tests just these integration. > >> > >> It will get latest branches of the 3 projects and run tests. > >> > >> What do you think? > > > > I'm glad to see the interest but most of the base work > > is still needing to be done as far as the OpenGL stuff. > > We need modern OpenGL support in POGL before a lot of > > the specific development can occur. > > > > However, one important piece that could be investigated > > is how we could make conversion between SDL2 objects > > and PDL objects work. Ideally we could have a fast > > conversion to take a piddle and use it for an SDL2 surface > > or texture or whatever and similarly for the other direction. > > > > Currently, the approach used for SDL is to create the PDL > > object with the right sized data segment and then pass that > > to SDL to make a surface from that. I'm not sure what would > > work for SDL2 stuff. > > > > --Chris > > > hi Chris, > > i was looking at elmex's construder code recently, and noticed that the > passing of an SDL surface to OpenGL was done by dumping the SDL surface to > a BMP temp file (via File::Temp), then loading the BMP with OpenGL. > > obviously this solution is a little slower than others, but... it should > 'just work' without much effort > > we could always use this lazy technique for initial testing, until a more > 'correct' solution is sorted with SDL_Texture :) > > > Mason
Re: SDL2 + POGL2 + PDL confluence
On 2013-08-17, at 1:37 AM, Chris Marshall wrote: > On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore > wrote: >> >> I am definitely interested in helping with this. Perhaps we should make a >> test module that tests just these integration. >> >> It will get latest branches of the 3 projects and run tests. >> >> What do you think? > > I'm glad to see the interest but most of the base work > is still needing to be done as far as the OpenGL stuff. > We need modern OpenGL support in POGL before a lot of > the specific development can occur. > > However, one important piece that could be investigated > is how we could make conversion between SDL2 objects > and PDL objects work. Ideally we could have a fast > conversion to take a piddle and use it for an SDL2 surface > or texture or whatever and similarly for the other direction. > > Currently, the approach used for SDL is to create the PDL > object with the right sized data segment and then pass that > to SDL to make a surface from that. I'm not sure what would > work for SDL2 stuff. > > --Chris hi Chris, i was looking at elmex's construder code recently, and noticed that the passing of an SDL surface to OpenGL was done by dumping the SDL surface to a BMP temp file (via File::Temp), then loading the BMP with OpenGL. obviously this solution is a little slower than others, but... it should 'just work' without much effort we could always use this lazy technique for initial testing, until a more 'correct' solution is sorted with SDL_Texture :) Mason
Re: SDL2 + POGL2 + PDL confluence
I think it will with SDL_Texture. http://wiki.libsdl.org/moin.fcg/SDL_Texture On Fri, Aug 16, 2013 at 9:37 AM, Chris Marshall wrote: > On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore > wrote: >> >> I am definitely interested in helping with this. Perhaps we should make a >> test module that tests just these integration. >> >> It will get latest branches of the 3 projects and run tests. >> >> What do you think? > I'm glad to see the interest but most of the base work > is still needing to be done as far as the OpenGL stuff. > We need modern OpenGL support in POGL before a lot of > the specific development can occur. > However, one important piece that could be investigated > is how we could make conversion between SDL2 objects > and PDL objects work. Ideally we could have a fast > conversion to take a piddle and use it for an SDL2 surface > or texture or whatever and similarly for the other direction. > Currently, the approach used for SDL is to create the PDL > object with the right sized data segment and then pass that > to SDL to make a surface from that. I'm not sure what would > work for SDL2 stuff. > --Chris >> On Thu, Aug 15, 2013 at 1:11 PM, Chris Marshall >> wrote: >>> >>> PDL/SDL/OpenGL users- >>> >>> With the recently announced SDL2 release and in-progress work >>> to provide perl bindings for the same, I wanted to share my >>> thoughts for leveraging joint capabilities of these three >>> modules with a couple of specific points. >>> >>> 1) SDL2 brings integrated hardware acceleration via Direct3D and/or >>> OpenGL to both 2D and 3D graphics. This offers the possiblity >>> of using modern OpenGL API features like renderbuffers for >>> computation and display. >>> >>> 2) PDL provides a high level array computation language that >>> can be used as a back-end engine for SDL applications and >>> visualization. The PDL::Graphics::TriD currently uses >>> the OpenGL-1.x fixed pipeline interface. >>> >>> 3) Perl OpenGL currently supports the original fixed-pipeline >>> display process of OpenGL-1.x and some 2.x functionality. >>> Work is underway to update the support to modern OpenGL >>> APIs such as OpenGL-3.x, OpenGLES,... >>> >>> The common thread here is OpenGL, and I think that by updating >>> the OpenGL use and interfaces to the modern programmable display >>> pipeline we can generate significant synergy between the >>> projects: >>> >>> 1) Update Perl OpenGL to modern OpenGL (In progress by slowed >>> by the fact that my development time is spread too thin. >>> Am I the only one with a whole slew of projects for which >>> I know *exactly* what and how to do them but not having >>> the time to execute? :-) >>> >>> 2) Refactor PDL::Graphics::TriD to use modern OpenGL for >>> display rather than the fixed-function pipeline of OpenGL >>> API 1.x. >>> >>> 3) Update PDL to support (simply) the use of arbitrary >>> sources of data (e.g., I'm thinking framebuffer and >>> renderbuffer objects but deliberately being more >>> general since I could also imagine some sort of >>> generator that could act like a piddle for computation >>> with PDL). >>> >>> 4) Add GPGPU support to PDL computation. >>> >>> 5) Add support to the perl SDL2 interface to allow easy >>> mix and match operation with PDL for computation, IO, >>> and visualization. I could see PDL+GPGPU computing >>> working well with realtime game or display computations. >>> >>> Well, the above ideas have a some hand waving to make them >>> happen, but I think the pieces are there. >>> >>> Comments? >>> Chris
Re: SDL2 + POGL2 + PDL confluence
On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore wrote: > > I am definitely interested in helping with this. Perhaps we should make a > test module that tests just these integration. > > It will get latest branches of the 3 projects and run tests. > > What do you think? I'm glad to see the interest but most of the base work is still needing to be done as far as the OpenGL stuff. We need modern OpenGL support in POGL before a lot of the specific development can occur. However, one important piece that could be investigated is how we could make conversion between SDL2 objects and PDL objects work. Ideally we could have a fast conversion to take a piddle and use it for an SDL2 surface or texture or whatever and similarly for the other direction. Currently, the approach used for SDL is to create the PDL object with the right sized data segment and then pass that to SDL to make a surface from that. I'm not sure what would work for SDL2 stuff. --Chris > On Thu, Aug 15, 2013 at 1:11 PM, Chris Marshall > wrote: >> >> PDL/SDL/OpenGL users- >> >> With the recently announced SDL2 release and in-progress work >> to provide perl bindings for the same, I wanted to share my >> thoughts for leveraging joint capabilities of these three >> modules with a couple of specific points. >> >> 1) SDL2 brings integrated hardware acceleration via Direct3D and/or >> OpenGL to both 2D and 3D graphics. This offers the possiblity >> of using modern OpenGL API features like renderbuffers for >> computation and display. >> >> 2) PDL provides a high level array computation language that >> can be used as a back-end engine for SDL applications and >> visualization. The PDL::Graphics::TriD currently uses >> the OpenGL-1.x fixed pipeline interface. >> >> 3) Perl OpenGL currently supports the original fixed-pipeline >> display process of OpenGL-1.x and some 2.x functionality. >> Work is underway to update the support to modern OpenGL >> APIs such as OpenGL-3.x, OpenGLES,... >> >> The common thread here is OpenGL, and I think that by updating >> the OpenGL use and interfaces to the modern programmable display >> pipeline we can generate significant synergy between the >> projects: >> >> 1) Update Perl OpenGL to modern OpenGL (In progress by slowed >> by the fact that my development time is spread too thin. >> Am I the only one with a whole slew of projects for which >> I know *exactly* what and how to do them but not having >> the time to execute? :-) >> >> 2) Refactor PDL::Graphics::TriD to use modern OpenGL for >> display rather than the fixed-function pipeline of OpenGL >> API 1.x. >> >> 3) Update PDL to support (simply) the use of arbitrary >> sources of data (e.g., I'm thinking framebuffer and >> renderbuffer objects but deliberately being more >> general since I could also imagine some sort of >> generator that could act like a piddle for computation >> with PDL). >> >> 4) Add GPGPU support to PDL computation. >> >> 5) Add support to the perl SDL2 interface to allow easy >> mix and match operation with PDL for computation, IO, >> and visualization. I could see PDL+GPGPU computing >> working well with realtime game or display computations. >> >> Well, the above ideas have a some hand waving to make them >> happen, but I think the pieces are there. >> >> Comments? >> Chris
Re: SDL2 + POGL2 + PDL confluence
Hey Chris, I am definitely interested in helping with this. Perhaps we should make a test module that tests just these integration. It will get latest branches of the 3 projects and run tests. What do you think? On Thu, Aug 15, 2013 at 1:11 PM, Chris Marshall wrote: > PDL/SDL/OpenGL users- > With the recently announced SDL2 release and in-progress work > to provide perl bindings for the same, I wanted to share my > thoughts for leveraging joint capabilities of these three > modules with a couple of specific points. > 1) SDL2 brings integrated hardware acceleration via Direct3D and/or >OpenGL to both 2D and 3D graphics. This offers the possiblity >of using modern OpenGL API features like renderbuffers for >computation and display. > 2) PDL provides a high level array computation language that >can be used as a back-end engine for SDL applications and >visualization. The PDL::Graphics::TriD currently uses >the OpenGL-1.x fixed pipeline interface. > 3) Perl OpenGL currently supports the original fixed-pipeline >display process of OpenGL-1.x and some 2.x functionality. >Work is underway to update the support to modern OpenGL >APIs such as OpenGL-3.x, OpenGLES,... > The common thread here is OpenGL, and I think that by updating > the OpenGL use and interfaces to the modern programmable display > pipeline we can generate significant synergy between the > projects: > 1) Update Perl OpenGL to modern OpenGL (In progress by slowed >by the fact that my development time is spread too thin. >Am I the only one with a whole slew of projects for which >I know *exactly* what and how to do them but not having >the time to execute? :-) > 2) Refactor PDL::Graphics::TriD to use modern OpenGL for >display rather than the fixed-function pipeline of OpenGL >API 1.x. > 3) Update PDL to support (simply) the use of arbitrary >sources of data (e.g., I'm thinking framebuffer and >renderbuffer objects but deliberately being more >general since I could also imagine some sort of >generator that could act like a piddle for computation >with PDL). > 4) Add GPGPU support to PDL computation. > 5) Add support to the perl SDL2 interface to allow easy >mix and match operation with PDL for computation, IO, >and visualization. I could see PDL+GPGPU computing >working well with realtime game or display computations. > Well, the above ideas have a some hand waving to make them > happen, but I think the pieces are there. > Comments? > Chris
SDL2 + POGL2 + PDL confluence
PDL/SDL/OpenGL users- With the recently announced SDL2 release and in-progress work to provide perl bindings for the same, I wanted to share my thoughts for leveraging joint capabilities of these three modules with a couple of specific points. 1) SDL2 brings integrated hardware acceleration via Direct3D and/or OpenGL to both 2D and 3D graphics. This offers the possiblity of using modern OpenGL API features like renderbuffers for computation and display. 2) PDL provides a high level array computation language that can be used as a back-end engine for SDL applications and visualization. The PDL::Graphics::TriD currently uses the OpenGL-1.x fixed pipeline interface. 3) Perl OpenGL currently supports the original fixed-pipeline display process of OpenGL-1.x and some 2.x functionality. Work is underway to update the support to modern OpenGL APIs such as OpenGL-3.x, OpenGLES,... The common thread here is OpenGL, and I think that by updating the OpenGL use and interfaces to the modern programmable display pipeline we can generate significant synergy between the projects: 1) Update Perl OpenGL to modern OpenGL (In progress by slowed by the fact that my development time is spread too thin. Am I the only one with a whole slew of projects for which I know *exactly* what and how to do them but not having the time to execute? :-) 2) Refactor PDL::Graphics::TriD to use modern OpenGL for display rather than the fixed-function pipeline of OpenGL API 1.x. 3) Update PDL to support (simply) the use of arbitrary sources of data (e.g., I'm thinking framebuffer and renderbuffer objects but deliberately being more general since I could also imagine some sort of generator that could act like a piddle for computation with PDL). 4) Add GPGPU support to PDL computation. 5) Add support to the perl SDL2 interface to allow easy mix and match operation with PDL for computation, IO, and visualization. I could see PDL+GPGPU computing working well with realtime game or display computations. Well, the above ideas have a some hand waving to make them happen, but I think the pieces are there. Comments? Chris
