GLdc - Call for testers!

[kazade]

Hi everyone!

Over the last few months I've been maintaining a custom fork of libGL, but a few weeks ago I hit a corruption bug that I couldn't solve and decided to essentially tear the whole thing apart and put it back together again

So, now it's *mostly* back together and it lives here: https://github.com/Kazade/GLdc

There are still outstanding features to implement, so I'm not recommending people just blindly switch over, but I would really appreciate if people could try it, and report bugs on GitHub (or even better, send me patches!)

There are a lot of bug fixes in this version compared to libGL, and it adheres more to the spec. The one thing you will need to do is swap glutSwapBuffers with glKosSwapBuffers.

[lerabot]

Shoutouts to Kazade for working on this.
We've been chatting quite a bit about this project and I've been using it for Reaperi Cycle.

It's been working quite well so far. We've both been testing different stuff with, my project being in 2D and using glOrtho and kazade's test being 3D.

[MetaFox]

Sorry for the lateness in seeing this. I've been toying with some GL stuff, and I've recently gotten into Dreamcast again, so I'm excited to see improved libGL support on the Dreamcast.

I'll try to it with a few of my different prototypes once I get a DC toolchain up on my MacBook, as this is my main computer now.

Thanks for this library, Kazade, and thanks for DreamPi too - I just recently ordered a premade DreamPi kit from dreamcastlive.com, so I'll be playing with that too once I get it.

[Corbin]

Late to the party, as usual :S

I am _definitely_ interested in helping test and shape GLdc kazade! Right now we are using libGL (for Slave, Hypertension, and EDGE/DOOM/etc in general) and, well, while it definitely is a great GL library, it has room for improvements. It is nicer and closer to real GL, but it doesn't seem quite as stable as something older, like KGLX (also, we have to modify the internal vert counts in gl_pvr.h [from 1024*64 -> 1024*16][ everytime we rebuild the toolchain for libGL, otherwise we run out of RAM really quick. I don't remember having to do that for other GL libraries..


Let me know what I can do, my engine is pure OpenGL so I would be very happy to test and report results for you @kazade! Please get in touch with me via PM or email!

[kazade]

Well GLdc is ready for use aside from the caveats listed in the README and the issues here: https://github.com/Kazade/GLdc/issues

I've basically done the hard-slog 80% but need help to get the final 20% done. The key missing feature you'll probably find is multitexturing isn't there yet, neither is mipmapping (but then I'm fairly sure libGL mipmapping would trash memory anyway...)

Feel free to try compiling it and using it and let me know if anything doesn't work - the GLdc code is easy to follow so you should be able to figure out any bugs fairly quickly

For what it's worth, I don't have masses of time for this and coded GLdc out of necessity (for another project) so I'd really appreciate some help with it - filing issues or submitting patches is the best way to do that

[lerabot]

+1 for everyone willing to use GLdc. Kazade has been very active in making this work and pushing new updates.

[Rizzoislandgame]

For those using windows subsystem for linux, these are the installation instructions:
1. go into your kos/addons folder and git clone GLdc into it
2.

make defaultall

3.

make create_kos_link

4. put headers into you programs include folder

[BlueCrab]

@kazade:
As GLdc gets more and more feature-complete, how would you feel about us including it officially as the GL library going forward in kos-ports? Do you think it is mature enough now, and if not, any estimates as to when it will be?

[kazade]

I think it might be an idea to ship it in kos-ports alongside libGL (e.g. libGLdc + /usr/include/GLdc/gl.h). Simply because it will avoid ambiguity of which version someone is using, and also, GLdc won't be exactly compatible (it has different header constants and glKosSwapBuffers() instead of glut etc.)

But yes, I'd be very happy if GLdc became part of kos-ports - the only real blocker to that is multitexture support. It won't take me long to add multitexturing, I just haven't gotten around to it. I'll try to get to that next!

I'd also like to know how performant it is compared to libGL so if someone has a relatively intensive GL scene they could try it on and compare I'd appreciate it.

[BlueCrab]

It could certainly be the case that both are shipped as part of kos-ports, although, I'd probably avoid calling the resulting .a file (or the include directories for that matter) different things. The idea is that your library would probably be "the" library going forward, once any further kinks are worked out. If I were to rename one, it'd probably be PH3NOM's library, since it would essentially be deprecated by yours.

Also, I wouldn't necessarily call multitexture support a blocker, as no version of GL that was available in kos-ports or the addons tree up until PH3NOM's supported it.

There are other things that could potentially be blockers, but that all is probably better served to be discussed after I take a look at the code first. Probably highest amongst the many things that could potentially be considered blockers is pollution of the global namespace with functions that aren't prefixed in any way... By that, I mean internal functions that you can't make static for whatever reason. I recall there being quite a few of them before PH3NOM's libgl went in, so I'm expecting your library probably has a bunch of stuff like that too (just based on how all of it has to fit together in the end). When PH3NOM did his libgl, I asked him to prefix any internal functions that couldn't be made static with "_glKos" or similar, to make sure to not potentially trample on names someone else might want to use for a function in their own code. The underscore prefix makes it obvious that they're meant to be internal, and the glKos part makes sure it doesn't trample so much on the global namespace.

Another potential blocker would be porting over example programs and whatnot, but that's not as much of an issue until we get closer to a KOS release.

[lerabot]

For those using windows subsystem for linux, these are the installation instructions:
1. go into your kos/addons folder and git clone GLdc into it
2.

make defaultall

3.

make create_kos_link

4. put headers into you programs include folder

This also works for people on linux.

Don't forget to go

Code: Select all

cd GLdc

between step 1 and 2

[kazade]

Cool, OK I'll make sure I prefix non static functions with _gl. I've got a bug to fix in lighting, and then I'll shove in multitexture support.

I could really use someone who understands the SH4/PVR to look over my code and suggest performance improvements. At the moment:

- I only send polygon headers if necessary
- I perform each step (e.g. transform, clip, perspective divide etc.) in a separate loop to avoid using up floating point registers
- I try not to switch loaded matrix unless necessary
- I'm trying to minimise hand coded ASM and trust the compiler
- I only ever send triangle strips, I dunno if there's some flag or something when sending plain triangles that might speed things up?

Is DMA faster than using store queues? I'm currently using store queues for submission.

[BlueCrab]

Cool, OK I'll make sure I prefix non static functions with _gl. I've got a bug to fix in lighting, and then I'll shove in multitexture support.

Cool. Keep me posted.

I could really use someone who understands the SH4/PVR to look over my code and suggest performance improvements. At the moment:

- I only send polygon headers if necessary

Reasonable.

- I perform each step (e.g. transform, clip, perspective divide etc.) in a separate loop to avoid using up floating point registers

Not sure on this one, especially considering how many iterations it might need to be run over...

- I try not to switch loaded matrix unless necessary

Definitely a good idea.

- I'm trying to minimise hand coded ASM and trust the compiler

Often trying to optimize things and be more clever than the compiler blows up in people's faces, so this is probably a good idea, especially before doing any sort of hard analysis of things to determine where the compiler might need more help.

- I only ever send triangle strips, I dunno if there's some flag or something when sending plain triangles that might speed things up?

Nope. The PVR doesn't really do just plain triangles. There's specialized quads that cut down on the amount of data being sent, but no specialized "general" triangles.

Is DMA faster than using store queues? I'm currently using store queues for submission.

That largely depends on how your handling things. DMA isn't necessarily "faster", but you can do it in the background while you're doing other things, whereas with the store queues, the transfer can't be done completely in the background in a large batch (the actual transfers can/do happen in the background, but you still need to load up the SQ for each 32 byte transfer, unlike with DMA where it does all the work for you). One benefit of the SQs are that you don't have to go through the extra step of flushing the operand cache to memory before doing things, and you can potentially write the results of your final transformations directly into the SQ (rather than to memory) to speed things along a slight bit.

[kazade]

Interesting, thanks!

I don't suppose you know how I can view the compiled ASM for a function? I could really do with being able to see what functions are being compiled down to.

[BlueCrab]

Run kos-cc -E on your files, like this:

Code: Select all

kos-cc -E filename.c -o filename.s

[Corbin]

@kazade:

Since EDGE is OpenGL heavy, and uses things like lighting and multi-texturing, I'll be sure to keep up to date and report any performance and/or other issues we might have.

I plan on switching this library out today inside KOS at work, and tomorrow I should be completely free to integrate and test with SLaVE/Hypertension/EDGE.

[kazade]

Excellent! I've made good progress on multitexture, just need to write a good test sample for it and then fix up any breakage.

*Update*

Just pushed a completely untested multitexture implementation. I'll test and improve tomorrow.

https://github.com/Kazade/GLdc/commit/6 ... e2d0bfcb82

[KingCrazy]

Okay I'm going to sound like a real doofus right now, but...

4. put headers into you programs include folder

What folder am I supposed to put the headers into? By "program's include folder " do you mean kos/include, kos/addon/include, an include folder within my project, or some other include folder?

I tried a couple of combinations, but when I went to go run the make files for the samples I was getting undefined references for almost every GLdc function.

Edit: Pretty sure the latter issue was because I didn't include it in the makefile. Oops. First part of the question still stands, though, considering I'm not sure how to specify if I'm using libGL or GLdc when including/compiling.

Sorry if this is a stupid question!

[lerabot]

Okay I'm going to sound like a real doofus right now, but...

4. put headers into you programs include folder

What folder am I supposed to put the headers into? By "program's include folder " do you mean kos/include, kos/addon/include, an include folder within my project, or some other include folder?

If you cloned the lib in kos/addons/, all you have to do is add

Code: Select all

#include <GL/gl.h>

and link using

Code: Select all

-lGLdc

Or at least, that's what I did

[Corbin]

@kazade: Any chance we could get support to handle paletted textures?

For our games and the engine, it would really help us save VRAM.