• 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

Quote from: Ben on 2011.02.13, 19:53:11
Quote from: demetrioussharpe on 2011.02.13, 19:00:08
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
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

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

demetrioussharpe

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

jep

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?!

cytan

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

Ben

Quote from: 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.

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.


miturbide

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
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

demetrioussharpe

Quote from: 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?!

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


We're of the same mindset in this regard.
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: Ben on 2011.02.23, 21:40:49
Quote from: 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.

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

Yes, it's based on Mesa3D. I think it's the 5.0 version of Mesa3D.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

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

demetrioussharpe

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

Vincenzo

#163
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

demetrioussharpe

Quote from: 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

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