OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Hardware => Topic started by: tj81 on 2009.11.07, 18:17:06

Title: OpenGL ddk
Post by: tj81 on 2009.11.07, 18:17:06
Hi, all. If this post is in the wrong place or inappropriate, please remove accordingly. I'm trying to  collect info on opengl and display programming (sourcecode, etc) and am trying to find the OS/2 Hardware Device Driver Toolkit (openglddk). Searches online seem to suggest it is rarer than hen's teeth. The relevant OS/2 yahoo groups of the day seem to now be defunct. As the toolkit is now effectively abandonware, is it possible that anyone on these forums has this file that they can provide or can point me to it's location, by PM if necessary.  Any assistance would be greatly appreciated.
Thanks, TJ.
Title: Re: OpenGL ddk
Post by: Pete on 2009.11.07, 18:53:16
Hi TJ

Maybe this page will be of use http://www.os2site.com/sw/dev/opengl/index.html

Regards

Pete
Title: Re: OpenGL ddk
Post by: miturbide on 2009.11.09, 16:49:51
Hi TJ81

you can search at hobbes for some OpenGL documentation and examples.
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/doc/OpenGL

or to get the last patch (old)
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/system/patches

But what are you seaching for?
Do you want to create an application with OpenGL ?

If you want to share you findings or create an OpenGL tutorial feel free to use the OS2World.com Wiki.
http://www.os2world.com/wiki/

Martin
Title: Re: OpenGL ddk
Post by: rwklein on 2009.11.09, 17:55:17
If you look around on the internet or ask some people you can still get a copy of the Open GL DDK from IBM. With this you can have the closest example of how to make a Open GL driver for OS/2.

For Mensys (eComStation) about 6 years ago I tried to get permission from IBM to get a license on the DDK. At the time you needed to pay $25.000 for a license to Silicon Graphics, IBM could then pass a license to you. However Silicon Graphics had given the license for other platforms free. The status of the OS/2 version was unclear (from what I can remember).

Ever since the Open GL DDK for OS/2 was never officially released at it hangs in a legal no mansland.

Its realy the question if its worthwhile to do anything with this old stuff if you can get a copy of the beast. A lot of OS/2 developers got a copy because it was once on a public IBM FTP server.

You would have more luck with Mesa library and start from scratch there. Maybe the Open GL DDK is usefull to see how to hook into the GRADD subsystem.

Roderick Klein
Mensys
Title: Re: OpenGL ddk
Post by: rwklein on 2009.11.09, 17:59:53
I forgot to add that Open GL DDK is very old. And thats why you might want to consider to use the MESA library.
Its at the level of Open GL 1.1. So how usefull it would be is the question.

Roderick Klein
Mensys
Title: Re: OpenGL ddk
Post by: tj81 on 2009.11.10, 18:58:17
Thanks for the replies and apologies for the delay in response. Had a quick peruse of those sites, but due to access restrictions at this public library, I can't peek into some of the archives, at the moment, to verify their contents. What I'm really after, for a starter, I suppose, is the gengradd sample driver source code. I believe the openglddk has source for the glintgradd (or is it gligradd?) driver. My laptop has recently gone down but somehow I'll overview the resources at the links provided and see if I find the glintgradd info. Roderick, you are correct, hooking into GRADD is initially my area of interest. Thanks again for the quick responses, TJ.
Title: Re: OpenGL ddk
Post by: jep on 2009.11.11, 09:05:58
Hi tj81,

would you try to write a hardware accelerated driver (OpenGL)?

//Jan-Erik
Title: Re: OpenGL ddk
Post by: lpino on 2009.11.11, 14:47:23
Thanks for the replies and apologies for the delay in response. Had a quick peruse of those sites, but due to access restrictions at this public library, I can't peek into some of the archives, at the moment, to verify their contents. What I'm really after, for a starter, I suppose, is the gengradd sample driver source code. I believe the openglddk has source for the glintgradd (or is it gligradd?) driver. My laptop has recently gone down but somehow I'll overview the resources at the links provided and see if I find the glintgradd info. Roderick, you are correct, hooking into GRADD is initially my area of interest. Thanks again for the quick responses, TJ.
Even though many people here thinks that the effort to support such an old version of OpenGL it's a waste of time, in my view, trying to develop a hardware accelerated driver would be a very important thing for OS/2.

Just my two cents.

Title: Re: OpenGL ddk
Post by: rwklein on 2009.11.11, 15:36:45
I'm not stating its not useful to develop a open gl hardware driver for OS/2.

What might be a waste of time is using the old open GL portion from the Open GL DDK from IBM, since its based on OpenGL 1.1.(with some digging you should be able to find it on the internet :-))  One purpose I could think of is it would be easier to port Linux applications to OS/2 and then you need an up to date Open GL backend.

I don't know how it like these days but Open GL and Linux is also still messy last time I looked. With that I mean vendors don't make API's public (what else is new :-)). Some vendors have open source drivers others not.
Writing a driver I understood from an Open GL developer can also be a big job.

One thing to look at for software based open gl is:

http://www.mesa3d.org/systems.html

Roderick
Title: Re: OpenGL ddk
Post by: magog on 2009.12.16, 15:23:38
Hi, all. If this post is in the wrong place or inappropriate, please remove accordingly. I'm trying to  collect info on opengl and display programming (sourcecode, etc) and am trying to find the OS/2 Hardware Device Driver Toolkit (openglddk). Searches online seem to suggest it is rarer than hen's teeth. The relevant OS/2 yahoo groups of the day seem to now be defunct. As the toolkit is now effectively abandonware, is it possible that anyone on these forums has this file that they can provide or can point me to it's location, by PM if necessary.  Any assistance would be greatly appreciated.
Thanks, TJ.

Hi, it's a little bit late but if you still need some information about the Hardware DDK, you can first read this post from two years ago:
http://www.os2world.com/component/option,com_smf/Itemid,63/topic,515.msg2485/#msg2485

If you need the Hardware Accelerated OpenGL DDK...look into your inbox. ;)



Moderator Note: If you cannot see the above link, please copy and paste this one into your browser window:
http://www.os2world.com/forum/index.php/topic,515.msg2485.html#msg2485 (http://www.os2world.com/forum/index.php/topic,515.msg2485.html#msg2485)

Code: [Select]
http://www.os2world.com/forum/index.php/topic,515.msg2485.html#msg2485
Title: Re: OpenGL ddk
Post by: lpino on 2009.12.16, 21:54:58
Hi, all. If this post is in the wrong place or inappropriate, please remove accordingly. I'm trying to  collect info on opengl and display programming (sourcecode, etc) and am trying to find the OS/2 Hardware Device Driver Toolkit (openglddk). Searches online seem to suggest it is rarer than hen's teeth. The relevant OS/2 yahoo groups of the day seem to now be defunct. As the toolkit is now effectively abandonware, is it possible that anyone on these forums has this file that they can provide or can point me to it's location, by PM if necessary.  Any assistance would be greatly appreciated.
Thanks, TJ.

Hi, it's a little bit late but if you still need some information about the Hardware DDK, you can first read this post from two years ago:
http://www.os2world.com/component/option,com_smf/Itemid,63/topic,515.msg2485/#msg2485

If you need the Hardware Accelerated OpenGL DDK...look into your inbox. ;)

Can I be included in your mail delivery list ;)

Bye
Title: Re: OpenGL ddk
Post by: magog on 2009.12.17, 01:46:15

If you need the Hardware Accelerated OpenGL DDK...look into your inbox. ;)

Can I be included in your mail delivery list ;)

Bye

No problem you should also find something in your inbox (PDF Docs + DDK files).
I forgot to include a link to the main DDK files for the two other guys who asked about the DDK but that file is also there in the same directory. An updated mail is on it's way.
Title: Re: OpenGL ddk
Post by: alex on 2009.12.17, 11:46:24
Can I also be included in your mail delivery list? ;)

Thx
Title: Re: OpenGL ddk
Post by: magog on 2009.12.17, 20:52:46
Can I also be included in your mail delivery list? ;)
Thx

Done...see inbox.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.19, 18:23:52
If you look around on the internet or ask some people you can still get a copy of the Open GL DDK from IBM. With this you can have the closest example of how to make a Open GL driver for OS/2.

For Mensys (eComStation) about 6 years ago I tried to get permission from IBM to get a license on the DDK. At the time you needed to pay $25.000 for a license to Silicon Graphics, IBM could then pass a license to you. However Silicon Graphics had given the license for other platforms free. The status of the OS/2 version was unclear (from what I can remember).

Ever since the Open GL DDK for OS/2 was never officially released at it hangs in a legal no mansland.

Its realy the question if its worthwhile to do anything with this old stuff if you can get a copy of the beast. A lot of OS/2 developers got a copy because it was once on a public IBM FTP server.

You would have more luck with Mesa library and start from scratch there. Maybe the Open GL DDK is usefull to see how to hook into the GRADD subsystem.

Roderick Klein
Mensys


Is this topic still open? Has anyone found a viable solution to implementing hardware accelerated OGL drivers for OS/2? If so, I'm VERY interested in the process & techniques. Also, if possible, could someone send me a copy of the DDK? I'm interested in developing an OGL subsystem for a possible OS/2 clone. Thanks!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.22, 15:34:17
Ok, here's what I've learned (other than the fact that IBM's OpenGL ddk is horribly out of date! lol):

1. It really doesn't seem as though they ever finished implementing this ddk.

2. This ddk is really high level & expects the driver implementation to do all of the heavy lifting (understandably).

3. As with most development of that time period, there's too much reliance on global variables; this may cause issues with smp code if not done correctly; may be a major source of the threading limitations.

4. Completely replaceable; this was not true in the past, because IBM was still actively working on OS/2; the danger was in a new version coming out that could make an alternate OGL driver implementation incompatable, that's not an issue now days, since IBM has dropped OS/2.

5. The only real knowledge in the kit that's worth knowing is how the OGL drivers are supposed to communicate with the 2d GRADD drivers; it's interesting learning how they implemented pgl, however, it's almost the exact same as xgl with a few hints thrown in from wgl, so it's implementation is also completely replaceable.

6. It's very obvsious of the history of this port, it still remains very AIX-centric, while pasting OS/2 into it.

7. It's unclear to me of whether it would be a better idea to attempt to use this ddk or just work on creating a new one.



I'm going to set up an OS/2 box & put together a build environment. While I'm doing that, I'm going to try to figure out what the best course of action is. Ideas include:

1. Try to use this ddk while making note of things that could be done better or could be completely removed from it.

2. Try to create an open source replacement of this ddk, with no IBM IP.

3. Try to finish & improve this ddk & possibly resubmit it to IBM, while keeping my fingers crossed.



Any comments or ideas guys?
Title: Re: OpenGL ddk
Post by: cyberspittle on 2010.10.22, 15:42:12
I would prefer option #1, but my vote is for #2, as there are a lot of resources already on the internet.

Try to create an open source replacement of this ddk, with no IBM IP.
Title: Re: OpenGL ddk
Post by: cytan on 2010.10.22, 15:52:39
I would prefer option #1, but my vote is for #2, as there are a lot of resources already on the internet.

Try to create an open source replacement of this ddk, with no IBM IP.


I second that.

cytan
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.22, 15:53:18
To be honest, that gallium3d stuff that the Mesa3d & DRI/DRM guys are doing looks pretty nice. It's a bit too new, though. It's also taking me a while to get a thorough understanding of the source of DRM so I can port it to non-*nix platforms. I was trying to use it for Syllable, but there seems to be too much *nix crap in it & it seems like a better idea to just implement something more simple & tailored for Syllable. The same may be true for OS/2. In the long run, I'm working on an open source alternative to OS/2 (no, not osfree) & I'd love to create something that I could use on OS/2 until the time comes to port it over to my project.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.22, 18:40:29
One major question that needs asking is, "Has anyone released AGP support for OS/2?".
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.23, 03:50:10
I guess we 3 are the only ones left who still care enough to want this to happen. I guess I'll be going with option 2 & try to do a full rewrite. Performance still won't be as good, without proper agp support. Also, I think I'll focus on getting a software render up & running before I push on to hardware. The hardware driver for the new ddk will probably be something low like maybe a matrox 450 or something like that or maybe a SiS 6326.
Title: Re: OpenGL ddk
Post by: cytan on 2010.10.23, 04:10:19
I guess we 3 are the only ones left who still care enough to want this to happen. I guess I'll be going with option 2 & try to do a full rewrite. Performance still won't be as good, without proper agp support. Also, I think I'll focus on getting a software render up & running before I push on to hardware. The hardware driver for the new ddk will probably be something low like maybe a matrox 450 or something like that or maybe a SiS 6326.

Good luck! Perhaps the ddk can also work on a low end ATI Radeon card?
Title: Re: OpenGL ddk
Post by: jep on 2010.10.23, 07:07:00
I guess we 3 are the only ones left who still care enough to want this to happen. I guess I'll be going with option 2 & try to do a full rewrite. Performance still won't be as good, without proper agp support. Also, I think I'll focus on getting a software render up & running before I push on to hardware. The hardware driver for the new ddk will probably be something low like maybe a matrox 450 or something like that or maybe a SiS 6326.

Ohh, no, you're not the last 3 people on the planet left.  ;D
AGP? PCI-E that we use now then?
_______

A driver with hardware acceleration tied to some of the newer OGL ES or ... be nice.
Would WarpOverlay goes OpenGL be something?
Title: Re: OpenGL ddk
Post by: Saijin_Naib on 2010.10.23, 19:39:32
Did Scitech ever open-source any part of the DisplayDoctor drivers like they said they were going to?

Pretty sure that had AGP acceleration support.

I am very interested in seeing OS/2 support OpenGL as that opens up a ton of options for games, multimedia software, and important academic software.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.24, 06:00:01
Good luck! Perhaps the ddk can also work on a low end ATI Radeon card?

Thanks. That shouldn't be an issue. I think that I have an old Radeon laying around, so I might be able to pull it off.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.24, 06:07:57
Ohh, no, you're not the last 3 people on the planet left.  ;D
AGP? PCI-E that we use now then?
_______

A driver with hardware acceleration tied to some of the newer OGL ES or ... be nice.
Would WarpOverlay goes OpenGL be something?

Good, I'd hate to be attempting this for nothing.

I'm more worried about the gart that comes with agp, not necessarily the bus itself.  With that in mind, I haven't read up on PCI-E, so I'm not sure what all would come with that. However, both of these standards are just extensions of the baselevel PCI spec, so in theory, all one would have to do is add the functionality to the PCI bus driver that's already there. Though, I'm not sure that IBM released much about it's PCI bus driver.

I don't know much about WarpOverlay, maybe someone else could add that enhancement to the mix. At this point, I'm really only worried about getting a working framework up. I'm sure that someone else will improve my work down the road.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.24, 06:13:46
Did Scitech ever open-source any part of the DisplayDoctor drivers like they said they were going to?

Pretty sure that had AGP acceleration support.

I am very interested in seeing OS/2 support OpenGL as that opens up a ton of options for games, multimedia software, and important academic software.

I'm not sure, however, keep in mind that all AGP devices are really PCI devices. The only real importance that AGP bring are the ability of the bridge & the card to agree on the level of speed/support and the gart that allows 3d cards drivers to take advantage of a bit of extra memory. Since the Scitech drivers were 2d, then I would imagine that they didn't do much more than get the bus part of the AGP spec up and running; I doubt that they took the time to write an agpgart driver to handle the memory aspect. I've written an AGP layer that included an agpgart driver for another os, but I'm just not sure how to accomplish the same thing for OS/2. I guess this will be quite an experience for everyone involved!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.24, 06:50:47
So, here's the basic plan:

Interfaces:

Geometry interface: pgl -> pipeline (OPENGL.DLL -> GLPIPELINE.DLL)
Raster interface: pipeline -> raster driver (GLPIPELINE.DLL -> GLRASTER.DLL)
Context interface: pgl -> raster driver (OPENGL.DLL -> GLRASTER.DLL)
GRADD interface: raster driver -> gradd driver (GLRASTER.DLL -> GRADD system (via VMAN))
PDD interface: ppd <-> gradd driver (when necessary)

OPENGL.DLL:

All this really consists of is the pgl codebase. With the pgl.h header that's included with the openwatcom package, I should have all that I need for a starting point. I'll grab as much as I can about PGL from all available sources & put together a PGL module that's able to load a graphics pipeline driver. PGL does not implement any of the OpenGL spec, it's imported from GLPIPELINE.DLL; so this will be the easiest part of the ddk. Still hard, just easy in relativity to the other parts. The device independent portion of context management lives here.

GLPIPELINE.DLL:

IBM's version of this is simply called GLPIPE.DLL. This is the part of the spec that covers the geometry part of the OpenGL spec. This part of the ddk will be very generic. It is an implementation of the gl library, however, it' s implementation is swappable for driver writers who'd like to provide a more hardware specific version. In fact, any implementation of the OpenGL spec can be used here as long as it interfaces correctly with the rest of the ddk.

GLRASTER.DLL:

IBM's version of this is simply called RASTER.DLL. As you can guess, this part of the driver covers the rasterization process. For drivers that are only capable of rasterization, it is sufficient to replace the standard GLRASTER.DLL with a more hardware specific version. The hardware version must use the provided interfaces to communicate with OPENGL.DLL, & GLPIPELINE.DLL. In the absence of a hardware accelerated version, a software version will be used. The device specific portion of context management lives here.


Those are the basic guidelines that I'm starting with.
Title: Re: OpenGL ddk
Post by: Tellie on 2010.10.24, 10:12:19
Hihi,

I wish you all the best and keeps fingers crossed that you will succeed :P

I will gives us more options, to use it for porting other software :)
Title: Re: OpenGL ddk
Post by: StefanZ on 2010.10.24, 15:02:16
Also wish you lots of luck, strong nerves and huge amounts of free time!
Unfortunately I'm more Pascal programmer, not C, otherwise I would offer my help in this.

I cannot wait to get my hands on GL/2 framework with i.e. SDL :)
Title: Re: OpenGL ddk
Post by: cytan on 2010.10.24, 20:12:08
One suggestion is to use the svn on netlabs for your work. Maybe others might be interested to help you out.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.24, 21:45:55
One suggestion is to use the svn on netlabs for your work. Maybe others might be interested to help you out.

Sounds reasonable enough. After I have something worth putting up, I'll look into that. If that's a bust, I'll probably end up at sourceforge.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.25, 03:36:38
Funny thing happened while I was looking through the OpenGL spec trying to separate commands into groups of interfaces between the components of the new GL/2. I realized that some of the commands that'll be linked into pgl actually go to the raster, which means that pgl will have to talk directly to both the pipeline & the raster. I guess the deeper you go, the more you learn about the flaws in your initial line of thinking. Lesson learned.

Also, I decided to go ahead & use version 4.0 of the OpenGL spec. If this goes correctly (which we all hope it does), I would imagine that it would be used for a long time & what better way to help future-proof it than to use the newest spec available. Besides, by the time this is fully functional, I expect more platforms to be using OGL 4.0.

It looks like version 2.0 is about the time that GLSL was entering the picture & becoming part of the standard, so it looks like I have no choice but to try to find a way to fit the shading language into the mix. Hopefully, when the time comes, there will be someone in the OS/2 community who has some ideas of how to create the shading units & help integrate them into this codebase.

In an earlier post, someone refurred to OpenGL on OS/2 as GL/2. For a lack of a better name, I think I'll just stick with that name.
Title: Re: OpenGL ddk
Post by: cyber on 2010.10.25, 14:01:06
There is no better name than GL/2.  :D
Title: Re: OpenGL ddk
Post by: djcaetano on 2010.10.25, 15:19:50
In an earlier post, someone refurred to OpenGL on OS/2 as GL/2. For a lack of a better name, I think I'll just stick with that name.

  Great name, indeed. :)
  Man, I believe most members on OS/2 community are now crossing their fingers, hoping for any development on this arena. There were many developments on important areas such as ACPI, QT, UniAud, Panorama, Samba, Flash and even Java; these are great to keep us alive, up to date... and adding real OpenGL stuff to this set of improvements will be awesome because we've been waiting for this support for almost 15 years!

   My best wishes and my kindest regards!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.25, 15:24:17
I've been such a fool. I hope no one will be pissed at me, especially since the actual GL library is loadable by pgl, but I'm going to use TinyGL as my GL implementation. It's been sitting here staring me in the face the whole time. I'm also going to build upon earlier work that I was doing in regards to adding hardware acceleration to it. This is the fastest course of action. It also removes us from all of the *nix cruft code that are in other *nix centric implementation.
Title: Re: OpenGL ddk
Post by: cyber on 2010.10.25, 15:52:48
  Man, I believe most members on OS/2 community are now crossing their fingers, hoping for any development

I do not want to be rude, but I do not believe that Demetrious can do that. Anyway, if hi is "the One", will this bring any improvement to existing applications, or we must wait to (no)one develop new apps which will be able to use this... and after all that... there is bunch of other problems/2 that wait for years to be fixed. Being /2 user so many years just lead to hmmmm... distrust ? that there is future for anything relative to /2 and new hardware in same sentence.   :'(

Demetrious, do not think that this text is offensive in any way, I'm really sorry that I can not help in any way, because my knowledge of programing is just at same level as my knowing knitting and crocheting.  :-\
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.25, 17:36:50
I do not want to be rude, but I do not believe that Demetrious can do that. Anyway, if hi is "the One", will this bring any improvement to existing applications, or we must wait to (no)one develop new apps which will be able to use this... and after all that... there is bunch of other problems/2 that wait for years to be fixed. Being /2 user so many years just lead to hmmmm... distrust ? that there is future for anything relative to /2 and new hardware in same sentence.   :'(

Demetrious, do not think that this text is offensive in any way, I'm really sorry that I can not help in any way, because my knowledge of programing is just at same level as my knowing knitting and crocheting.  :-\

No worries, man. I'll be the first to admit that this is a long shot. However, all through the years, everyone (including me) just kind of sat on our hands while OS/2 was being neglected. Other OS's got advancements & yet, nothing for OS/2. Is this deserving behavior towards an OS that started off as one of the most advanced OSes available to the general public? No, I don't think so. And yet, when these things started happening to other OSes, the users took matters in their own hands & made it their personal responsibility to ensure that their platform wouldn't die without a serious fight. But that wasn't necessarily the case for OS/2. There was the initial begging & demanding for OS/2 to be released as open source. When that failed, everyone just accepted it with a tear in their eyes. Sure, a few people released drivers for this video card or that sound card. But far & few in between were the guys that decided to tackle the system components knowing that no one else would do it for them. And when another company stepped forth, to fill the void, everyone cheered; never pausing to consider what would happen if this new company stopped producing it's OS/2 derivative. As long as we resign ourselves to be at the mercy of come company, we'll always live in fear of losing OS/2. Time is moving forward & it's carrying technology with it. We're going to have to take the responsibility of making sure that OS/2 is able to keep up. But, work like this is always an uphill battle & it can't be fought by just one man. Hopefully, the simple fact that someone is attempting to do something, will inspire others to do the same. If not, then it means that we didn't really deserve OS/2 & it was fate that took it away from us. Now, the bar for success is pretty low right now. To be honest, all I really have to do is prove that it can be done & that, in itself, will be success. But I think that we can both agree that our community deserves more than that. The *nix guys shouldn't be the only ones that are capable of rolling their own 3d graphics stack. Throughout the past couple of decades, many individuals have proved that it's possible to do so. We have the numbers & we have the ability, so lets take control of our futures. So, here's the challenge to everyone: If this thing succeeds, I challenge you to do something to contribute to the cause. It doesn't have to be coding, it could be something as simple as spreading the word. It could be as simple as writing documentation. If you have friends who're developers, convince them to consider developing for OS/2. Whatever it takes, whatever form it takes, I challenge you to do something, anything to contribute. Does that sound fair?

Sorry for the long post, I really needed to get that out.
Title: Re: OpenGL ddk
Post by: ivan on 2010.10.25, 21:26:51
Quote
Whatever it takes, whatever form it takes, I challenge you to do something, anything to contribute. Does that sound fair?

More than fair.

When you manage to get working code I'll write the documentation for it - I've been writing tech docs for years - plus, I have several units here that have a collection of ATI video cards, stand alone and integrated,  if you want test beds.

ivan
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.25, 22:38:56
More than fair.

When you manage to get working code I'll write the documentation for it - I've been writing tech docs for years - plus, I have several units here that have a collection of ATI video cards, stand alone and integrated,  if you want test beds.

ivan

That sounds wonderful! In the mean time, I'll work on getting the code to at least compile & execute. When that's up & running, I'll be looking for feedback on functionality.
Title: Re: OpenGL ddk
Post by: cyber on 2010.10.26, 08:14:34
This is to far optimistic. How can I trying to convince people to use /2 ?
First, they need to rob museum to got hardware that will working.
Second, they need to raise from average_idiot_home_user level just to install damn' thing.
Third, they need to pay for not just OS it self (even old one W4), they need to pay even for OOo which is on all other platform free program.
Then, there will me more problems, when buy new hdd larger than 500 Mb, when try to use printer wich is not from museum, when try to copy data from ordinary flash stick, to watch videos from Youtube, when try to backup data from smartphone...

Even I am a fanatic OS/2 user, I do not want to slipped other people to. There is alternatives, free of charge, wich isn't beautiful like /2, but work with any hardwer, and work with much less problems and faster.  :'(
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.26, 15:19:44
This is to far optimistic. How can I trying to convince people to use /2 ?
First, they need to rob museum to got hardware that will working.
Second, they need to raise from average_idiot_home_user level just to install damn' thing.
Third, they need to pay for not just OS it self (even old one W4), they need to pay even for OOo which is on all other platform free program.
Then, there will me more problems, when buy new hdd larger than 500 Mb, when try to use printer wich is not from museum, when try to copy data from ordinary flash stick, to watch videos from Youtube, when try to backup data from smartphone...

Even I am a fanatic OS/2 user, I do not want to slipped other people to. There is alternatives, free of charge, wich isn't beautiful like /2, but work with any hardwer, and work with much less problems and faster.  :'(

You're right, I agree with you 100%. Which is why it's more important than ever for us to take control & reimplement OS/2 on our own. How many other communities must we sit back & watch while they set the example before we catch the hint & learn from their example? Do you think it was easy reimplementing OpenGL, Unix, Windows, BeOS, or DOS? It couldn't have been easy at all & yet we have Mesa3d, Linux, *BSD, ReactOS, Haiku, & FreeDOS. Reimplementing established systems is never easy, but it must be done. If you're not a developer, that's ok. But there's no need to discourage others from heeding the call. Others will take care of providing the technology, you just make sure you're there to use it & spread the word. Now, surely, that's fair.
Title: Re: OpenGL ddk
Post by: djcaetano on 2010.10.26, 15:24:32
Even I am a fanatic OS/2 user, I do not want to slipped other people to. There is alternatives, free of charge, wich isn't beautiful like /2, but work with any hardwer, and work with much less problems and faster.  :'(

  Cyber, I believe every single OS/2 user is concerned about the future and how
to keep things going. Of course there are many obstacles to be beaten, but the
only way to get over them is one by one.
  While basic hardware support is gold, Serenity and other individuals have been
working on it for years... and more advancements are in the pipeline.
   That doesn't mean we do not need support for not-so-essential-technologies.
OGL support seems cosmetic, only for bells and whistles... but it's not. When
saying this will be just one more piece of not used library, keep in mind that SDL
should have support for OpenGL; it has not due to limitations on the available
alternatives at this moment. With a working and up-to-date SDL GL support,
several games would be available, and that would be even better if it is hardware
accelerated.

    If it is difficult to bring new users to eCS-OS/2, it can be even more difficult to
keep them using it when we do not even have the ability to run 3D applications or
even present him with a nice-looking operating system. Most advanced users
(not the lemming type) believe OS/2 is very advanced in the way it works and
in the way we use it, but they also think it looks like outdated and the support for
new technologies is non-existent. Something has to be done in this arena.

    Besides all I said previously, there is a new generation of monitors capable
of 3D which would never be reliably supported without a real 3D rendering stack.

    This is the reason I believe this effort is worth the community support. I do not
think it is a simple project but... even if the project fail, the effort shows at least
that our community will not fall without a fight. :)
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.26, 17:47:00
djcaetano: well spoken.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.26, 20:33:10
Here's an update:

Gotten TinyGL to compile into GLPIPELINE.dll.

Abstracted buffer code so that any renderer implementation will be able to provide it's own buffer support or let GLPIPELINE.dll default to one of the 2 internal buffer systems (either DIVE or system memory).

Implemented glGetError. It was already lacking from TinyGL.

Added function pointer table to GLContext to hold renderer's hooks.

Added void pointer to GLContext to point to renderer's private context data.


Next step:

Use TinyGL's rendering system to create internal version of GLRASTER.

Target internal renderer to use DIVE surfaces for buffers.

Fall back to rendering to buffers backed by system memory if DIVE is unavailable.

Implement code to load GLRASTER.dll, if available. Fall back to internal renderer if GLRASTER.dll is unavailable.


Next, next step:

Begin work on OPENGL.dll (PGL).
Title: Re: OpenGL ddk
Post by: Saijin_Naib on 2010.10.26, 20:36:57
Nice. Forgive the possibly noob question, but what will the end result of this be?

A OpenGL software renderer, or possibly an OpenGL hardware renderer?
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.26, 20:40:24
Nice. Forgive the possibly noob question, but what will the end result of this be?

A OpenGL software renderer, or possibly an OpenGL hardware renderer?

Questions are always good! The end result will be hardware rendering with a software rendering fallback if the drivers haven't been written for your video card yet.
Title: Re: OpenGL ddk
Post by: Saijin_Naib on 2010.10.26, 20:51:18
That is fantastic! This opens up the door for a ton of Linux and windows software (running with Odin/WINE) to work, as well as many academic applications.

Now for cards supported by SNAP (which has hardware accel, correct), this OpenGL implementation you're writing would interface with that?
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.26, 21:01:49
That is fantastic! This opens up the door for a ton of Linux and windows software (running with Odin/WINE) to work, as well as many academic applications.

Now for cards supported by SNAP (which has hardware accel, correct), this OpenGL implementation you're writing would interface with that?

To be honest, I don't know all that much about SNAP from a coding & organizational standpoint. My code will talk directly to GRADD drivers through the VMAN interface, however, basic GRADD drivers will have to be modified in order to understand what the GL/2 driver is asking for. Unless you have an updated GRADD driver, you won't be able to take advantage of hardware accelerated GL/2. Once I start working on the first hardware drivers & get it up & running, I'll have the API for the communication between the GRADD & GLRASTER.dll. But that's a bit down the road for now. Right now, there's the matter of getting GLPIPELINE feature complete (including GLSL support), completing OPENGL.dll, creating an installer, & figuring out what I want to put into config.sys.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.30, 14:21:53
DeviceCreateBitmap()
DeviceDeleteBitmap()
DeviceSelectBitmap()
GetBitmapBits()
SetBitmapBits()

These 5 functions are PM hooks that will either be implemented by the PM display driver or fallback to the PM if the driver does not implement them. Does anyone know more about these functions? I'm wondering if I should just use these functions for GL buffers, or continue to view them as fallbacks. If the driver implements them, then they should already be accelerated, if not, then it would be any different from normal software buffers. The only difference would be the fact that there's less code to right & we'd be able to use GL/2 without modifying GRADD drivers.
Title: Re: OpenGL ddk
Post by: warpcafe on 2010.10.30, 15:26:47
Hi demetrioussharpe,

there are only 2 persons I know of who have experience in "native DDK" stuff with regards to graphics AND who are still more or less active in developing software for OS/2|eCS are either Ruediger ("Rudi") Ihle the author of Emperoar ... or Peter Koller, the author of Maul publisher.
Rudi is also active here on OS2World.com ... perhaps either one of them can give you more insight on the internals of graphics stuff or have "better" documentation - but I'm not sure.

HTH,
Thomas
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.30, 19:38:13
Hi demetrioussharpe,

there are only 2 persons I know of who have experience in "native DDK" stuff with regards to graphics AND who are still more or less active in developing software for OS/2|eCS are either Ruediger ("Rudi") Ihle the author of Emperoar ... or Peter Koller, the author of Maul publisher.
Rudi is also active here on OS2World.com ... perhaps either one of them can give you more insight on the internals of graphics stuff or have "better" documentation - but I'm not sure.

HTH,
Thomas

Thanks for the reply. I've stubbed out the interface between the pipeline & the raster. The direction that I'm going is for driver implementers to implement the raster interface if they just want to reuse the TinyGL pipeline or to implement the pipeline with it's own raster (as one set package if necessary). If implementers have a better pipeline that's more integrated with the hardware, there's no problem at all. OPENGL.dll will focus on loading just the pipeline, so there's no need to worry about using the included raster interface. The raster interface is most useful with the included pipeline. Does anyone have any additional insight or comments?
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.30, 20:31:02
I can use DosLoadModule(), but I guess there's no way to unload modules from a running system. There seems to be no signs of DosUnloadModule() or something similar.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.10.30, 20:35:48
I can use DosLoadModule(), but I guess there's no way to unload modules from a running system. There seems to be no signs of DosUnloadModule() or something similar.

Nevermind, I'm supposed to use DosFreeModule().
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.09, 04:03:20
Does anyone know of an opensource 3d rendering library? Something very small & light. I only need something that can plot points, lines, & triangles. It needs to output to a generic buffer. It needs to be in C (not C++ or anything else). And preferably licensed under BSD or some other non-viral license. The drawing system for TinyGL is incomplete & I really don't have all year to be dicking around trying to create a whole new system when there's probably one that suits the need already out there. This will form the basis of the software renderer for GL/2. Until I can find a suitable replacement, I'm going to halt work on the software system & move over to pgl (OPENGL.dll) & then shift over to the hardware driver. I should probably go ahead & push the software driver out into it's own project. Maybe GLSOFTRASTER.dll.
Title: Re: OpenGL ddk
Post by: warpcafe on 2010.11.09, 12:01:16
Hi,

you are so much more into this topic than anyone else around I guess... so forgive me if I'm telling rubbish, also you may already have checked them out on the internet, but anyways... FWIW, here's what I found. Perhaps it helps or gives a starting point for further searches:

http://sourceforge.net/projects/glide/
http://www.ogre3d.org/about
http://www.genesis3d.com/index.php   (looks abandoned though)
http://g3d.sourceforge.net/
http://lightfeather.de/content.php?content.10

Some (if not most) of the above are C++ though. Sorry, I didn't check in detail before posting.
Anyway... HTH,
Thomas
Title: Re: OpenGL ddk
Post by: cytan on 2010.11.09, 14:31:21
Don't forget that CAIRO has already been ported to OS/2 and written in C. But it's 2D.

cytan
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.09, 15:46:56
Hi,

you are so much more into this topic than anyone else around I guess... so forgive me if I'm telling rubbish, also you may already have checked them out on the internet, but anyways... FWIW, here's what I found. Perhaps it helps or gives a starting point for further searches:

http://sourceforge.net/projects/glide/
http://www.ogre3d.org/about
http://www.genesis3d.com/index.php   (looks abandoned though)
http://g3d.sourceforge.net/
http://lightfeather.de/content.php?content.10

Some (if not most) of the above are C++ though. Sorry, I didn't check in detail before posting.
Anyway... HTH,
Thomas

Thanks for the response. I've looked at most of them & they are a bit too big. Truth be told, my biggest hickup is line drawing. I need a line drawing algorithm that can optionally interpolate the color between 2 points, the z component between 2 points, & is capable of doing both at the same time if necessary.

Don't forget that CAIRO has already been ported to OS/2 and written in C. But it's 2D.

cytan


I've been looking at Cairo, but I'm not sure that I'm completely comfortable with the MPL license. I know that the LGPL license can also be used for it, but I'm not really comfortable with the possible code pollution that could cause the rest of the code to be sucked into LGPL land.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.13, 23:54:55
 IBM's spec for pglSwapBuffers  states:

"The window specified by hwnd does not have to be currently bound to an OpenGL context; it needs only to have been bound at some point. This function has no effect on a PM window that has never been bound to an OpenGL context. "

I'm changing this a bit. Since a context can only be bound to one window at a time, the window specified by hwnd MUST be currently bound to an OpenGL context. If it is not, then pglSwapBuffers is a no-op. This should not cause too much of an issue, since pglSwapBuffers should be called to swap the buffers of a window that contains the current context. Afterall, why would you swap the buffers of a context that isn't current? Also, my implementation stores the buffers in the context, not in the window. Even if there are applications that rely on the specified behavior, I doubt that there are many of these apps that're going to be relevant going forward. If anyone has any issues or reservations about this change, please let me know.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.23, 03:56:07
Does anyone know how to copy a font into a bitmap? The GPI functions seem to be missing that functionality lol
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.23, 04:11:45
I created a sourceforge project for GL/2. I have to work on the homepage & upload the source code for OPENGL.dll(pgl). I sent an email to netlabs to ask about hosting my project there, but I didn't get a response & got tired of waiting, so sourceforge it is. I'm going with svn for the code repo.
Title: Re: OpenGL ddk
Post by: jep on 2010.11.24, 09:53:13
Draw something (line, font, square or...) into a hps, then grab it and use the resulting bitmap.
Title: Re: OpenGL ddk
Post by: Joachim on 2010.11.24, 11:03:44
I created a sourceforge project for GL/2. I have to work on the homepage & upload the source code for OPENGL.dll(pgl). I sent an email to netlabs to ask about hosting my project there, but I didn't get a response & got tired of waiting, so sourceforge it is. I'm going with svn for the code repo.

Hi Dee,

that is unfortunate. It would be preferable to keep 'everything' at Netlabs SVN but I understand your urge to move forward.
Would you mind posting the SourceForge URL here?

Thanks,

Joachim
Title: Re: OpenGL ddk
Post by: ktk on 2010.11.24, 11:11:32
I sent an email to netlabs to ask about hosting my project there, but I didn't get a response & got tired of waiting, so sourceforge it is. I'm going with svn for the code repo.

Hmm I checked my inbox for both your name and the topic OpenGL but I really can't find any mail from you asking for a repo. When did you send that where? I don't delete emails and I really can't remember that I got asked for an OpenGL repo.
Title: Re: OpenGL ddk
Post by: warpcafe on 2010.11.24, 13:14:22
Would you mind posting the SourceForge URL here?

...http://sourceforge.net/projects/gl2/

;) Thomas
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.24, 15:47:31
Draw something (line, font, square or...) into a hps, then grab it and use the resulting bitmap.

Thanks, I didn't even consider that. Though, that's the technique I'm trying to use for pglUseFont(). However, the issue that I'm running into is how to grab the resulting bitmap. Though, it looks like I may have found the GPI function to accomplish this. If I'm correct, I'll be able to use that technique in GLRASTER.dll as you suggested.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.24, 15:53:27
I sent an email to netlabs to ask about hosting my project there, but I didn't get a response & got tired of waiting, so sourceforge it is. I'm going with svn for the code repo.

Hmm I checked my inbox for both your name and the topic OpenGL but I really can't find any mail from you asking for a repo. When did you send that where? I don't delete emails and I really can't remember that I got asked for an OpenGL repo.

I sent the email on 4 Nov 10 to ktk@netlabs.org. The subject of it is:  GL/2 - OpenGL DDK hosting. I figured that you were busy with other OS/2 & eCS plans and just didn't have time to respond.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.24, 15:57:06
I'm checking all of the code to ensure that the proper licenses are included at the top of the files. My initial checkin should happen before the end of tonight. I'm on US-Central time, so your timing may vary. If time permits, I maybe be complete much earlier.
Title: Re: OpenGL ddk
Post by: abwillis on 2010.11.24, 18:12:32
I'm checking all of the code to ensure that the proper licenses are included at the top of the files. My initial checkin should happen before the end of tonight. I'm on US-Central time, so your timing may vary. If time permits, I maybe be complete much earlier.
Considering you have now heard from Adrian, I would humbly submit that it would be preferable to work with him and set the project on Netlabs rather than sourceforge considering that no files have been uploaded yet.
Andy
Title: Re: OpenGL ddk
Post by: ktk on 2010.11.24, 18:20:38
I sent the email on 4 Nov 10 to ktk@netlabs.org. The subject of it is:  GL/2 - OpenGL DDK hosting. I figured that you were busy with other OS/2 & eCS plans and just didn't have time to respond.

Hmm just checked that day, can't find your email, sorry. My spam-folder deletes automatically after one week so I can't check anymore if it showed up there.

Anyway if you want one I will for sure help, if you stay with SF no bad feelings so just let me know what you prefer.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.24, 19:17:11
I'm checking all of the code to ensure that the proper licenses are included at the top of the files. My initial checkin should happen before the end of tonight. I'm on US-Central time, so your timing may vary. If time permits, I maybe be complete much earlier.
Considering you have now heard from Adrian, I would humbly submit that it would be preferable to work with him and set the project on Netlabs rather than sourceforge considering that no files have been uploaded yet.
Andy

That would indeed be preferable. I really have little time to set up all of the crazy little features of SF or even as much as a homepage. Maybe I'll do a short write up of the project one day.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.24, 19:18:24
I sent the email on 4 Nov 10 to ktk@netlabs.org. The subject of it is:  GL/2 - OpenGL DDK hosting. I figured that you were busy with other OS/2 & eCS plans and just didn't have time to respond.

Hmm just checked that day, can't find your email, sorry. My spam-folder deletes automatically after one week so I can't check anymore if it showed up there.

Anyway if you want one I will for sure help, if you stay with SF no bad feelings so just let me know what you prefer.

Ok, sounds good. How do we proceed? My email address is my screen name here at netscape dot net.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.26, 06:46:28
In lieu of netlabs access, I've uploaded the current sources of GL/2 to the sourceforge repo. Access to netlabs is in the works; once it's been granted to me, I will upload the codebase to that repo. What's included in the codebase so far is:

All of the headers in my development tree, courtesy of the openwatcom group.
OPENGL.dll, which resides in the pgl directory.

To compile this code, you will have to place the codebase into a directory, then update the openwatcom project include path to point to the include folder that comes with the gl2 checkout.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.26, 10:13:26
Just so it's understood, my OPENGL.dll is not compatible with IBM's pipeline or raster components. Until my pipeline & raster components are uploaded, my OPENGL.dll will be useless. But the code is there for viewing. I'll work on pglUseFont() in the next few days & commit the changes to the repo.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.11.27, 21:20:36
Learned about a feature of openwatcom that I wasn't aware of before. I'll be reorganizing the tree within the coming days. It'll be easier to insert the GLU library into OPENGL.dll.
Title: Re: OpenGL ddk
Post by: craigm on 2010.12.03, 22:17:15
I'm so excited to hear that this is moving forward, I think OpenGL support for eCS is so important to the OS's health as a viable platform. Thank you!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.07, 22:02:32
I'm so excited to hear that this is moving forward, I think OpenGL support for eCS is so important to the OS's health as a viable platform. Thank you!

Thanks for your enthusiasm towards this project. That's the kind of feedback that keeps me going when I think my tank's on 'E' for the night; it's greatly appreciated!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.07, 22:37:57
Things have been a bit slow for the past few days. It's the holiday season & I'm also winding down my Army career, so it's safe to say that 'Real Life' issues have drained quite a bit of my time. However, here's a small update:

-I've received the info necessary to host this project on Netlabs.
-I've been in the process of updating my commiting tree with code from my sandbox tree.
-When the commiting tree is completely up to date & I've pushed all of the code to sourceforge, I will do a final svn checkout to make sure that my tree is correctly revisioned. That's when I will commit it all to Netlabs & shutdown the sourceforge tree.
-I have successfully built the GLU library as a lib file & included it into the OPENGL.dll project file.
-I have added a GLU function pointer table within PGLContext. This will make it much easier if there comes a time in the future when another GLU library, that's more robust, is created.
-My PGL is almost feature complete with IBM's PGL. Here's the summary of what needs to be finished:

---pglWaitPM() currently has no way to check to make sure that the presentation manager is finished drawing to the viewing area of the window before it returns.
---pgl_internal.[c|h] needs functionality that allows PGL to be able to subclass the window & service specific window messages. It also needs an internal clean up system to register to the Exit system. This will allow PGL to do clean up regardless of whether a program was ended  normally or by force.
---pglUseFont() still needs to be implemented.
---pglUsePMBitmapFont() was depreciated by IBM, so my implementation is well within reason by just returning FALSE. However, I'd like to go ahead & implement it properly for indirect contexts anyway.
---pglMakeCurrent() when a context has been bound to a window for the first time, pglMakeCurrent() needs to attach cleanup routine to program, subclass the window to allow handling of specific window message, get window bounds, & set the viewport to bounds values.


So, I'm a long ways off from where I've started. I've also gained a few ideas for additions to PGL that will not use the standard 'pgl' API format, but will still prove themselves valuable. One such idea is to insert a thin portion of a profiling system within PGL. There would also need to be companion portions within the pipeline & the video driver. This will not only allow me to better understand the choke points through the entire system for a total implementation optimization effort. It will also give developers more insight into which pathways their apps are spending the majority of their time in. Work on this may or may not be started before I start fleshing out the actual pipeline.

I'd like to thank everyone who's given me their support. I will continue make summary reports as time permits.
Title: Re: OpenGL ddk
Post by: Ben on 2010.12.08, 00:05:44
The OS/2 community really, is a marvel in that it is still so solid... yet so small... as is the OS itself.

This is a testament to the quality of its original design and its implementation. With regard to that aspect of it, IBM did an outstanding job.

I personally, still love the power and the ease of use, the way that programs still fit snugly into their own, respective, folder and thus, are completely transportable; Simply archiving and unarchiving of said folder onto whatever machine, and creating a Program Object for it is enough; All done. How many other OSes can claim that?

Still, it would be wrong to say that OS/2 hasn't suffered the fate of an orphaned child having been in too many foster homes; it's now an amalgam of many different-and-varied, ideas and is the bastard child that everyone loves to feel fickle about. But still there is the core pseudo-family that will not give up on it! And keeps it alive and mostly healthy.

But some appendages have become atrophied and at risk of becoming vestigial; And despite Darwin's unprovable and wildly speculative, claims about things becoming, evolutionarially, vestigial for a reason, in my opinion, this can never be good and certainly isn't now.

To continue, it's hardly necessary to say it, but your infusion of fresh, and powerful, blood has been quietly hoped for. And I,  though I am only one, represent, (if unofficially), a train of others who are holding their breath wondering if it isn't all just a little bit too much to expect, and too good to last... for some future thoughts are more pleasant than others. And there have been many er... attempts... in the past... accompanied by many powerful words!

However... while your words are many, they are quickly followed by aggressive, and positive, action... (which is potentially, one of the finer characteristic of military training).

Whichever way that Fate follows, I'd like to say a thoughtful "thank-you" for your efforts. My skills are not in programming so I can only stand outside the work area and applaud; and I am applauding now.

Thank-you.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.08, 00:24:29
I've gotta admit, that was quite an overwhelming post! I suppose, I'm used to the actions of 1 person being mostly dismissed at a local level & usually unnoticed at a global level. Such is the way it is in military life. This feels largely new to me. Thanks for your kind words!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.10, 20:38:10
Ok, it looks like I've hit a little snag. I'll be the first to admit that I don't know a whole lot about using SVN. I've been able to get along by using TortoiseSVN, since I've been doing the actual development on my Win box. Now, it's time to push the GL/2 repo over from sourceforge to netlabs. I'm at a complete loss at how to accomplish this with all of my version info & commit history intact. Is there anyone keeping track of this forum topic who knows how to accomplish such a thing? Any help would be greatly appreciated!
Title: Re: OpenGL ddk
Post by: diver on 2010.12.10, 23:07:49
i'm not sure if it's easy to have history and such intakt.
but best would be you ask in #netlabs channel on irc.freenode.net

regards
Silvan
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.14, 00:54:23
Adding pglGetProcAddress() to the pgl layer. Windows users know it as wglGetProcAddress(). It allows developers to use new functions that are not in the system's default OpenGL installation, but are included either in a chip-specific implementation or as an extension.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.15, 02:42:31
Here's an update:

- The codebase at sourceforge is at revision 39.

- Work's in progress to insure that revision 39 is brought up on netlabs.

- I've sent the rsync drop to Adrian as a tarball via email.

- I've reorganized the split between the GL library & the hardware driver; there's no longer a pipeline/raster split, it's all pipeline with the split being lib/hardware; all of this now lives in the pipeline directory, since all drivers that'll be part of the default install will interface to this library. All of this is in my local repo & will be committed once netlabs' repo is up.

- PGL will look for 2 environmental variables; most likely, the names will be GLDEFAULTLIBRARY & GLALTERNATELIBRARY. These variables must be defined in config.sys for usage. GLDEFAULTLIBRARY is the GL library that's part of this DDK & must never be changed. GLALTERNATELIBRARY is the library used if a hardware-specific GL library needs to be loaded. PGL will look for GLALTERNATELIBRARY first & if it's not defined, then PGL will fall back to GLDEFAULTLIBRARY.

- GLDEFAULTLIBRARY will look for 2 environmental variables; most likely, they will be named GLSOFTRENDERER & GLHARDRENDERER. GLSOFTRENDERER will be the software driver that comes with this DDK. It's not a must that it's not changed to point to another software implementation, but I'll ask that it not be changed. If someone comes up with I ask that they contribute to the official codebase. GLHARDRENDERER will point to the hardware driver for the currently installed videocard. As such, it should be changed each time the hardware changes. I am considering doing a massive hardware renderer that uses the correct card-specific routines depending on which card is installed.

I know that some of what I just posted kinda goes without saying, I just wanted to go ahead & write those things down anyway just to make my intent official.

Comments, concerns, gripes, or complaints?
Title: Re: OpenGL ddk
Post by: David McKenna on 2010.12.15, 14:23:26
<Comments, concerns, gripes, or complaints?>

  Only to thank you for this exciting (and important IMHO) contribution to eCS! I'm really looking forward to being able to use it.

  Thanks!

Regards,

Dave McKenna
Title: Re: OpenGL ddk
Post by: Sigurd on 2010.12.15, 14:39:54
<Comments, concerns, gripes, or complaints?>

  Only to thank you for this exciting (and important IMHO) contribution to eCS! I'm really looking forward to being able to use it.

  Thanks!

Regards,

Dave McKenna

So do I!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.15, 17:35:01
Thanks for the support guys, it really means a lot!

Does anyone know how to find out if the PM & GPI pipelines have finished drawing everything in their pipeline?

Also, while I'm waiting for netlabs, I've started working on the library's gl rendering pipeline.
Title: Re: OpenGL ddk
Post by: RobertM on 2010.12.17, 19:58:43
It really means a lot to us! It's the few highly dedicated people like you, Remy, the eCoSoft and Firefox Teams, Paul and others that are helping keep things going for this community, and your work is definitely appreciated!!!

No luck on the books yet, btw (haven't forgotten about you). I do have at least two more boxes I have to get out of storage though. I suspect they may be in one of them (since I have yet to find any of my OS/2 programming references - and I suspect I packed them all in the same place). I am hoping I'll find them in the upcoming week... been swamped with work though, and haven't managed to dig the last few boxes out.

Rob
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.17, 20:01:12
No worries, I suspect that we've all been swamped, especially at this time of year.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.22, 02:48:09
The GL/2 codebase is on Netlabs now. The sourceforge repo will be deleted in the coming weeks. More to follow. Stay tuned for new OSWorld topics, also.
Title: Re: OpenGL ddk
Post by: miturbide on 2010.12.22, 16:45:22
Excellent !!
http://svn.netlabs.org/repos/gl2/ (http://svn.netlabs.org/repos/gl2/)

Thanks for your effort Demetrious.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.22, 20:39:32
No problem, I hope I've gotten the ball rolling. I'm also looking for anyone who'd like to help contribute.
Title: Re: OpenGL ddk
Post by: RobertM on 2010.12.23, 10:03:22
I may have missed it, but what build environment & compiler are you using?
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.23, 18:13:12
I may have missed it, but what build environment & compiler are you using?

OpenWatcom 1.8 on Win7, but I'm about to move it to OpenWatcom 1.8 on eCS 2.0.
Title: Re: OpenGL ddk
Post by: abwillis on 2010.12.23, 20:19:39
The glpipeline.dll will need to be renamed unless requiring the use of win32k.sys.  At some point a restriction in DLL names was put into place allowing only 8.3 naming (something to do with allowing a smaller memory usage).
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.24, 21:37:20
Wow, I had no clue. Thanks for letting me know, I'll work out a shorter name for all of my DLLs that are out of compliance.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2010.12.28, 02:39:30
It's been awhile since I've spoken, so I'll speak now. I'm still here. It's the holiday season, so I'm kinda busy with family holiday stuff. I'm also in the process of leaving the military, so things are kind of busy. I'm weighing a lot of important life decisions right now, but I'm still committed to GL/2, among other OS/2 projects. Currently, I'm working on the pipeline & figuring out how to use TinyGL as the library with as least modification to the code as possible. My current attempt uses TinyGL as the main processing, but embedding it within a framework that covers some of the bases that TinyGL doesn't. It's also how I plan to embed profiling & other systems within GL/2. Memory management will also be very important. Which is why I have started the process of porting my AGPGART driver to OS/2. Code will start flowing into Netlabs. Also, I've started working on AL/2, which is a port of Chris Robinson's OpenAL/Soft library to OS/2. It's going to use OS/2's multimedia framework as a backend. There are also a few other projects that I'm not ready to speak about. Stay tuned!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.03, 21:06:56
Ok, so here's a quick update.

I've started on the pipeline code. I've decided to just completely ditch TinyGL. In the end, there was just too much bullshit there to deal with. Not that the codebase is bad, it's just created to serve the author's purpose, which is different from mine. I'm sure that it served it's author's purpose very well, however, it would be a bit of a pain to get it to do what I want it to do, so I gave it the pink slip. What I've settled upon is a C/C++ framework. Basically, you call into the library with C-styled functions, because that part is procedural. But, that code calls C++ style code, because the actual pipeline is based on objects (where there's a benefit). For instance, each particular stage of the pipeline is an object. These stages are then strung together to create actual graphics pipelines. In the current implementation, there're 3 different pipelines: Fixed Function, Programmable Function, & Device Supplied. Now, the Programmable Function pipeline won't be usable until we get support for the GL Shader Language, which I don't expect to get until sometime after there're more people, than me, contributing. Afterall, look at how many people contribute to Mesa3D & they still don't really seem to have a full handle on GLSL. After we get support for GLSL, the Programmable pipeline will be used if there is no Device Supplied Pipeline AND the Context indicates that there's a shader program in use. This leaves the Device Supplied pipeline & the Fixed Function pipeline. If the driver supplies a pipeline, then that pipeline is used regardless of what else is available. If there's no Device Supplied pipeline, then there Fixed Function pipeline is used. There's also a Pipeline class which manages which pipeline to use & controls most things pipeline related. In addition, the glraster.h file has been pushed down into the pipeline's include directory & renamed to gldevice.h. It's also been expanded by adding an object for managing the actual device driver. This will encapsulate all of the device driver functions into one easy to manage area. The Context object handles the actual OpenGL API. It's easily going to be the largest class, because of all of the OGL state that has to be stored & managed, and also because of the large volume of functions it contains. It contains the OGL API as static functions. As such, the actual data that these functions have to work on must be sent to them as arguments; they cannot access the data to their own class directly unless that data is static. In addition the the OGL API, it contains sections allocated for self management functions (such as the ability to reset itself at each glBegin), self management data, and anything that revolves around the pipeline that's attached to it. Soon, there will be a section designated to the windowing system which will contain buffers & viewing area coordinates.

Most of the code, that I've just spoken about, has already been uploaded into the Netlabs repo. If you're inclined to do so, go check it out. I'd love to have more set of eyes overlooking my work anyway; all code needs to be audited!

Also, the Sourceforge repo has not been updated at all & it's deletion is imminent. If you're still checking that codebase, stop; that's a zombie repo.

Gripes, complaints, concerns, or comments?
Title: Re: OpenGL ddk
Post by: ivan on 2011.01.03, 21:15:21
No complaints or gripes from us just thanks that you are prepared to go to the trouble of doing this for OS/2.  As I said before, if you want testing done on several setups just let me know, we have machines ranging from a 486 up to Athlon II x4 - all AMD though.

ivan
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.03, 21:45:37
That's just a tag line that I use to solicit feedback. We usually end our After Action Review meetings with it. If no one speaks up, then that means that we can go ahead & end our meeting. ;) BTW, thanks for the offer. When it's ready for testing, you'll definitely know about it!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.04, 01:25:20
For all of the gamers who may have a bit of technical knowledge, I'd like to post a query. Which is more important to you personally, high precision rendering or sacrificing precision for render speed?
Title: Re: OpenGL ddk
Post by: magog on 2011.01.04, 03:53:55
After I now read the complete thread and with the basic knowledge of OpenGL plus the different implementations out there I have to say good that you ditched TinyGL. It's outdated stuff and more or less abandonware.
Keep in mind: A full OpenGL implementation is not something a small group could even pull off let alone a single person. On the other side there is also the big problem, who is going to implement something in the graphic drivers so this can be used at all. Even SciTech had problems here (they were ATI development partner)...but there are quite some open source drivers out there (but not for the latest hardware - still AMD did some progress in this area).

So what can be used?
As a full OpenGL implementation is out of question what about a subset? OpenGL ES v1.1 or the newer v2.0 version seem to be a good idea. This is what you can find in the smartphones based upon different ARM chips (TIs OMAP3xxx and OMAP4xxx, Apples A9, etc.). The devices like the Palm Pre (Plus; 2), iPhone (3GS; 4) or the Pandaboard/Beagleboard-xM (ARM based developer mainboard everyone you can buy for round about $150) have an 3D accelerator like e.g. the nVidia Tegra or the PowerVR SGX 5x0 (embedded into TIs OMAP processor). All those smartphones now use OpenGL ES v2.0.
http://www.khronos.org/opengles/
http://en.wikipedia.org/wiki/OpenGL_ES

I can't really answer the question what framework to use. For the application developer common frameworks are:

Mesa3D brings it's own implementation and hardware implementation as far as I know and OpenGL ES v1 and 2 can be used.
This looks interesting but there is a high learning curve involved. The other "problem" is the usage of more linux/unix stuff. Drivers might use DRI2 or something else.
As I'm not into that area someone needs to look into it...seems to be Dee or someone else who as already some background and can at least some advice (e.g. the former SciTech gang: Kendall Bennett, Steve Wendt, Michal Necasek).

For the driver part:
The guy(s) who did the Panorama driver have also a driver (port) for the R100 and R200 chipsets (R100 = ATI Radeon 7000...7500; R200 = ATI Radeon 8500...9250). It would be a good idea to get in touch with the developers using the ecomstation.ru website or Roderick Klein (Mensys.nl): http://en.ecomstation.ru/projects/panorama/
Question is: Is the code for those drivers available somewhere? Would be good to get the 3D stuff actually working.

As stated above it might be possible to port more applications based upon SDL or directly Mesa3D as OpenGL (ES) implementation. With the limited acceleration and the latest progress on Java 1.6 even Mindcraft (http://www.minecraft.net/) - which is a Java 3D application - might be working later.

There is a lot of work involved to pull this off even with only OpenGL ES! Everyone should be aware of that.

Edit: There might be some typos left...I should be sleeping since 3 hours which doesn't really help typing. ;)
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.04, 08:24:34
After I now read the complete thread and with the basic knowledge of OpenGL plus the different implementations out there I have to say good that you ditched TinyGL. It's outdated stuff and more or less abandonware.

I didn't drop it because of it's age or state of maintainership, i dropped it because I didn't agree with it's implementation in regards to a true GL implementation.

Quote
Keep in mind: A full OpenGL implementation is not something a small group could even pull off let alone a single person. On the other side there is also the big problem, who is going to implement something in the graphic drivers so this can be used at all. Even SciTech had problems here (they were ATI development partner)...but there are quite some open source drivers out there (but not for the latest hardware - still AMD did some progress in this area).

It's a lot easier to pull off than you think. People get wrapped up into thinking there's one set way to do it, but that's not true. In fact, the difficulty actually comes from deciding just how you WANT to do it. Even with the specs, there's a lot of leeway in regards to the actual implementation. The fact of the matter is that the basic rendering pipeline is fairly well understood. In fact, it's just basic algebra & geometry; the very same that was learned in high school. It's not as if I have to create a completely new spec; all I have to do is create an implementation that follows the spec. I'm also a firm believer that sometimes having too many developers is just as bad as not having enough. In regards to hardware, I doubt that the majority of users are running OS/2-eCS on top of the line systems. We can get away with OpenGL on cards that are a few generations behind. Afterall, that's better than what we currently have.

Quote
So what can be used?
As a full OpenGL implementation is out of question what about a subset? OpenGL ES v1.1 or the newer v2.0 version seem to be a good idea. This is what you can find in the smartphones based upon different ARM chips (TIs OMAP3xxx and OMAP4xxx, Apples A9, etc.). The devices like the Palm Pre (Plus; 2), iPhone (3GS; 4) or the Pandaboard/Beagleboard-xM (ARM based developer mainboard everyone you can buy for round about $150) have an 3D accelerator like e.g. the nVidia Tegra or the PowerVR SGX 5x0 (embedded into TIs OMAP processor). All those smartphones now use OpenGL ES v2.0.

A full implementation is not out of the question. If the *nix guys can roll a full implementation, then there's no reason why we can't do the same. There's no compelling reason to force ourselves to reuse the *nix guys' implementation. The important stuff is actually in the hardware drivers anyway. I've also learned from experience that I don't enjoy assembling a *nix development environment, just to use a *nix project on a non-*nix system. I have better things to do than to bang my head up against that wall. :) I also see no reason to drop down into the ES version of the standard. GL/2's target is for a full implementation. Consider GL/2 as OS/2's equivalent to Mesa3D.


Quote
I can't really answer the question what framework to use. For the application developer common frameworks are:
  • SDL (has also a 3D part and uses OpenGL if available) and there is an eCS and OS/2 port available!
  • Mesa3D (uses software rendering and if available also hardware accelerated 3D) at least an older eCS and OS/2 port is available (done by SciTech)!

Quite a bit of GL/2's framework has already been written.

http://svn.netlabs.org/repos/gl2/ (http://svn.netlabs.org/repos/gl2/)

Quote
Mesa3D brings it's own implementation and hardware implementation as far as I know and OpenGL ES v1 and 2 can be used.
This looks interesting but there is a high learning curve involved. The other "problem" is the usage of more linux/unix stuff. Drivers might use DRI2 or something else.
As I'm not into that area someone needs to look into it...seems to be Dee or someone else who as already some background and can at least some advice (e.g. the former SciTech gang: Kendall Bennett, Steve Wendt, Michal Necasek).

Yeh, I've already banged my head up against that wall with another non-*nix system; lesson learned!

Quote
For the driver part:
The guy(s) who did the Panorama driver have also a driver (port) for the R100 and R200 chipsets (R100 = ATI Radeon 7000...7500; R200 = ATI Radeon 8500...9250). It would be a good idea to get in touch with the developers using the ecomstation.ru website or Roderick Klein (Mensys.nl): http://en.ecomstation.ru/projects/panorama/
Question is: Is the code for those drivers available somewhere? Would be good to get the 3D stuff actually working.

I'm in contact. ;)

Quote
As stated above it might be possible to port more applications based upon SDL or directly Mesa3D as OpenGL (ES) implementation. With the limited acceleration and the latest progress on Java 1.6 even Mindcraft (http://www.minecraft.net/) - which is a Java 3D application - might be working later.

All of those projects (except Mesa3D) still require an OpenGL implementation underneath them in order to use 3d, whether it's hardware or software.

Quote
There is a lot of work involved to pull this off even with only OpenGL ES! Everyone should be aware of that.

So very true! I've lost count of how much code had been written & I'm not even halfway finished!

Quote
Edit: There might be some typos left...I should be sleeping since 3 hours which doesn't really help typing. ;)

Trust me, I know the feeling!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.04, 08:36:32
Back to the question I posted earlier; I think that maybe I should explain things a bit:

OpenGL consists of tons of functions, many of which are redundant. There are many functions groups who's sole difference is merely the grouping of the data & the size type of the data. While this allows application developers a lot of leeway in the way they choose to use the OGL API, it my place a slight burden on the OGL implementer. In order to mitigate this a bit, I've decided to funnel these API groups into a core set of functions that will be the main workhorses of the API, with all variant functions feeding into the core functions. This requires me to make a decision on the underlying size of the data & the implementation of the core functions that operate on this data. It would be far too easy for me to decide to store all of the data as 64-bit floating point data that's double precision & create a complement of conversion functions that convert to/from doubles to/from all of the other size types. However, I wanted to give the OS/2 community a chance to weigh in on the decision. Since many of you are not programmers, I decided to make the decision a bit simple - more precision or faster rendering. I'm fully aware that low-end systems (486, pentium, & pentium 2) will mostly likely have some of the worst performance using GL/2; this is to be expected.
Title: Re: OpenGL ddk
Post by: melf on 2011.01.04, 11:26:45
Hi demetrioussharpe,
just some words of appreciation. Like others I've seen your postings since several weeks, and I've held my breath until know. I don't understand what you technically are talking about,but I very much appreciate what you are doing, and not the least, your attitude. Wish you all luck with this work. Whatever happens it's a great and appreciated effort you do. Thanks!
Title: Re: OpenGL ddk
Post by: Ben on 2011.01.04, 14:57:56
For my part Dee, I'd rather have precision. While my machines are far from current, they aren't ancient either.

Now I know some with ancient machines will rather go for speed; I'll leave that up to them to voice where my fingers will type my stance. So... give me precision.  8)
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.05, 04:06:00
The glpipeline.dll will need to be renamed unless requiring the use of win32k.sys.  At some point a restriction in DLL names was put into place allowing only 8.3 naming (something to do with allowing a smaller memory usage).

As promised, I've changed the names of the pipeline & 3d driver dlls to fit the 8.3 format. The new names are GL2PIPE.DLL (GL/2 Pipeline) & GL2DFT3D.DLL (GL/2 Default 3D).

BTW, I just reached commit 100! WOO HOO!!! ;D
Title: Re: OpenGL ddk
Post by: Joachim on 2011.01.06, 18:52:40
BTW, I just reached commit 100! WOO HOO!!! ;D

Hi Dee,

I notice you even reached commit 137 yesterday :)

Accesible to anyone now via Trac: http://svn.netlabs.org/gl2/timeline

Regards,

Joachim
Title: Re: OpenGL ddk
Post by: miturbide on 2011.01.06, 19:52:27
I took the liberty to change/update the main page of the project:
http://svn.netlabs.org/gl2/ (http://svn.netlabs.org/gl2/)

Please let me know any corrections to be done there.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.07, 00:08:30
I notice you even reached commit 137 yesterday :)

Accesible to anyone now via Trac: http://svn.netlabs.org/gl2/timeline

Hello Joachim,

Thanks for giving me the heads up, I didn't realize that trac setup yet. I've really been trying to push this code out as fast as I can. In many parts of the codebase, I started coding before having a clear idea of what the result should be!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.07, 00:11:14
I took the liberty to change/update the main page of the project:
http://svn.netlabs.org/gl2/ (http://svn.netlabs.org/gl2/)

Please let me know any corrections to be done there.


Thanks for your initiative. I really appreciate it! I made a few slight changes to the wording of one sentence & put my full name in the credits, but nothing major. Feel free to do what you think needs to be done. I'm completely out of my element when it comes to things like that.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.07, 07:25:19
I've been looking at the structure of GRADD drivers. It looks as though it really wouldn't be relatively too difficult, structurally, to add GL support to current video cards. Though, I'd admit that drivers designed to rely on VESA support should be rewritten to include hardware acceleration. I'll research this more & see if I can come up with a rough plan of action.
Title: Re: OpenGL ddk
Post by: warpcafe on 2011.01.25, 22:44:03
Heyda,

sorry if this completely off topic, already discussed or doesn't fit in here at all.
On the occasion of the recent Haiku bounty for porting Gallium3D:

Quote
Gallium3D is a cross-platform video driver API, on which an increasing number of open-source Linux drivers are based.
...
Gallium drivers have no OS-specific code (OS-specific code goes into the "winsys/screen" modules) so they're portable to Linux, Windows and other operating systems.

Now... is that of any relevance... or help?
Is Gallium3D (whatever it is) perhaps a viable solution for eCS?
As I said: If that has nothing to do with the "OpenGL DDK" because I'm comparing apples to pears... sorry! Was just wondering...

Read more: http://haikuware.com/bounties/gallium (http://haikuware.com/bounties/gallium)

Cheers,
Thomas
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.26, 10:15:38
Heyda,

sorry if this completely off topic, already discussed or doesn't fit in here at all.
On the occasion of the recent Haiku bounty for porting Gallium3D:

Quote
Gallium3D is a cross-platform video driver API, on which an increasing number of open-source Linux drivers are based.
...
Gallium drivers have no OS-specific code (OS-specific code goes into the "winsys/screen" modules) so they're portable to Linux, Windows and other operating systems.

Now... is that of any relevance... or help?
Is Gallium3D (whatever it is) perhaps a viable solution for eCS?
As I said: If that has nothing to do with the "OpenGL DDK" because I'm comparing apples to pears... sorry! Was just wondering...

Read more: http://haikuware.com/bounties/gallium (http://haikuware.com/bounties/gallium)

Cheers,
Thomas

Hello Thomas,

Thanks for your interest in the GL/2 project. I've been keeping track of Mesa3D & their Gallium3D framework for quite some time now. While there's a very high chance that I will use their drivers to gain knowledge of how to access the 3D features of various video cards, there're 2 major issues that cause me to refrain from using their codebase directly:

1). I'm striving to create a framework that's usable with the standard OS/2-eCS development toolchain. I do not want to mix & match development tools into a "Frankenstein" styled development environment that's not standard on neither *nix nor OS/2-eCS environments. For this project, I'd prefer to keep the development environment simple & easily reproducible for other developers who may want to contribute.

2). Mesa3D's frameworks seem to be highly *nixed based, which is understandable. This gives me a very low chance for code reuse, considering the fact that we do not have available the types of frameworks that other OS's use to port the codebase. Even Windows seem to use their D3D API for hardware acceleration. There does not seem to be support for using Mesa3D's hw drivers with the Windows platform.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.26, 10:23:47
Allow me to tighten up my response a bit. Gallium3D is largely OS-independent. However, in order to use most of the drivers included in Gallium3D, a port of DRI/DRM is required. There lies the rub. I've attempted to port DRI/DRM to a platform that's more POSIX than OS/2-eCS in the past. There's so much XWindows cruft in there that I realized that it would be more benefitial to just write a DRI/DRM layer from scratch. Unfortunately, I did not have that kind of time laying around & I really didn't need that kind of headache. I would never attempt to disquade someone else from porting DRI/DRM, but I also won't help. I don't need that headache again.
Title: Re: OpenGL ddk
Post by: warpcafe on 2011.01.26, 13:58:42
Hi Dee,

well, now I see the implications. And ind that context, I can perfectly understand what you said/wrote!
It would have also been sufficient to simply tell me "There is X in it" in order to make me roll my eyes and say "OK, naa, thanks then." :)

Cheers,
Thomas
Title: Re: OpenGL ddk
Post by: RobertM on 2011.01.27, 02:16:24
Added a poll
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.27, 15:54:00
Added a poll

Thanks! I know for sure that Ben votes for precision. Is there a way to add his vote in or does he have to do it himself?
Title: Re: OpenGL ddk
Post by: Ben on 2011.01.27, 19:49:22
Too late!

For I have already done it! :D

Now, I am the single vote for Precision against 3 & 3 for the other choices... whatever they may be... I really can't think of them right now... my mind seems to have blanked... something to do with precision too I am sure! ;)

I'll just have to sit and wait for others to choose the obvious choice and then wait as Dee codes for precision.::)

Hehehe... the reality of it is that I'll be pleased to see the finished product in whichever direction it is balanced. For it's the having of the extra functionality that we all anticipate!

                               For it is not our OS, but a goal,
                               That is determined in a Poll.
                               It will serve the eyes and too our minds,
                               That we not be left far behind.
                               And if this code should be complete.
                               Then few will think of our defeat,
                               But of our struggle to survive,
                               And keep our OS/2 alive.

 :o
 
Title: Re: OpenGL ddk
Post by: StefanZ on 2011.01.28, 10:13:01
Well,
would not it be possible to have BOTH - precision AND speed - as selectable driver configurations?
Title: Re: OpenGL ddk
Post by: warpcafe on 2011.01.28, 11:02:49
Dee,

I have to admit that when asked "precision or speed" I'd say "it depends" :)
The point for me here is that I basically have no idea what the GL/2 will be "used for" - is it rather "gaming" or "everything"?

If we talk about rendering of "everything" (including typefaces/fonts, applications screen output in general a la OpenOffice...) then I'd vote for "precision". However, if GL/2 will rather be used for "gaming" then I'd say "speed". Well, honestly, I'd say "I don't care" since I don't do any such games that would require intensive 3D stuff. ;)

Perhaps you can give some more details for n00bs like me what GL/2 will be used for?
(Sorry if everyone else here understands...)

Cheers,
Thomas
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.28, 14:09:14
Well,
would not it be possible to have BOTH - precision AND speed - as selectable driver configurations?

Here's the deal. The OpenGL spec gives the lowest level of precision that's acceptable for certain datatypes, but allows you to over-achieve on things a bit. For instance, a particular value may be allowed to be represented as a float (32-bit floating point), but that's just the low end, you're more than free to represent that value as a double (64-bt floating point). Obviously, the double has more precision, but it's also a slight bit slower to work with. Also, there are many OpenGL functions that are all basically the same with the only differences being the size of the datatypes accepted and whether or not the arguments come in an array or are explicitly spelled out. I'm not going to sit here & implement separate versions of these functions. Instead, I'm going to do the smart thing, the part of the GL context that the function modifies will be in only 1 precision. All of the various functions that modify that particular variable will have to convert their data to the correct datasize & then call another function that does the actual modification.

Ex.:

GLAPI void GLAPIENTRY glVertex2d( GLdouble x, GLdouble y );
GLAPI void GLAPIENTRY glVertex2f( GLfloat x, GLfloat y );
GLAPI void GLAPIENTRY glVertex2i( GLint x, GLint y );
GLAPI void GLAPIENTRY glVertex2s( GLshort x, GLshort y );

GLAPI void GLAPIENTRY glVertex3d( GLdouble x, GLdouble y, GLdouble z );
GLAPI void GLAPIENTRY glVertex3f( GLfloat x, GLfloat y, GLfloat z );
GLAPI void GLAPIENTRY glVertex3i( GLint x, GLint y, GLint z );
GLAPI void GLAPIENTRY glVertex3s( GLshort x, GLshort y, GLshort z );

GLAPI void GLAPIENTRY glVertex4d( GLdouble x, GLdouble y, GLdouble z, GLdouble w );
GLAPI void GLAPIENTRY glVertex4f( GLfloat x, GLfloat y, GLfloat z, GLfloat w );
GLAPI void GLAPIENTRY glVertex4i( GLint x, GLint y, GLint z, GLint w );
GLAPI void GLAPIENTRY glVertex4s( GLshort x, GLshort y, GLshort z, GLshort w );

GLAPI void GLAPIENTRY glVertex2dv( const GLdouble *v );
GLAPI void GLAPIENTRY glVertex2fv( const GLfloat *v );
GLAPI void GLAPIENTRY glVertex2iv( const GLint *v );
GLAPI void GLAPIENTRY glVertex2sv( const GLshort *v );

GLAPI void GLAPIENTRY glVertex3dv( const GLdouble *v );
GLAPI void GLAPIENTRY glVertex3fv( const GLfloat *v );
GLAPI void GLAPIENTRY glVertex3iv( const GLint *v );
GLAPI void GLAPIENTRY glVertex3sv( const GLshort *v );

GLAPI void GLAPIENTRY glVertex4dv( const GLdouble *v );
GLAPI void GLAPIENTRY glVertex4fv( const GLfloat *v );
GLAPI void GLAPIENTRY glVertex4iv( const GLint *v );
GLAPI void GLAPIENTRY glVertex4sv( const GLshort *v );

All of these functions create a vertex (4-dimensional point). The differences are how many planes of space are used to represent the vertex, how the data is passed to the function, & the precision of the data. Obviously, I wouldn't want to represent the vertex as a short (16-bit integer); however, representing it as an int verses a float or double may give certain speed advantages on older CPU's & GPU's. On modern hardware, it may not be as big of an issue & there'd really be no reason to not go with a float or a double. Who knows, the future may bring code that decides which to use based on which CPU the host system has, but for now, I need to get something running & I thought it might be prudent to solicit outside opinions. Also, I've already decided to go ahead & represent all vertices in terms of (x, y, z, w) internally, regardless of how many values are passed to the glVertex function. Non-specified values will probably be represented as 0 for the basic 3d coordinates & 1 for the w component.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.28, 14:14:26
Dee,

I have to admit that when asked "precision or speed" I'd say "it depends" :)
The point for me here is that I basically have no idea what the GL/2 will be "used for" - is it rather "gaming" or "everything"?

If we talk about rendering of "everything" (including typefaces/fonts, applications screen output in general a la OpenOffice...) then I'd vote for "precision". However, if GL/2 will rather be used for "gaming" then I'd say "speed". Well, honestly, I'd say "I don't care" since I don't do any such games that would require intensive 3D stuff. ;)

Perhaps you can give some more details for n00bs like me what GL/2 will be used for?
(Sorry if everyone else here understands...)

Cheers,
Thomas

Being that it's largely just a plug-in replacement for IBM's OpenGL implementation, it really just depends on the user. User's who are heavy into gaming may value speed first. However, users who are into CAD & possibly renderfarms will value precision. In that light, I'd say that it also depends on the app developers. I'm sure that some's going to say that no one develops OpenGL apps for OS/2. However, they really didn't have a reason to until now. And with all of the open-sourced code floating around these days, it'll be much easier to port code over. The large bulk of code that utilizes OpenGL will probably be more easily ported if the Windows version of the app is ported.
Title: Re: OpenGL ddk
Post by: StefanZ on 2011.01.28, 17:49:55
Ah,

now I perfectly understand your concerns.
From the above point of view, I will definitely vote for precision ;)

Thanks a lot for explaining, demetrious  ;)
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.29, 08:13:14
Ah,

now I perfectly understand your concerns.
From the above point of view, I will definitely vote for precision ;)

Thanks a lot for explaining, demetrious  ;)

No problem at all.
Title: Re: OpenGL ddk
Post by: wimpie on 2011.01.29, 13:44:19
I just voted for precision.
Title: Re: OpenGL ddk
Post by: cytan on 2011.01.29, 16:54:05
I vote for a driver that I can test!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.30, 05:04:52
I vote for a driver that I can test!

As nice as that would be, we need a pipeline before we worry about a driver! :P
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.01.31, 10:08:04
Well, so far the tally's pretty much split evenly with 3 for precision, 3 for speed, & 6 for a mixture of both (which really doesn't apply in the matter of the reason I was asking). So, I decided to go with precision & hope that faster processors help to offset the speed difference. Slower processors are just out of luck. Renderable data will be implemented as 64-bit floating point values.

In other news, I now have a pretty good layout for the pipeline. I'm not sure if I can accurately describe it in words without pictures & diagrams, but I'll try:

Functions that directly change the context will do so immediately. Colors, vertices, normals & things of that nature will be contained in the GL's context until it's time for processing. Processing won't begin until GLEnd() is called. At that point, the context & all of it's gathered data will be sent through the pipeline. All the pipeline does is render the graphics as specified by the data within the context. the only 3D functionality exported by the hardware driver is the entrance to the pipeline function. If there's no hardware pipeline function attached, the pipeline will use it's internal software pipeline.

That's all for now. If there's anyone here with 3D experience & a few comments, tips, or anything helpful to share, now's the time to speak up! :)
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.08, 19:40:26
Well, I guess it's time for another update. I'll admit, I've mostly been sitting at home on my ass since leaving the army. I guess this little break is going to have to do until I can actually take a real vacation. But still, I've got a few thing done on GL/2.

I think I've done a decent job of figuring out which commands can be used in display lists, grouping them up based on functionality, & encoding them in a way that will provide a fair amount of code reuse, allowing me to side step lots of coding &  simplify some of the function implementation into cuts & pastes. There's still quite a bit of work left to do on the actual API, but I've actually knocked out more of it than I thought I would. I'm kinda dragging my feet on it, but sooner or later I'll have to start working on the datatype conversions between all types signed & unsigned to & from floats and doubles. I hope I can find a great conversion system, this needs to be as accurate as possible. Along with the API, I still have to finish working on pipeline management & the actual internal rendering pipeline. I'm also trying to mesh together a driver layer that can be plugged into the GRADD system through the extensions mechanism. Most of the code that I've been working on has been committed to the repo; so, if you think you have some ideas about the driver layer or you have GRADD experience, please, hit me up so we can collaborate. Also, I'm far from a coding God & I haven't tried to build this pipeline yet (I haven't even setup an Open Watcom project for it), so take a look at the code & keep me on track.

I've also been slacking on AL/2 & AGPGART. I'm not sure what it is, but I just can't seem to get a good boiler plate driver up for plugging in AGPGART. I'll keep at it & figure out something, because I'm going to need to be able to communicate with AGPGART when I start work on the memory management portion of GL/2. As for AL/2, it's mainly been a matter of not having time to research OS/2's multimedia API's properly. The great thing about Chris Robinson's OpenAL Soft is that there's really not much needed in order to port it to a new system. It'll need a driver file added that interfaces OpenAL Soft to OS/2's multimedia subsystem & a few additions to parts of the code just to let the library know that there's a new driver included, that's it. I'm slowly dragging myself up outta my slouch, so my productivity will start to kick up again. More later!

Comments, concerns, gripes, or complaints?
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.11, 17:00:08
If there're any graphic design specialist out there, I need your help. I just noticed that the OpenGL logo is on the GL/2 page. It must be taken down, since neither myself or anyone else have an OpenGL commercial license. Without the commercial license, we are not allowed to use the OpenGL branding. Which means that this is a great time to start accepting submissions for a GL/2 logo. Keep in mind that if you contribute this logo, you're in fact donating your logo to this project. You will receive full credit for you're work, however, your work will belong to the GL/2 project upon acceptance. So, any takers? Also, I'm looking for a few users to help me judge. Four people, in addition to myself, should be enough to adequately judge submissions. So, I'm looking for submitters & judges, any takers?
Title: Re: OpenGL ddk
Post by: Joachim on 2011.02.11, 17:17:45
I just noticed that the OpenGL logo is on the GL/2 page. It must be taken down, since neither myself or anyone else have an OpenGL commercial license. Without the commercial license, we are not allowed to use the OpenGL branding.

Hm, my fault - I submitted it to Adrian, didn't realize it was covered by whichever license. I'll notify him it has to be changed.

Sorry,

Joachim
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.11, 19:51:31
Hm, my fault - I submitted it to Adrian, didn't realize it was covered by whichever license. I'll notify him it has to be changed.

Sorry,

Joachim

Well, to be honest, I'm glad you did it. It's jolted me into speaking up on needing a logo. I first wanted to make sure that there was interest in the project, before calling for a logo. However, eventually, most of my time on GL/2 ended up being spent on coding & researching, so it kinda got prioritized out of the forefront. You taking the initiative has reminded me that one's needed & to ask for help. Afterall, coding is just one aspect of the project, so you don't have to be a coder in order to help me! :)
Title: Re: OpenGL ddk
Post by: melf on 2011.02.11, 23:42:33
Four people, in addition to myself, should be enough to adequately judge submissions. So, I'm looking for submitters & judges, any takers?
I'll be happy to be one of the judgers. I'm no expert but I like graphics.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.12, 00:50:14
Four people, in addition to myself, should be enough to adequately judge submissions. So, I'm looking for submitters & judges, any takers?
I'll be happy to be one of the judgers. I'm no expert but I like graphics.

Sounds good to me! Ok, so far I have one additional judge & one submittion. Is there anyone who wouldn't mind temorarily hosting the logos for everyone's viewing pleasure while the contest is up & running? I plan to keep this contest going until the 4th of March. Afterwards, the judges will decide which logo has won. If there are no other submissions, then the current submission will win by default. Though, it's really not a bad logo. It's nice & simple.
Title: Re: OpenGL ddk
Post by: melf on 2011.02.12, 01:13:19
Well, I can host them if you send them to me , me@os2world.com. I'll provide a link. Or just put them up in this forum.
Title: Re: OpenGL ddk
Post by: Ben on 2011.02.12, 02:48:01
Though, it's really not a bad logo. It's nice & simple.

Unfortunately, logos have to be simple given the wide variety of uses they must serve, including still being able to look good when severely reduced.

Given that restriction alone, it has to be sort of big and blocky and not contain any fine, fancy work or it is either lost in the reduction, or falls apart looking... well... sometimes less than it was and other times... simply 'orrible!  :o

Of course, if someone has some very good, expensive, graphics software to work with, that limitation is not so limiting!  :D
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.12, 04:31:22
Unfortunately, logos have to be simple given the wide variety of uses they must serve, including still being able to look good when severely reduced.

Given that restriction alone, it has to be sort of big and blocky and not contain any fine, fancy work or it is either lost in the reduction, or falls apart looking... well... sometimes less than it was and other times... simply 'orrible!  :o

Of course, if someone has some very good, expensive, graphics software to work with, that limitation is not so limiting![/color]  :D

Undoubtedly. I just wasn't expecting to like the first submission as much as I do. If there aren't any other submissions, I would be perfectly fine with this one.
Title: Re: OpenGL ddk
Post by: Ben on 2011.02.12, 14:36:42
Ack!

Well, from that I would deduce that my submission isn't going over all that well... HEhaahahha!

                 *coughs & grins & finally stops laughing*

Heheh... well, I have never claimed to be a graphics artist.  :D

Oh, that's just sooo funny!  :D



Don't take that the wrong way, now.

But... is there a little preview of this wonderful logo that you keep talking about, that we can all see? I mean, to inspire us all to greater, graphic, heights?

I mean, it's just sooo wrong to tease us all like this and not put out at the height of the tease... or should I say... at the "peak of the pique"... when you have us all so prepare... so aroused.  :D

I mean, show us the damn logo for chrissake!  ::)

Heheheh...
Title: Re: OpenGL ddk
Post by: melf on 2011.02.12, 15:12:59
Here is the link Ben ,

http://elfonnet.nu/logos

Title: Re: OpenGL ddk
Post by: Ben on 2011.02.12, 15:58:55
Er... thanks, Melf!, but that not the logo Dee was talking about.. that's my weak attempt.

Where's the great one?
Title: Re: OpenGL ddk
Post by: melf on 2011.02.12, 16:09:26
:-)
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.13, 00:25:33
Er... thanks, Melf!, but that not the logo Dee was talking about.. that's my weak attempt.

Where's the great one?

Actually, I rather like this logo. The most important factor is that it's nothing at all like the OpenGL logo. It's not even similar to it. And, on top of that, it's rather simple. Not a whole lot to confuse the eyes. It gets it's point across rather nicely. You know, without a shadow of a doubt, what this logo represents.
Title: Re: OpenGL ddk
Post by: Ben on 2011.02.13, 03:19:37
Actually, I rather like this logo. The most important factor is that it's nothing at all like the OpenGL logo. It's not even similar to it. And, on top of that, it's rather simple. Not a whole lot to confuse the eyes. It gets it's point across rather nicely. You know, without a shadow of a doubt, what this logo represents.

Well, thanks for that, Dee, but it couldn't have been the one that you were talking about, because I hadn't made it yet. Hehe. 8)

I guess that the first one will be shown at some point...

Be sure to post a reference to it...
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.13, 03:32:48
Actually, I rather like this logo. The most important factor is that it's nothing at all like the OpenGL logo. It's not even similar to it. And, on top of that, it's rather simple. Not a whole lot to confuse the eyes. It gets it's point across rather nicely. You know, without a shadow of a doubt, what this logo represents.

Well, thanks for that, Dee, but it couldn't have been the one that you were talking about, because I hadn't made it yet. Hehe. 8)

I guess that the first one will be shown at some point...

Be sure to post a reference to it...

I didn't post until after I got the pic from your PM.
Title: Re: OpenGL ddk
Post by: Ben on 2011.02.13, 14:14:31
There's some frequency wandering going on here I think.  ;)

Let me see if I can clarify this a bit...

Sounds good to me! Ok, so far I have one additional judge & one submittion.

Your "& one submittion" [sic] means that you had to have at least one logo at that point.

It was that message that prompted me to create-and-submit mine... so there must be at least two logos at this point.

It is that first submission to which I refer(red)... and want(ed) to see.  :D
Title: Re: OpenGL ddk
Post by: jep on 2011.02.13, 16:03:29
Hello Dee,

is there something we (users) can help you out with beside cheering you on?


//Jan-Erik

__________
Some of us can demand new features, while others suggest things, offer money ...
Even though some of us tried to study "programming" and know the basics of C/C++, there's no way to help you out when we always stumble on roadblocks.


Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.13, 19:00:08
There's some frequency wandering going on here I think.  ;)

Let me see if I can clarify this a bit...

Sounds good to me! Ok, so far I have one additional judge & one submittion.

Your "& one submittion" [sic] means that you had to have at least one logo at that point.

It was that message that prompted me to create-and-submit mine... so there must be at least two logos at this point.

It is that first submission to which I refer(red)... and want(ed) to see.  :D

I typed that ONLY after receiving your logo via this site's PM system.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.13, 19:05:56
Hello Dee,

is there something we (users) can help you out with beside cheering you on?

Hello Jep,

Sure, there's always something to do that's not really related to actual programming. Logos would be great. Convincing any of the graphics & game developers that you know to consider building a version of their software targeting OS/2's OpenGL implementation. GL/2 site management probably needs a little help here & there. There're also tons of things that are going to need to be in place when this thing is up & running, since the availability of hardware acceleration (in itself) is just 1 solution to 1 problem, but doesn't solve the overall issues. Maybe organizing fellow OS/2 users who love games to get back involved. Perhaps someone could even create a new OS/2 gaming site. The sky's the limit really. Thanks for your interest! :)
Title: Re: OpenGL ddk
Post by: Ben on 2011.02.13, 19:53:11
I typed that ONLY after receiving your logo via this site's PM system.

Geez...

You must have been online when I sent that PM.

You replied so fast I thought that you were talking about someone else's pic.

Also, the way that you described it, I didn't think that you could possibly be talking about my errr... rather basic... submission. Hahaha!  ::)

In which case, thanks for the kind words.   :D
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.13, 22:54:58
I typed that ONLY after receiving your logo via this site's PM system.

Geez...

You must have been online when I sent that PM.

You replied so fast I thought that you were talking about someone else's pic.

Also, the way that you described it, I didn't think that you could possibly be talking about my errr... rather basic... submission. Hahaha!  ::)

In which case, thanks for the kind words.   :D

I'm usually online. Now, more than ever, since I no longer have to worry about going to work! lol
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.17, 18:28:13
Just reached commit #200.  It brings a large portion of my overall concept to the project -"Nugget Streams".  The nugget streams are what flow through the pipeline. Nuggets are bits & pieces of graphics primitives.  In order to allow the driver to be as efficient as possible, all of the data is manipulated within the GL library up until GLEnd() is called.  Once GLEnd() is called, the Context sends itself to the Pipe object.  The Pipe object evaluates the Context in order to decide which pipeline to use.  Once that's decided, the Pipe object retrieves the nugget stream from the Context & sends it through the prior selected pipeline.  At this point, we're sending raw data through the pipeline.  There's nothing else left for the GL library to manipulate & the hardware will not be sending any return values back to the GL library.  The basic format for a nugget 'so far' is:

typedef struct NUGGET
{
    struct NUGGET *pPrev;
    struct NUGGET *pNext;
    NUGGETTYPE eType;
    void *pPrim;
} NUGGET, *PNUGGET;

The basic format for a stream of nuggets 'so far' is:

typedef struct STREAM
{
    unsigned int nCount;
    NUGGET *pNuggets;
} STREAM, *PSTREAM;

I'm still trying to hash out exactly which primitive commands will be listed in enum NUGGETTYPE.  More to follow!

P.S.  It looks like I forgot to include nuggets.h in commit #200, so it's in #201!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.23, 16:38:12
Recently, I was contacted by someone who sent me the source code to WarpMesaGL. If I'd had this code from the beginning, I probably would've never started up the GL/2 project. I'm currently evaluating this code to determine it's value. The programmer who did the port seems to have abandoned the code back in 2003, apparently.
Title: Re: OpenGL ddk
Post by: jep on 2011.02.23, 19:44:30
You've probably done a lot of thinking about it on your own, so now that you can see the other code, you've probably got a lot of your own ideas and input that can boost your effort to perhaps merge the ideas into one project.

Is it far from what you've been working on?!
Title: Re: OpenGL ddk
Post by: cytan on 2011.02.23, 21:09:33
Hi Demetrious,
   I think the most important thing is to get something working. Having some other code might help you compare it to what you've already written but I think that you've put in so much effort in GL/2 that it would be a pity if you abandoned it in favour of WarpMesaGL
Title: Re: OpenGL ddk
Post by: Ben on 2011.02.23, 21:40:49
Recently, I was contacted by someone who sent me the source code to WarpMesaGL. If I'd had this code from the beginning, I probably would've never started up the GL/2 project. I'm currently evaluating this code to determine it's value. The programmer who did the port seems to have abandoned the code back in 2003, apparently.

Ouch!

You have my sympathies...  :(

I know what it's like to do a work of altruism only to find once well along the road, that someone brings something forward that makes your good deed redundant... or a significant portion thereof.

Still, here's hoping that the two work well together to bring out something more than either would otherwise have been.

Title: Re: OpenGL ddk
Post by: miturbide on 2011.02.24, 00:22:42
Hi demetrioussharpe

Is the WarpMesaGL source code open source? is the license compatible with the work you are doing?

I don't know much about WarpMesaGL, I just hope the access to the source code and binaries can be public and freely distributed.

Martin
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.24, 01:11:45
You've probably done a lot of thinking about it on your own, so now that you can see the other code, you've probably got a lot of your own ideas and input that can boost your effort to perhaps merge the ideas into one project.

Is it far from what you've been working on?!

Yes, it's very far. It's based on Mesa3D. I'm still trying to find the supposed ATi R200 & SNAP drivers that it's said to include. Though, they're only supposed to be work-in-progresses. I'm more interested in how the drivers interface to the code. If I were to scratch everything & pursue this codebase solely, It would mean that I'd end up trying to update it to the latest stable version of Mesa3D, & figure out a way to interface the output of Mesa3D & the input of the drivers with the GRADD extension interface between them. This is pretty much what I have to do with GL/2.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.24, 01:12:30
Hi Demetrious,
   I think the most important thing is to get something working. Having some other code might help you compare it to what you've already written but I think that you've put in so much effort in GL/2 that it would be a pity if you abandoned it in favour of WarpMesaGL


We're of the same mindset in this regard.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.24, 01:14:01
Recently, I was contacted by someone who sent me the source code to WarpMesaGL. If I'd had this code from the beginning, I probably would've never started up the GL/2 project. I'm currently evaluating this code to determine it's value. The programmer who did the port seems to have abandoned the code back in 2003, apparently.

Ouch!

You have my sympathies...  :(

I know what it's like to do a work of altruism only to find once well along the road, that someone brings something forward that makes your good deed redundant... or a significant portion thereof.

Still, here's hoping that the two work well together to bring out something more than either would otherwise have been.



It was definitely a pickle, but I'm going to push forward with GL/2. It would take too much work to bring WarpMesaGL up to date with current Mesa3D.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.24, 01:14:53
Hi demetrioussharpe

Is the WarpMesaGL source code open source? is the license compatible with the work you are doing?

I don't know much about WarpMesaGL, I just hope the access to the source code and binaries can be public and freely distributed.

Martin

Yes, it's based on Mesa3D. I think it's the 5.0 version of Mesa3D.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.24, 01:41:48
After evaluating the codebase, I can find no actual ATi R200 driver implementation, the folder that was supposed to contain it is actually empty. Also, while looking at the GL glue API's, I found code for OS/2 versions of GLX & WGL. What I did not find, however, was an implementation of PGL. I can understand wanting to bring over these APIs from other OSes for compatibility reasons, but it really seems like everyone wants to abandon the original OS/2 APIs even when there's no need to. I'm all for extending our APIs & upgrading them, but we really shouldn't just abandon them when there's no real reason to do so.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.24, 23:23:50
After committing the latest bit of code to the GL/2 repo, I find myself at a special point in development. It's a point where you can go no father until you tackle problems that you've been procrastinating on. Now that the function routing code (cpp_pipeline/internal.cpp) has been implemented, I won't get very far with the implementation of the actual GL API (cpp_pipeline/glapi.cpp) until I implement the memory management system. This shouldn't end up being overly complicated & overbearing. It should be just enough to allocate memory for textures & other video objects. This also means that I'll be able to put more effort into the AGPGART driver port. The memory manager will have a basic waterfall approach to memory allocations & will try to allocate memory from the following sources, in order:

1). Video memory
2). AGP aperture
3). System RAM

More to follow.
Title: Re: OpenGL ddk
Post by: Vincenzo on 2011.02.26, 03:29:53
Hello Demetrius, hello to everyone. Excuse me if I do not write properly in English  :)
I am glad that finally tackle the problem of opengl, but mainly the problem of 3D accelerated driver. I analyzed the code of Demetrius, and it seems very promising, if it continues at this rate, we can have a very complete OpenGL library, but also adhering to the current OpenGL standard.
The problem remains, however, always to have accelerated 3D drivers that currently does not exist in OS/2.
I've heard about GL2DDK, with source code examples for writing a GRADD video driver with OpenGL hardware support (if someone can be sent to me via email this GL2DDk). Well, beyond the issue of licensing IBM and SGI, I think it's time to take as an example GL2DDK and begin the creation of such drivers.

Vincenzo
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.26, 09:13:23
Hello Demetrius, hello to everyone. Excuse me if I do not write properly in English  :)
I am glad that finally tackle the problem of opengl, but mainly the problem of 3D accelerated driver. I analyzed the code of Demetrius, and it seems very promising, if it continues at this rate, we can have a very complete OpenGL library, but also adhering to the current OpenGL standard.
The problem remains, however, always to have accelerated 3D drivers that currently does not exist in OS/2.
I've heard about GL2DDK, with source code examples for writing a GRADD video driver with OpenGL hardware support (if someone can be sent to me via email this GL2DDk). Well, beyond the issue of licensing IBM and SGI, I think it's time to take as an example GL2DDK and begin the creation of such drivers.

Vincenzo

Hello Vincenzo,

I think you are slightly confused & are blending 2 completely different codebases. GL/2 is my project which has the dual goals of creating an OpenGL implementation & creating a DDK for 3D video drivers in OS/2. So, GL2DDK most closely describes my project. I think the DDK codebase that you're referring to is IBM's OpenGL DDK. While both of these codebases should result in the same outcome, there are a number of differences between the 2. Keeping in mind that OpenGL drivers are intimately tied to specific OpenGL library implementations & can not be used with other implementations, here are the major differences between GL/2 (w/DDK) & IBM's DDK:

IBM:

1). Based on an older version of OpenGL (1.0 & 1.1) with no way to used extensions or updated functionality
2). Incomplete & never released for usage
3). Did not originate from OS/2 & has quite a bit of cruft from *nix
4). Seems exist for the sole purpose of jumping on the OpenGL bandwagon, instead of existing to be actually useful

GL/2:

1). Initially based on OpenGL v2.0, but constantly looks forward to later specs with the added ability to use extensions & updates (if available)
2). The whole purpose for this project is completeness & usability; it's open sourced, so it's in a constant state of release
3). It's written for OS/2 from scratch & does not contain any DNA from implementations from other OSes
4). Exists because it's useful & needed

While IBM's DDK would be mildly useful for writing OpenGL drivers for the included OpenGL implementation for OS/2, it really wouldn't serve a purpose for writing GL/2 drivers. The main purpose for DDKs is to give an example of how to interface a specific driver to the OS by tying it to the subsystem that will be the primary user. In that regard, IBM's DDK will show you exactly how to tie a driver in to their implementation, but it really won't give you much data on how video drivers should work with the card that they're written for. In fact, if I remember correctly, their DDK's driver doesn't really actually accelerate very much, it's more of a proof-of-concept kind of driver. However, stay tuned. Soon enough, I'll get to the part of the project where it'll be time to finish solidifying the actual device driver interface & create an example of how to write a GL/2 driver.
Title: Re: OpenGL ddk
Post by: Vincenzo on 2011.02.26, 23:38:24
Hello Demetriuos, thank you for your explanations, now i have understand the difference about IBM OpenGL and GL/2. I will stay tuned, because i'm very interesting about how to write a GL/2 driver.

Vincenzo
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.02.28, 01:19:16
After evaluating the codebase, I can find no actual ATi R200 driver implementation, the folder that was supposed to contain it is actually empty. Also, while looking at the GL glue API's, I found code for OS/2 versions of GLX & WGL. What I did not find, however, was an implementation of PGL. I can understand wanting to bring over these APIs from other OSes for compatibility reasons, but it really seems like everyone wants to abandon the original OS/2 APIs even when there's no need to. I'm all for extending our APIs & upgrading them, but we really shouldn't just abandon them when there's no real reason to do so.

I was sent an older version of WarpMesaGL which did have the ATi R200 driver beginnings. I have not had a chance to properly look through the code, but I can say that there's code there. Also, the sender has an OS/2 OpenGL readme page that may be of interest. It's located at: ftp://alter.org.ua/incoming/gl_os2.htm (ftp://alter.org.ua/incoming/gl_os2.htm). By using this page, I was able to avoid a potiential bug by using a simple header fix. I will know for sure if this bug has be fixed once I start the GLUT implementation. In any case, this whole experience has been pretty pleasant & has taught me a lot. More to follow!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.03.02, 02:29:10
Well, March 4th is right around the corner & there haven't been any other submissions. Looks like we might be able to forgo any actual judging. I think we might have our logo!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.03.02, 02:35:30
Looks like we no longer need the poll. Back when the polls were even, I decided to mostly use 64-bit floating point precision for values that could be submitted as one of multiple types. They're now converted to the correct value for their respective types. Thanks to all who've taken the time to vote in the poll & thanks for setting up the poll!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.03.06, 04:00:09
Ok, it's the 5th of March & we have no other submissions, so I'll email Joachim the new image for the GL/2 page.
Title: Re: OpenGL ddk
Post by: Ben on 2011.03.19, 17:32:31
Any headway with OpenGL/2?

I haven't heard anything in a while so I was wondering...

Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.03.19, 20:48:34
Any headway with OpenGL/2?

I haven't heard anything in a while so I was wondering...



Still working on the memory management layer. Taking a break this wk, though, in celebration of my birthday.  Don't worry, the project is still ongoing.
Title: Re: OpenGL ddk
Post by: Ben on 2011.03.20, 13:57:04
Still working on the memory management layer.

*nods*


Still working on the memory management layer. Taking a break this wk, though, in celebration of my birthday.  Don't worry, the project is still ongoing.

Ah!

Well, here's wishing you a very Happy Birthday celebration!

 :D
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.03.20, 15:34:58
Still working on the memory management layer.

*nods*


Still working on the memory management layer. Taking a break this wk, though, in celebration of my birthday.  Don't worry, the project is still ongoing.

Ah!

Well, here's wishing you a very Happy Birthday celebration!

 :D


Thanks! We're driving back from Dallas within the next couple of hours. After we pick up the kids, things will get back to normal.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.01, 15:36:16
It seems as though I've accidentally wrote a few lines of code that render in a similar fashion to how Direct3D renders. Instead of deleting the code, I've decided to pursue it a little. Since GL/2 has an architecture that's mildly modular, I should be able to add D3D support without disrupting the rest of the framework & with using the same hardware drivers. More to follow!
Title: Re: OpenGL ddk
Post by: Joachim on 2011.04.01, 18:30:52
It seems as though I've accidentally wrote a few lines of code that render in a similar fashion to how Direct3D renders. Instead of deleting the code, I've decided to pursue it a little. Since GL/2 has an architecture that's mildly modular, I should be able to add D3D support without disrupting the rest of the framework & with using the same hardware drivers. More to follow!

Wow, that's accidentally very cool!

Joachim
Title: Re: OpenGL ddk
Post by: Ben on 2011.04.01, 20:49:50
Wow, that's accidentally very cool!

Joachim

Yeah!

I second that...

... highly unexpected! :o

I thought such a task would be overly complex and thus, not doable save... where a team would be involved.

Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.02, 03:58:31
Sorry mates, mind the date! lol
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.02, 04:01:27
Sorry mates, mind the date! lol

I know, I was wrong! But it was too easy of an April Fool's joke, I couldn't resist! All isn't lost though, gents. The way my code is structured does give way to adding a D3D style rendering subsystem. It did happen kind of accidentally, but there's no such D3D rendering code in place. I just wanted to clear that up before April Fool's day ended (in my time zone!).
Title: Re: OpenGL ddk
Post by: abwillis on 2011.04.02, 04:28:01
You should consider porting GL/2 to REXX/OS.
http://rexxos.netlabs.org/en/site/index.xml
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.02, 04:49:13
You should consider porting GL/2 to REXX/OS.
http://rexxos.netlabs.org/en/site/index.xml

It'd be a perfect fit! Lol
Title: Re: OpenGL ddk
Post by: Ben on 2011.04.02, 16:26:46
Sorry mates, mind the date! lol

Ahahhahahaah!

All the steps except the conclusion...

Ahahaha!


 :o
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.10, 21:22:32
Just a few thoughts:

The GRADD driver subsystem seems to be an implementation of the old OS/2 video drivers with a plug-in interface. It seems, to me, that the GRADD subsystem could be replaced with another video driver abstraction. It seems to be boiler plate code that just needs the hardware specifics to be filled in; much like Windows' driver/mini-driver & port/mini-port implementations. From the kernel's perspective, GRADD is a common video driver; but from a video driver's perspective, GRADD is the OS.

The April Fool's prank that I pulled caused me to take a pause & examine the design of GL/2. Mainly in the aspect of where the dividing lines of responsibility are drawn. It seems that I might have to add another dividing line & parcel out the code that communicates with the 3D GRADD extension into it's own DLL. Afterwards, the API for using that DLL needs to be cleaned up & streamlined. This will allow multiple graphics libraries to emit graphic commands to the 3D hardware. The end result would be an allowance for possible future work for Direct3D. Will I be doing this work? Probably not, however, creating the possibility is a fine position to leave the codebase.

It occurs, to me, that more work could've been accomplished if the OS/2 community would've started working on a modern, open source, replacement for OS/2 the minute IBM rung the death bell (the way the BeOS community did). I mean real development, not just talking, posturing, politicking, & arguing. We wouldn't have lost so many developers or had such a hard time writing drivers. Now, we're at a bad point where there really aren't enough developers to handle the workload. On top of that, there's a group working to recreate a product that was never even released commercially. Not to discount their work, but how do you even know when you're finished when the OS that they're cloning was never finished? In any case, I've been evaluating the Möbius OS. It seems as though it might be a great starting point for a Merlin clone. Although, there's the issue of drivers. Still, that's no worse than the situation that we're currently in.

Just a few thoughts.
Title: Re: OpenGL ddk
Post by: Ben on 2011.04.11, 12:22:25
Virtual PC relies heavily on ODIN. In there somewhere, is the handling for Direct3D... at least to some degree, though clearly not a full implementation. I don't know if looking at how that was done can offer any insight or some such. I'm not a programmer, so I might be off track there.

With regard to making a clone OS/2, this has been bantered about this community for many years. The Voyager Project was the last serious attempt at such a thing, (now deceased as best I can tell), and OS/3, (OSFree?), has been dealing with kernel replacement for many years now. The OS loader has been replaced and other bits as well. But as you stated, there is a definite lack of developers and such an undertaking will find itself more than a few sets-of-hands shy of a  team.

But it never hurts to speak about it again.

Maybe one day, enough bits and pieces will have been developed to actually put together a working clone... or to seriously talk about completing one.

For me that would be ideal, for I have no intention of going Windows, *nix or Mac, (or switching to any other OS for that matter). OS/2 does what I need while none of the other even comes close. Ergo: they are a waste of my time.

My only real beef with my favourite OS is that most of the latest software for it is crippled. Meaning that they do not take advantage of the power of the WPS and is hacked-off-at-the-knees in that regard, because all other OSs lack those specific WPS goodies.

That may seem on the surface, to be somewhat ungrateful with regard to all the new programs that have come out recently, particularly WRT the QT ports, but if that is how the reader interprets what I have written, I'll just point out now that is not the inspiration for those words; I am grateful for those who have made, (and are making), new software available to the OS/2 community.

It just isn't OS/2 software... rather just ports.

Of course, it has been so long since any real OS/2 software has been made, that most users have been unconsciously steered away from those nice, neat, WPS gems and are well into the interface standard GUI these days, (epitomized by Windows), and thus, have been weaned off that now hidden, WPS power.

Like you, just putting some thoughts into written words.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.19, 19:47:49
Here's the latest visible update:

I added a 'docs' folder to contain all important documents for this project.
I added a bit more focus & clarity to the plan.txt file.
I added a diagram that blue prints the current graphics stack for OS/2 & one that blue prints the changes that GL/2 will produces, along with future possibilities that may be opened up.

I've included those diagram files & the updated plan.txt file here.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.25, 18:51:33
Food for thought...the attached file is a possible direction.

P.S. You might have to be a member of OS2World to see this file!
Title: Re: OpenGL ddk
Post by: abwillis on 2011.04.25, 21:11:18
I see one of two reasons your looking to pipe pmgre through gl2pipe:
1)  Possibly an increase of performance going through 3D acceleration
2)  Ability to do something like set a generic resolution that then could be changed on the fly without a reboot so that gl2 is changing the resolution actually being displayed such that reboots would not be required.

Assuming option 1, then does that then rely on a less than generic driver 3D Component Driver?  Or is that something that gradd would be replaced by and still have a largely generic driver possible with maybe plugins required for specific chipsets?

Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.04.26, 00:34:57
I see one of two reasons your looking to pipe pmgre through gl2pipe:
1)  Possibly an increase of performance going through 3D acceleration
2)  Ability to do something like set a generic resolution that then could be changed on the fly without a reboot so that gl2 is changing the resolution actually being displayed such that reboots would not be required.

Assuming benefit 1, then does that then rely on a less than generic driver 3D Component Driver?  Or is that something that gradd would be replaced by and still have a largely generic driver possible with maybe plugins required for specific chipsets?

You're correct with choice number 1; I was looking for faster, more consistent acceleration. I realized that GRADD, Panorama, & SNAP are abstractions that are built around the old video driver interface, they're actually video drivers that accept plugins for actually controlling the device. After realizing this, I came to the conclusion that I probably would be better off if I eventually replaced the GRADD subsystem with a driver of my own that would never change (just one solid 2d driver). This would allow me to streamline the interaction between PMGRE.DLL & the actual screen, by stripping away some of the generics that are required when it's expected that you may be swapping out 2d drivers for upgrades to new hardware. By allowing the 2d driver to become a 3d client, the issues that are generally prevalent when synchronizing between the 2d & 3d render paths of a video card are removed. Also, since the PM will be drawing all of the windows & other screen items via 3d, an opportunity for a composite desktop opens up. One of the key benefits of this (in my eyes) is that there are less redraw messages flowing through the message queue, since none of the windows are technically occluding each other.

On the flip side of this design, all video drivers become full 3d drivers. This means that they will all be called by EMIT3D.DLL. These drivers, at a minimum, will have to implement the 3d 'stage' & the 'memory management' back-end interfaces. Both of these interfaces are very specific to the card itself.

I'll admit that benefit 2 didn't even cross my mind. I'm glad that you noticed & mentioned it, thanks! If this doesn't work out, a screen resolution API could be created that patches the compositor directly to the 3d component driver.

Now, for the appendage API that's hanging off of the right side of the diagram. I'm still not fully aware of how to make this portion work. The problem is not with the diagram itself, it's with the window bindings. Obviously, there are no OS/2 programs that use Direct3D; which means that there are no Presentation Manager bindings for Direct3D. This could help make D3D games feel more like first class citizens under OS/2, however, that would also require a tighter integration of ODIN into OS/2. With that being said, hopefully, ODIN will receive enough attention to allow Win32 games to seem a bit more seamless & harder to distinguish from native OS/2 games (present & future).

For me, one of the biggest benefits from this design is that it's a sensible evolution from the second diagram that I posted earlier. This gives me less pressure before reaching the final goal of what I really want to achieve. As an intermediate stepping stone, diagram two is what I'm shooting for achieving before Warpstock arrives this October. I hope I can beat the clock!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.05.04, 08:28:25
Ok, it's been a moment since I've last given an update, so here goes:

All of my work so far has been towards putting together a sensible memory management API that should allow the allocation & freeing of memory with a pool approach & a plugin based architecture. It's still VERY MUCH a work in progress & is only partially implemented at this time. The basic flow for memory allocation & freeing are:
MemManager::AllocMem()->MemGroup::AllocMem()->MemPool::AllocMem()->(*memory device)->alloc_mem()

MemManager::FreeMem()->MemGroup::FreeMem()->MemPool::FreeMem()

You allocate & free memory from the memory manager object. From that point, the memory manager uses the memory groups that're registered, which each use a set of memory pool objects. The actual memory device is only touched when it's absolutely necessary. Memory is only returned to the memory device when the pools are destroyed upon the destruction of the groups. Each memory group represents a physical memory device, whether it's system ram, agp memory, or local video memory. In turn, each memory group has to use the memory manager API to register itself. This interface allows future growth by allowing future memory devices to be assimilated by implementing a plugin based on RegisterMemGroup(), UnregisterMemGroup(), & the MEMFUNCS structure. There's still a lot of work left, so if I'm silent for a while, that usually means that I'm too busy coding & have lost track of time between postings! In order to make sure that my progress isn't lost, I've committed my latest work to the GL/2 repo.
Title: Re: OpenGL ddk
Post by: Ben on 2011.05.04, 13:36:10
It's good to read your update.

It would seem to me to be a problem for coders; Working in silence in a back room somewhere, out of sight and out of mind.

Meaning, (morale wise), it must only seem like a lot of work with little notice or reward... hours of staring at an endless stream of numbers and characters, loosing depth perception and feeling one's eyes crossing.

Whereas a builder can see the fruits of his labours with a real-time return.

I largely suspect that this is why many projects go stagnant as no one seems to notice that they're still alive and working hard...

Until the mummy unwraps itself and a new program is birthed, it can only be a labour of love shrouded in solitary, darkness.

Know, however, that the users wait in a sympathetic, frustrating, silence like an expectant father in the waiting room, not participating, yet highly aware.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.05.06, 20:58:51
Update (yeh, this soon):

I've finished the initial implementation of the memory manager api. This allows me to allocate blocks of memory for textures & what not. Now, I can move to the 3d emitter (EMIT3D.DLL). The task is to create a suitable group of constants, representing primitives & commands, to send to the video driver. In all likelyhood, this work will be combined with the task of fleshing out the GL pipeline (GL2PIPE.DLL).

That's all for now!
Title: Re: OpenGL ddk
Post by: Mike on 2011.05.10, 22:28:31
Quote
I've finished the initial implementation of the memory manager api

congratulations! It is amazing to see the speed of progress  :)  We cant wait to see the working code and soon after it the next step moving to the graphics driver part. Good luck for your project !
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.05.10, 22:33:58
Quote
I've finished the initial implementation of the memory manager api

congratulations! It is amazing to see the speed of progress  :)  We cant wait to see the working code and soon after it the next step moving to the graphics driver part. Good luck for your project !

Thanks! The first driver planned is GL2TST.DLL. Development will start on it within the next 2 weeks. It's a software based fully 3d rendering library that renders into a PM bitmap. This driver will be used to validate there rest of the GL/2 framework. The renderer is very generic & API agnostic; it's attached to the framework through the 3d emitter (EMIT3D.DLL). I'm still planning to attend Warpstock this October, but I know that there are many things that won't be in place yet. Still, I'll be very happy if I have the bare minimum necessary to display 3d onto the screen.
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.05.20, 18:21:27
Update:

The 3d emitter is mostly complete. The only portion that I haven't started work on is the framebuffer support. This won't be necessary until it's time to start stitching together the final parts of the GL/2 project which will require the compositing system. Maybe I'll come back to it & start working on it ahead of time, or perhaps I'll just wait & end up doing it when I actually need it; at this point, who knows! lol The hardware context needs to be fleshed out a bit more (still). I've made progress, but I won't get a better idea of what all should be included until I do more filtering through the OpenGL spec to figure things out a bit. It might also be prudent for me to do more digging on Direct3D, also.

My goal is to implement the whole setup in stages:

Stage 1: (initial components)

OPENGL.DLL
GL2PIPE.DLL
EMIT3D.DLL
TST3DDRV.DLL

Stage 2: (additional components)

GRE2GL.DLL (& WinOS2 counterpart, if necessary)
BUFFCOMB.DLL
MMAGP.DLL
MMSYSRAM.DLL (& possibly MMVMEM.DLL)
Hardware driver (possibly ATI RS480M, dependent on my secondary laptop being operational)

Stage 3: (optional components)

Here, we can start looking at a real attempt to get Direct3d support via DLLs for the interfaces of each version of D3D & D3DPIPE.DLL to contain all of the actual state management code.


I'm only shooting for Stage 1 for Warpstock America. As stated before, I'll be immensely happy if I'm at the point of displaying 3d primatives onscreen. However, if I'm able to attend the next WSE, I hope to have stage 2 mostly complete.

More to follow!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.05.20, 23:48:23
Update:

After a long round of chasing down syntax errors & logic bugs, I've finally gotten the latest version of EMIT3D.dll to build without any errors or warnings. To ensure that it is easily buildable by everyone else, I've included the OW project files. For those of us who aren't used to developing on OW, make sure you change these project files to reflect your build environment -especially as it relates to your include paths. In the future, I hope to find a solution that will allow the least possible amount of change between another developer's build environment & the one provided with the code. Unfortunately, that's one of my weaknesses as a developer & there are bigger fish to fry at the moment. If someone has any suggestions, I'm open to them & will do my best to evaluate them fairly.

Oh, yeh, before I forget! This code is provided in the spirit of openness. However, this code isn't 100% feature complete & should be treated as alpha quality code. Also, this code is useless by itself, so don't expect too much until other parts of the project begin to materialize.

More to follow!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.07.17, 21:13:07
Sorry it's been awhile. I haven't been able to work on GL/2 because of a combination of preparing to move & medical issues. Development won't continue until after the 1st of August. This will give me time to settle into the new house & put my office back together. More to follow.
Title: Re: OpenGL ddk
Post by: miturbide on 2011.07.18, 05:01:38
I wish you all my best Demetrius !!
Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.07.18, 05:11:31
I wish you all my best Demetrius !!

Thanks a lot! I've registered for warpstock & I'll be giving a presentation over what exactly GL/2 is. There's nothing to show visually, though.
Title: Re: OpenGL ddk
Post by: Mike on 2011.07.21, 22:45:07
welcome back Demetrius  :)

Quote from: demetrioussharpe
Hardware driver (possibly ATI RS480M, dependent on my secondary laptop being operational)

i good choice, i would vote for it when it may also work for a mobile ATI HD5xxx/6xxx graphics device  ;)

Quote from: demetrioussharpe
Sorry it's been awhile. I haven't been able to work on GL/2 because of a combination of preparing to move & medical issues. Development won't continue until after the 1st of August. This will give me time to settle into the new house & put my office back together. More to follow.

we wish you the best, take your time and then later we will have the warpstock news and wait till the next post here  :)

Title: Re: OpenGL ddk
Post by: demetrioussharpe on 2011.09.21, 08:33:35
Hello all,

It's been a long time since I've said anything & I feel that it's been quite long enough. There's no good way to say this, so I'll just say it. I'm getting a bit tired of certain aspects of GL/2. Working solo slows things down a bit & is wearing on me. There's only so much that one guy can do. Also, I see how many of the OS/2 community can be resistant to change. On top of all of this, the fact of the matter is that everyone is constrained by the limitations of the horribly aged OS/2 kernel. With that in mind, the following changes will be implemented:

1). I'm scrapping everything in GL/2 except the PGL layer.
2). I'm going to look at how the Mesa3d guys were able to get it to build under VisualStudio & apply that method to getting the same to work for OpenWatcom.
3). I'm going to write my AGP drivers to the specifications expected by the SNAP driver framework.
4). I'm going to dig through the source code to the WarpMesaGL port & try to understand how the author was able to tie Mesa3d to the GRADD API & try to do the same while attempting to shoe-horn Gallium3d into it all.
5). I'm going to graft my PGL layer on top of the SNAP mgl system (yes, I have the SNAP sdk/ddk).
6). I'm going to replace Mesa3d 4.1 that in the SNAP 3d ddk with a more modern version that used Gallium3d.

All of this should amount to a pretty modern & robust 3d stack that's achievable in a much shorter time-span than the roadmap that I was originally working towards. Couple that with the fact that Mensys now has the source to SNAP for OS/2 & you end up with a situation where everything ties into each other, because SNAP will be automatically included in eCS when they finish doing whatever they're going to do for integration purposes. It is very likely that I won't do much more in this area for this community after this work is complete. There's simply too few OS/2 developers & I really don't see a real reason to move to another big project without a real developer support system.

Just wanted to let everyone know what's going on & that I'm still at work. As time permits, I'll update the docs in the repo to reflect the changes.
Title: Re: OpenGL ddk
Post by: melf on 2011.09.21, 09:28:50
Hi demetrious,
it is nice to hear from you again. Your points 1 to 5 isn't really understandable to me but your statement
"All of this should amount to a pretty modern & robust 3d stack that's achievable in a much shorter time-span than the roadmap that I was originally working towards" sounds as a very good development to me.

Allthough working alone (in any business) gives you freedom to decide, it also, as you say, wears on you. Can't offer any help with your work though, but please get in touch if you need help with e.g. testing things or so. Good luck with your work.
Title: Re: OpenGL ddk
Post by: gap on 2011.09.21, 17:28:07
Hello,
I have not done graphics driver programming and not developed in C for some time.

Also I don't have the SNAP ddk. 

If this is not a problem then I might be able to help.

All my current work is in Java which I do for a living.