Poll

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

Author Topic: OpenGL ddk  (Read 70237 times)

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #180 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
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Ben

  • Sr. Member
  • ****
  • Posts: 367
  • What is really important?
    • View Profile
    • The Self Wrighting Network
Re: OpenGL ddk
« Reply #181 on: 2011.04.02, 16:26:46 »
Sorry mates, mind the date! lol

Ahahhahahaah!

All the steps except the conclusion...

Ahahaha!


 :o

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #182 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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Ben

  • Sr. Member
  • ****
  • Posts: 367
  • What is really important?
    • View Profile
    • The Self Wrighting Network
Re: OpenGL ddk
« Reply #183 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.

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #184 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.
« Last Edit: 2011.04.19, 19:49:24 by demetrioussharpe »
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #185 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!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

abwillis

  • Sr. Member
  • ****
  • Posts: 325
    • View Profile
Re: OpenGL ddk
« Reply #186 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?


demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #187 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!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #188 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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Ben

  • Sr. Member
  • ****
  • Posts: 367
  • What is really important?
    • View Profile
    • The Self Wrighting Network
Re: OpenGL ddk
« Reply #189 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.

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #190 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!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

Mike

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: OpenGL ddk
« Reply #191 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 !

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #192 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.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #193 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!
« Last Edit: 2011.05.20, 18:23:31 by demetrioussharpe »
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: OpenGL ddk
« Reply #194 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!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!