• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

OpenGL ddk

Started by tj81, 2009.11.07, 18:17:06

Previous topic - Next topic

Which is more important to you for OpenGL?

High precision rendering
4 (19%)
Sacrificing precision for render speed
6 (28.6%)
A balance between the two (IF possible)
11 (52.4%)

Total Members Voted: 0

demetrioussharpe

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?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

cyberspittle

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.

cytan

Quote from: cyberspittle on 2010.10.22, 16: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.


I second that.

cytan

demetrioussharpe

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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

One major question that needs asking is, "Has anyone released AGP support for OS/2?".
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

cytan

Quote from: demetrioussharpe on 2010.10.23, 04: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.

Good luck! Perhaps the ddk can also work on a low end ATI Radeon card?

jep

Quote from: demetrioussharpe on 2010.10.23, 04: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.

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?

Saijin_Naib

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.

demetrioussharpe

Quote from: cytan on 2010.10.23, 05:10:19
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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: jep on 2010.10.23, 08:07:00
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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: Saijin_Naib on 2010.10.23, 20: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.

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!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Tellie

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 :)

StefanZ

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 :)