From: No I. <kii...@gm...> - 2012-04-15 23:07:06
|
Hello, I've been working on my GL refactor branch for the last few days, and I thought I was doing rather well, until I noticed that I wasn't testing what I thought I was testing. Much of the GL code is in StelPainter, from where I'm moving it gradually to my GL renderer implementation. Eventually my code stopped to compile and I noticed that the STELPAINTER_GL2 macro was not defined which meant GL1 StelPainter code was used (even though I was refactoring the GL2 code). So I defined STELPAINTER_GL2. As soon as I did that, I noticed that pretty much everything was broken (visually). I'm not going into details since I think this is most likely due to me doing something wrong. I thought this was due to my changes, so I started testing older revisions, and eventually the main branch, but found the same problem there, even about 500 revisions back (older revisions' builds were broken and didn't run) I encountered the same problem on Intel and NVidia binary (Linux) drivers, so I don't think it's a driver-specific bug. I came to the conclusion that I'm doing something wrong and I need something more than just STELPAINTER_GL2 for a GL2 build. Couldn't find anything on Google or the wiki, though. So, how are the GL2 builds compiled currently? What do I need to change other than setting the STELPAINTER_GL2 macro? FM |
From: Alexander W. <ale...@gm...> - 2012-04-16 13:56:59
|
Hello! I think Fabien can give to you more info but I try answer for you. 2012/4/16 No Idea <kii...@gm...>: > So, how are the GL2 builds compiled currently? Stellarium build with STELPAINTER_GL2 macro only for OpenGL ES (StelPainter.hpp:38). This key used for Maemo/Android ports. For desktop use a GL1+GL2 mode. Safe mode switch Stellarium to forced GL1 mode (main.cpp:269) -- With best regards, Alexander |
From: No I. <kii...@gm...> - 2012-04-16 19:09:49
|
I can see the STELPAINTER_GL2 is implied by USE_OPENGL_ES2, but I thought STELPAINTER_GL2 is also used for desktop GL2 builds. It seems to me that not enabling STELPAINTER_GL2 leaves no GL2 features at all. Wouldn't this mean that the desktop version code is purely GL1 feature-wise? FM On 4/16/12, Alexander Wolf <ale...@gm...> wrote: > Hello! > > I think Fabien can give to you more info but I try answer for you. > > 2012/4/16 No Idea <kii...@gm...>: >> So, how are the GL2 builds compiled currently? > > Stellarium build with STELPAINTER_GL2 macro only for OpenGL ES > (StelPainter.hpp:38). This key used for Maemo/Android ports. For > desktop use a GL1+GL2 mode. Safe mode switch Stellarium to forced GL1 > mode (main.cpp:269) > > -- > With best regards, Alexander > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Reaves, T. <tr...@si...> - 2012-04-16 19:19:02
|
Perhaps the need for refactoring now becomes more apparent? :) On Mon, Apr 16, 2012 at 3:09 PM, No Idea <kii...@gm...> wrote: > I can see the STELPAINTER_GL2 is implied by USE_OPENGL_ES2, > but I thought STELPAINTER_GL2 is also used for desktop GL2 builds. > > It seems to me that not enabling STELPAINTER_GL2 > leaves no GL2 features at all. Wouldn't this mean that the desktop version > code is purely GL1 feature-wise? > > FM > > On 4/16/12, Alexander Wolf <ale...@gm...> wrote: > > Hello! > > > > I think Fabien can give to you more info but I try answer for you. > > > > 2012/4/16 No Idea <kii...@gm...>: > >> So, how are the GL2 builds compiled currently? > > > > Stellarium build with STELPAINTER_GL2 macro only for OpenGL ES > > (StelPainter.hpp:38). This key used for Maemo/Android ports. For > > desktop use a GL1+GL2 mode. Safe mode switch Stellarium to forced GL1 > > mode (main.cpp:269) > > > > -- > > With best regards, Alexander > > > > > ------------------------------------------------------------------------------ > > For Developers, A Lot Can Happen In A Second. > > Boundary is the first to Know...and Tell You. > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > > Stellarium-pubdevel mailing list > > Ste...@li... > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: No I. <kii...@gm...> - 2012-04-27 23:16:21
|
I managed to get GL2 to work so I can continue. StelSkyDrawer has a bug in combination with StelPainter GL2 code if not using shaders. I also encountered a bug with point sprites on my GPU driver (Mesa, Intel Sandy Bridge, Linux), so I replaced those temporarily with triangles and rewrote their shader. That was so I could actually test code. On the refactor side, I'm trying to write the Renderer backends so that their initialization can gracefully fail, allowing other backend to be used as fallback. I'm planning the GL2 backend to always use shaders, while the GL1 backend will never use them. On a machine with buggy shaders, the GL2 backend should fail to initialize and be replaced with a GL1 backend. This should work even on Qt5, as AFAIK they're only removing support for GL1 context creation - GL1 backend should still work as long as the drivers advertise GL2 support (even if very buggy) - and if they don't, Qt5 won't run, either. (Removing GL1 support as in breaking all GL1 code doesn't make sense, since GL2 is just a small update over 1.5 (basically a 1.6), and you can't write GL2 code without writing GL1 code) The whole point is that a fallback from GL2 to GL1 backend should make more sense / be more maintainable than mixing shader-based and shader-less code based on conditions such as useShader. On 4/16/12, Reaves, Timothy <tr...@si...> wrote: > Perhaps the need for refactoring now becomes more apparent? :) > > > > On Mon, Apr 16, 2012 at 3:09 PM, No Idea <kii...@gm...> wrote: > >> I can see the STELPAINTER_GL2 is implied by USE_OPENGL_ES2, >> but I thought STELPAINTER_GL2 is also used for desktop GL2 builds. >> >> It seems to me that not enabling STELPAINTER_GL2 >> leaves no GL2 features at all. Wouldn't this mean that the desktop version >> code is purely GL1 feature-wise? >> >> FM >> >> On 4/16/12, Alexander Wolf <ale...@gm...> wrote: >> > Hello! >> > >> > I think Fabien can give to you more info but I try answer for you. >> > >> > 2012/4/16 No Idea <kii...@gm...>: >> >> So, how are the GL2 builds compiled currently? >> > >> > Stellarium build with STELPAINTER_GL2 macro only for OpenGL ES >> > (StelPainter.hpp:38). This key used for Maemo/Android ports. For >> > desktop use a GL1+GL2 mode. Safe mode switch Stellarium to forced GL1 >> > mode (main.cpp:269) >> > >> > -- >> > With best regards, Alexander >> > >> > >> ------------------------------------------------------------------------------ >> > For Developers, A Lot Can Happen In A Second. >> > Boundary is the first to Know...and Tell You. >> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> > http://p.sf.net/sfu/Boundary-d2dvs2 >> > _______________________________________________ >> > Stellarium-pubdevel mailing list >> > Ste...@li... >> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > >> >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > |
From: Fabien C. <fab...@go...> - 2012-04-27 23:47:39
|
Hi Ferdinand, sorry for the no reply to your previous email, I was in holidays! On Sat, Apr 28, 2012 at 01:16, No Idea <kii...@gm...> wrote: > I managed to get GL2 to work so I can continue. > > StelSkyDrawer has a bug in combination with StelPainter GL2 code if > not using shaders. > I also encountered a bug with point sprites on my GPU driver > (Mesa, Intel Sandy Bridge, Linux), so I replaced those temporarily > with triangles and rewrote their shader. The impact of using point stars was not very important but there was one on small devices like the Nokia N900. > That was so I could actually test code. On the refactor side, I'm trying to > write the Renderer backends so that their initialization can gracefully > fail, allowing other backend to be used as fallback. > I'm planning the GL2 backend to always use shaders, > while the GL1 backend will never use them. > > On a machine with buggy shaders, the GL2 backend should fail > to initialize and be replaced with a GL1 backend. If understand well, you plan to replace the useShader boolean by a mechanism of inheritance. Although this is fine for generic rendering operations currently in StelPainter, I am a bit wondering what you plan to do with the shader code which in some case is very specialized (like rendering stars). Do you also plan to move it in a generic class like StelQGL2Renderer and an equivalent method using GL1 in StelQGL2Renderer? If you do that the StelXRenderer classes will end up containing a bunch of unrelated rendering routines like rendering of stars, atmosphere etc.. which more naturally fit into the dedicated StelSkyDrawer and StelAtmosphere classes. I know it's a bit a pain but I think it's cleaner to keep those in their respective files. > This should work even on Qt5, as AFAIK they're only removing support for > GL1 context creation - GL1 backend should still work as long as the drivers > advertise GL2 support (even if very buggy) - and if they don't, Qt5 > won't run, either. I see. > (Removing GL1 support as in breaking all GL1 code doesn't make sense, > since GL2 is just a small update over 1.5 (basically a 1.6), and you can't write > GL2 code without writing GL1 code) > > The whole point is that a fallback from GL2 to GL1 backend should make more > sense / be more maintainable than mixing shader-based and shader-less code > based on conditions such as useShader. It's fine for me. > > > On 4/16/12, Reaves, Timothy <tr...@si...> wrote: >> Perhaps the need for refactoring now becomes more apparent? :) >> >> >> >> On Mon, Apr 16, 2012 at 3:09 PM, No Idea <kii...@gm...> wrote: >> >>> I can see the STELPAINTER_GL2 is implied by USE_OPENGL_ES2, >>> but I thought STELPAINTER_GL2 is also used for desktop GL2 builds. >>> >>> It seems to me that not enabling STELPAINTER_GL2 >>> leaves no GL2 features at all. Wouldn't this mean that the desktop version >>> code is purely GL1 feature-wise? >>> >>> FM >>> >>> On 4/16/12, Alexander Wolf <ale...@gm...> wrote: >>> > Hello! >>> > >>> > I think Fabien can give to you more info but I try answer for you. >>> > >>> > 2012/4/16 No Idea <kii...@gm...>: >>> >> So, how are the GL2 builds compiled currently? >>> > >>> > Stellarium build with STELPAINTER_GL2 macro only for OpenGL ES >>> > (StelPainter.hpp:38). This key used for Maemo/Android ports. For >>> > desktop use a GL1+GL2 mode. Safe mode switch Stellarium to forced GL1 >>> > mode (main.cpp:269) >>> > >>> > -- >>> > With best regards, Alexander >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > For Developers, A Lot Can Happen In A Second. >>> > Boundary is the first to Know...and Tell You. >>> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> > http://p.sf.net/sfu/Boundary-d2dvs2 >>> > _______________________________________________ >>> > Stellarium-pubdevel mailing list >>> > Ste...@li... >>> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>> > >>> >>> >>> ------------------------------------------------------------------------------ >>> For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> _______________________________________________ >>> Stellarium-pubdevel mailing list >>> Ste...@li... >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>> >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: No I. <kii...@gm...> - 2012-04-28 20:38:07
|
> The impact of using point stars was not very important but there was > one on small devices like the Nokia N900. I'd like to refactor with a minimal set of features first, and only then look into that. Any such slowdown might be caused by 2 triangles being drawn on the GPU instead of a point sprite, but just as likely might be caused by the code that generates the triangles, which could be optimizable, or a part of it could be moved onto the GPU. Either way, I'd like to consult a profiler before doing any of that. Also, if only mobile devices are affected, it might be possible to make any needed optimizations for the GLES backend, if that will make sense. > > If understand well, you plan to replace the useShader boolean by a > mechanism of inheritance. Although this is fine for generic rendering > operations currently in StelPainter, I am a bit wondering what you > plan to do with the shader code which in some case is very specialized > (like rendering stars). Do you also plan to move it in a generic class > like StelQGL2Renderer and an equivalent method using GL1 in > StelQGL2Renderer? > > If you do that the StelXRenderer classes will end up containing a > bunch of unrelated rendering routines like rendering of stars, > atmosphere etc.. which more naturally fit into the dedicated > StelSkyDrawer and StelAtmosphere classes. I know it's a bit a pain but > I think it's cleaner to keep those in their respective files. > > I definitely don't plan to move that into Renderer implementations. Initially, I'd like to keep most of that code outside Renderer but move its GL-related parts into Renderer, which would require Renderer interface to be flexible enough to handle it. If that doesn't work, it can be implemented in classes _used_ by Renderer that would have their own implementations for each Renderer backend. Renderer also might end up having specialized functions for very specific drawing tasks if that is unavoidable, but I'd like to keep as much of that code as possible outside, and whatever must be done inside would be done in separate classes used by Renderer. I don't want 2000-line classes. Basically, I'd like to create a clean separation between Graphics classes here - Main Stellarium code here. (i.e. StelGL2SkyDrawer, etc.). I'm not yet sure which way I'll do it. That's why I'm experimenting with it, to get a better idea (I still don't have a complete idea about Stellarium codebase). FM |
From: Fabien C. <fab...@go...> - 2012-04-28 22:51:35
|
On Sat, Apr 28, 2012 at 22:37, No Idea <kii...@gm...> wrote: >> The impact of using point stars was not very important but there was >> one on small devices like the Nokia N900. > > I'd like to refactor with a minimal set of features first, and only then look > into that. Any such slowdown might be caused by 2 triangles being drawn > on the GPU instead of a point sprite, but just as likely might be caused > by the code that generates the triangles, which could be optimizable, > or a part of it could be moved onto the GPU. Either way, I'd like to > consult a profiler before doing any of that. > > Also, if only mobile devices are affected, it might be possible to make > any needed optimizations for the GLES backend, if that will make sense. I think the GL2 renderer should be also GLES compatible. GLES is just a subset of GL2 (which is an abusive name for all GL implementation which supports shaders) >> If understand well, you plan to replace the useShader boolean by a >> mechanism of inheritance. Although this is fine for generic rendering >> operations currently in StelPainter, I am a bit wondering what you >> plan to do with the shader code which in some case is very specialized >> (like rendering stars). Do you also plan to move it in a generic class >> like StelQGL2Renderer and an equivalent method using GL1 in >> StelQGL2Renderer? >> >> If you do that the StelXRenderer classes will end up containing a >> bunch of unrelated rendering routines like rendering of stars, >> atmosphere etc.. which more naturally fit into the dedicated >> StelSkyDrawer and StelAtmosphere classes. I know it's a bit a pain but >> I think it's cleaner to keep those in their respective files. >> >> > > I definitely don't plan to move that into Renderer implementations. > > Initially, I'd like to keep most of that code outside Renderer but move its > GL-related parts into Renderer, which would require Renderer interface to > be flexible enough to handle it. Good. I think that is somehow what Qt people spent years of coding efforts on with the Qt3D stuff. You should really have a very detailed look at it before going very far in your own implementation. There is a good chance that most of the tedious work is already done there. Don't be afraid to use it if necessary. > If that doesn't work, it can be implemented in classes _used_ by Renderer > that would have their own implementations for each Renderer backend. > > Renderer also might end up having specialized functions for very > specific drawing > tasks if that is unavoidable, but I'd like to keep as much of that > code as possible > outside, and whatever must be done inside would be done in separate classes > used by Renderer. I don't want 2000-line classes. > > Basically, I'd like to create a clean separation between > Graphics classes here - Main Stellarium code here. > > (i.e. StelGL2SkyDrawer, etc.). OK. > I'm not yet sure which way I'll do it. That's why I'm experimenting with it, > to get a better idea (I still don't have a complete idea about > Stellarium codebase). Feel free to ask me questions! Fab > FM > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: No I. <kii...@gm...> - 2012-04-29 21:58:26
|
> I think the GL2 renderer should be also GLES compatible. GLES is just > a subset of GL2 (which is an abusive name for all GL implementation > which supports shaders) Isn't this only the case with GL4? Or are the differences insignificant / is Qt3D able to hide them without special casing? I don't have any GLES experience unfortunately. Also, is there a convenient way to test GLES code on the desktop? > Good. I think that is somehow what Qt people spent years of coding > efforts on with the Qt3D stuff. You should really have a very detailed > look at it before going very far in your own implementation. There is > a good chance that most of the tedious work is already done there. > Don't be afraid to use it if necessary. I plan to use Qt3D (since those are QGL, not plain GL, backends), but I don't want it to be part of the interface - that should be backend-independent (so that even non-GL backends are possible - e.g. someone on the IRC mentioned they would like to have a PostScript backend). > Feel free to ask me questions! I will ask when needed. Unfortunately I only work on it about 1 day per week at the moment as I'm still attending university. FM |
From: Brady B. <br...@br...> - 2012-04-29 22:09:39
|
You can get GLES 2 emulators which you can build against and that translate the calls to normal OpenGL, though I've had no experience with them. GLES2 is like GL with all of the deprecated fixed-function things outright removed. On Apr 29, 2012 2:58 PM, "No Idea" <kii...@gm...> wrote: > > I think the GL2 renderer should be also GLES compatible. GLES is just > > a subset of GL2 (which is an abusive name for all GL implementation > > which supports shaders) > > Isn't this only the case with GL4? > Or are the differences insignificant / is Qt3D able to hide them > without special > casing? I don't have any GLES experience unfortunately. > > Also, is there a convenient way to test GLES code on the desktop? > > > Good. I think that is somehow what Qt people spent years of coding > > efforts on with the Qt3D stuff. You should really have a very detailed > > look at it before going very far in your own implementation. There is > > a good chance that most of the tedious work is already done there. > > Don't be afraid to use it if necessary. > > I plan to use Qt3D (since those are QGL, not plain GL, backends), > but I don't want it to be part of the interface - that should be > backend-independent > (so that even non-GL backends are possible - e.g. someone on the IRC > mentioned they would like to have a PostScript backend). > > > > Feel free to ask me questions! > > I will ask when needed. Unfortunately I only work on it about 1 day per > week > at the moment as I'm still attending university. > > > FM > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |