• 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 / Mesa3d

Started by Saijin_Naib, 2007.11.06, 11:30:15

Previous topic - Next topic

madcrow

Wasn't some groundwork laid for possible 3D acceleration in Warp 4? I remember hearing about beta 3D drivers for like Voodoo 1 bieng in closed testing or something once but I don't think they even made it into "open" beta. Still, if it was done at all, then writing the driver would have to start with finding out what (presumable undocumented) hooks were put in place for hardware 3d and go from there.

Saijin_Naib

How would one go about getting that info? Is IBM forth-coming with stuff like that or not?

madcrow

Quote from: Saijin_Naib on 2007.11.08, 23:29:08
How would one go about getting that info? Is IBM forth-coming with stuff like that or not?
I have my doubts as to whether there's anyone left around who even knows. It really is a shame that no hardware 3D drivers ever made it to public release of any sort for OS/2. Given the fact that some new video cards are now shipping without any sort of tradition framebuffer, but instead treat 2D as a simple subset of 3D texture operations, the need for hardware 3D support could soon be more than just a nice thing for games, but could soon be needed to get any sort of display at all...

Saijin_Naib

Slightly terrifying :\
I was just hoping to have a nice, neat accelerated interface, especially for video playback. It wouldn't hurt to have an interface effects system akin to compviz or beryl (as I mentioned before) to help keep OS/2 looking modern and help to possibly generate more interest.

lwriemen

Quote from: madcrow on 2007.11.08, 20:33:01
Wasn't some groundwork laid for possible 3D acceleration in Warp 4? I remember hearing about beta 3D drivers for like Voodoo 1 bieng in closed testing or something once but I don't think they even made it into "open" beta. Still, if it was done at all, then writing the driver would have to start with finding out what (presumable undocumented) hooks were put in place for hardware 3d and go from there.
I believe you are right. IIRC, hardware accelerated 3D is possible under OS/2. I don't even think it requires knowledge of some undocumented (OS/2) hooks. I think the factors affecting it were:
1) Lack of a market; Part of this is affected by support for OpenGL vs. ActiveX by game developers. I think if you search for it, you'll find some discussion by Brad Wardell on this subject.
2) Lack of documentation for the graphics chipsets; This is greatly improved from the last time I remember seeing discussion on this subject.
3) Limited number of knowledgeable developers. (Requires knowledge of writing OS/2 device drivers as well as 3D acceleration on graphics chips.)

Saijin_Naib

So on a scale of 1-10, 10 being impossible, how hard would OpenGL/Mesa3d and 2d or 3d acceleration be under OS/2?

lwriemen

Did a search on "hardware accelerated 3D" OS/2, and found this link.
http://www.edm2.com/0602/opengl.html
...which contains:
QuoteFirst some news: As was reported on several of the OS/2 news sites including  WarpCast , the AIX group has transferred the code for an accelerated OpenGL toolkit to the OS/2 group just before December. As the developer states, there is a lot of code and he doesn't expect the toolkit to be in a position to be released for several months, but at least it is being worked on. Expect the card manufacturers to take a few months on top of that for development time. Hopefully there will be a large number of 3D accelerated cards in people's Christmas stockings next year.
Too bad it was never realized.  :'(

StefanZ

Have you ever seen this?

http://youtube.com/watch?v=GF3wXTExzbM

I personally am not sure if this could be called a "real native" OS/2 HW 3D acceleration, but there IS a HW 3D acceleration for Odin supported on a specific hadrware.

What about that? Specialists: any comments?

The Blue Warper

Under Odin in fact there was hardware-accelerated (via Mesa GL) support for 3dfx Voodoo cards:
For anyone having this hardware, the driver is on Netlabs archives:

ftp://ftp.netlabs.org/pub/odin/Daily/opengl3dfx.zip

Saijin_Naib

 :-[ Alas, I do not have said hardware, but fortunately, my computer is sufficient to software render and still achieve acceptable frame-rates. That is promising however, to have 3d support from MesaGL though only for the 3dFX cards.

Okay, so question time:
If we had a working, up to date OpenGL/Mesa3d port for eCS, what would that do for us?

If said above system is in place and working, what would be required to have 3D acceleration under graphics chipsets?

Is this a viable goal? Is this something anyone other than myself cares for?

Does anyone have the knowledge to accomplish either 1, 2, or both?

BigWarpGuy

ftp://ftp.netlabs.org/pub/odin/Daily/opengl3dfx.zip I tried the above link but it did not work. I have searched the ftp part of Netlabs and found the above link. I hope it works.  ;D
8)

magog

#26
Quote from: lpino on 2007.11.06, 23:35:43
This is a subject that come and go all the time. To get a truly 3D accelerated driver you need a lot of work under the hood. There were some progress a long time ago first using EnDive and then GRADD filters. Those were based on the OS/2 video driver model (GRADD). Then came SNAP and built a nucleus (a sort of kernel) around GRADD which you could add support for chipsets as plugins, but the support was only for 2D acceleration. They (Scitech) never said that it was imposible to add 3D support, only that it was too hard -> ergo; too expensive to do it.

Then you have Panorama driver. I have an old presentation of their goals and one of them was to have accelerated 3D support (they mentioned the Mesa library not OpenGL).

Mesa[GL] (it's not allowed to call it MesaGL any more) is OpenGL
SciTech did have a compiled Mesa for OS/2 but I don't know when they updated it the last time. I might ask Steve about it maybe he knows or has the source somewhere. The SciTech Mesa port was Software accelerated only but better then nothing.

IBM did have a hardware accelerated OpenGL Toolkit back around 1994 or something (when there was OpenGL 1.1 Gold). Someone at IBM accidentially released this toolkit in 1999 or 2000 on IBMs FTP-Server and it was deleted after ~2-3 days. I still have a copy of it on my external harddrive (at least there it should be). The problem is that this toolkit could only be used by people that had an OpenGL license from SGI. This was expensive and actually nobody had this. I also think that IBM wanted to see some money for this toolkit.

I think hardware acceleration using this toolkit can only be done in full screen mode and not in a window but that might be interesting for other people to figure out
I think I'll look at the harddrive in a few moments...  ;D

UPDATE:
...got it...The postscript files in the archive tell me the DDK it's from 1st May 1998.
Beside some additional archives there are the following documents (Lotus WordPro + Postscript):
OpenGL for OS/2 Device Driver Sample Adaptation Guide (May 1, 1998)
and
OpenGL Rasterizer Interface - IBM Confidential (May 1, 1998)

I was right it's OpenGL 1.1. The device driver sample is for an Omnicomp 3DEMON adapter which is using an 3DLabs GLINT 300SX chipset.
I was wrong that it would require full screen.

The OGL-DDK file lists these features:

  • OpenGL acceleration in an OS/2 window
  • accelerated color and depth buffer clears
  • accelerated flat and Gouraud shaded triangles, with and without depth buffer enabled
  • fullscreen double buffering synchronized to vertical retrace
  • asynchronous DMA operation for GLINT

The sample driver includes:

  • source code for an OS/2 GRADD display driver (GLIGRADD) for PM and Win-OS/2
  • source code for PGL for OpenGL on OS/2
  • source code for complete rasterizer support for OpenGL on OS/2; with both full software function and sample GLINT hardware acceleration (requires SGI OpenGL source license and IBM nondisclosure agreement)
  • source code for a Rendering Context Manager (RCM) to handle different rendering contexts using an accelerated rasterizer
  • source code for a physical device driver (PDD) to handle DMA transfers and vertical retrace interrups

Here we have a problem:
The GLPIPE.DLL module, which provides geometry pipeline processing for OpenGL on OS/2, is provided as binary-only module. Also, IBM continues to provide a binary-only alternate RASTER.DLL module, which is a highly optimized software-only rasterizer for OpenGL on OS/2.


The documentation then describes to ways how to do 3D hardware acceleration on OS/2.
1st - Replace RASTER.DLL with an accelerated rasterizer, which is described here.
2nd - Replace both GLPIPE.DLL and RASTER.DLL modules. This approach would be necessary to accelerate functions in the OpenGL geometry pipeline as well as rasterization. The PGL source code is provided to support this approach.

By the way the GLINT 300SX has been available from 3DLabs in 1994!

You can find details about the Glint processor here: http://www.faqs.org/faqs/pc-hardware-faq/3dgraphics-cards/part1/
Regards,
Juergen
*** Java Movie Database - http://www.jmdb.de/

Saijin_Naib

So Magog. What does this discovery mean. Do we have a working basis for OpenGL or Mesa[gl] under os/2?

magog

#28
Yes and no. ;)

Personally I would say yes we should use this DDK in order to get accelerated OpenGL (or better the Open implementation Mesa 3D, so we don't harm SGIs OpenGL license) on OS/2 and eCS since it is abandonware by the IBM.
A lawyer would most likely say no because it wasn't officially released and we would more or less build upon stolen property (can we get around the binary only DLLs provided in this package?).
The problem is that looking into source and using ideas (even if implemented differently...some things can't be implemented that differently) you will most likely break patents.

Then in the meantime SGI has opened the licensing stuff, but I don't know if this can be automatically transported back in time and used for the stuff from IBM finished in 1998.
http://www.sgi.com/products/software/opengl/license.html
http://www.opengl.org/

Then is there the question for which hardware can we implement the accelerated driver?
Currently this would be 3Dfx and possibly Intel's onboard graphic chipsets (I think they are pretty open). AMD/ATI hasn't released enough specs I think but this may change...for older ATI chipsets there may have been done enough reengineering.
Finally it might also be possible to add hardware acceleration to some point for Matrox G400 that was pretty well documented if I recall correctly.

The next question is how far can it be pushed?
I don't know if there is more possible then just the rasterization stuff that is described in the docs as I'm not a graphic device driver developer and have never done anything with 3D graphics.
For a full featured OpenGL/Mesa 3D implementation there are not enough resources available (programmers that can do this). So the only option would be a stripped down version (OpenGL light) which is called OpenGL ES (http://www.khronos.org/opengles/2_X/)....or it would be based on Mesa 3D.

At the Mesa 3D website there is a recent note on their hardware device driver toolkit called Gallium3D (it's a codename).
There is a software only driver and one hardware accelerated driver for Intel i915/945. It's based on the stuff from tungsten graphics.
http://www.mesa3d.org/
http://www.tungstengraphics.com/wiki/index.php/Gallium3D

If anyone is interested in the hardware OpenGL DDK package (~9 MB) send a PM.
Regards,
Juergen
*** Java Movie Database - http://www.jmdb.de/

lwriemen

Didn't see a mention of this, so I thought I'd post it.
http://wiki.opengraphics.org/tiki-index.php

This is a project to provide a completely open graphics card. It will have all the information available for writing at the device driver level, which I haven't seen for any of the other cards.

At the very least, it would be a good way to get some experience in case some of the proprietary graphics vendors become more open with their specs.