OS/2 - Technical => Games => Topic started by: Saijin_Naib on 2007.11.06, 11:30:15

Title: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.06, 11:30:15
Im not sure if this is a horse that has been beaten to death far too many times, but here goes.

OpenGL, my favorite graphics accelerator. How I love thee, let me count the ways:
Blazing fast on Nvidia hardware, Brought me things like quake 1-4, Half life, Serious Sam.

However, OpenGL sorta died on OS/2 with 1.1 Gold, and Mesa 3d for xFree86/OS2 seems to have died in 1999 at the Mesa3d 3.xx level.

How hard would it be to pick back up official OpenGL support for OS/2 and get it current with Windows, Unix-derivatives, and OSX? I think OpenGL would open the door to a lot of possibilites with eCS and would maybe be a viable means to accelerate the user interface.

If OpenGL cant be done, how viable is Mesa3d now? Does it provide any performance gain?

Am I asking for something completely dumb and useless? Im not sure :\ Let me know..
Title: Re: OpenGL / Mesa3d
Post by: lpino on 2007.11.06, 12:51:17
Two problems here:

- Lack of hardware acceleration
- Lack of real interest on the OS/2 community
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.06, 12:57:42
 :-\ Yeah, I know both of those are big problems. However, with the possible? release of ATIs drivers as open-source for around december, there could be a large increase in hardware accelerated chipsets for eComStation. Myself, I only use Nvidia beacuse its what Ive used in the past, and I value its OpenGL performance best. What does it take to have hardware acceleration for a chipset?

Lets take for example my chipset: xfx 7600GT AGP card. What does it take to have hardware acceleration?
If OpenGL was written and implemented on the system level, would there need to be a hardware accelerated driver inbetween? Couldnt OpenGL just work with the card directly?
Title: Re: OpenGL / Mesa3d
Post by: John on 2007.11.06, 13:37:30
Personally I think it'd be the obvious thing to do- bringing Hardware Accelerated Graphics to OS/2 eCS. Compizfusion anyone?  ;) Think it'll attract more users to OS/2 eCS and open up more possibilities for the desktop, and possibly attract more developers?

Title: Re: OpenGL / Mesa3d
Post by: jep on 2007.11.06, 13:44:34

you may want to look at Panorama, but first the driver has to do 2D and be good at it for some more chips.
My hope was that some of the Scitech knowledge could be obtained, but Panorama seem to progress at a steady pace, along with the rest of the system.

Mvh / Wkr / MfG
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.06, 13:57:13
Well, if panorama ever does do 2d/3d for my chipset, then I will consider using it. As of right now, it only does VESA for my chipset, and no faster than the Scitech driver I am currently using. I do think that a nice, flashy GUI is important to help get interest in eCS. All the people I show it do dont notice the functionality and the way things work, only that it looks old and boring. And it does, but that doesnt bother me. Warp was the first GUI I ever used, so I like it alot. However, if we can get good 2d/3d, and better chipset support, there will be less reason for people to pass eCS as being outdated.

What would help with getting good 2d/3d acceleration for newer chipsets under eComStation?

Im not suggesting we change the WPS really. Keep the WPS the way it is now, but allow for schemes (eSchemes or eStyler/Lite) and other managers, but also have window effects like compviz or beryl. These should be in addition to the WPS, not replacing or changing it. We need to have eCS look modern and competent for it to get attention. This sadly is how I see people will react best. OSX and linux get the OOOOO SHINY! response. eCS gets the  ??? wtf is that like, DOS or something? response. And I go to a god-damned tech school.

Also for OpenGL, what would happen if the OpenGL libraries were written/ported to OS/2 before the display driver was capable of 3d?
Title: Re: OpenGL / Mesa3d
Post by: Radek on 2007.11.06, 14:30:09
That's it. Good graphics sells, "oooooh shiny!" is the first step in gaining a potential customer. Only then the potential customer will ask, what can OS/2 offer to him. Good graphics is awfully missing, the maximum we can show is a static wallpaper and a carefully devised desktop. Everyone can do the same and, at present, everyone can show more. Instead of "oooooh shiny!" we get "ueee", turning back, and going away. Only people, which know what they are searching for and which now a lot about computers, will ignore the lack of graphics and ask questions.

IMO, the most missing things in OS/2 are:
- Open GL
- better font rendering

Only then we can be "ooooh shiny!"
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.06, 14:42:18
Thank you! The important thing to note is, this should be OPTIONAL. The point is, if you want to have a nice rendered WPS, you shall have one. If you wish to be a bit more purist, dont use it (dont install it). The support for it MUST be there however. We need to have eCS evolve and stay attractive to the newer users. Having a GUI that looks like it is from 1994 will scare people away, and it does. With OpenGL and enhancements like compiz or beryl the WPS will function the same as before (amazingly well), but will be able to DRAW people who dont know why its different or what is good about it in, so they will get a chance to USE it and then feel why its awesome. If eCS and the WPS cant grab their attention and make it so they WANT to use it then they will most likely never give it a fair shot.

Short case study:

I have friends who all love trying other Operating systems. They sat by me and tried Vista, Ubuntu, Zeta, SkyOS, ReactOS, OSX, everything. My roomate tried practically every linux distro there is over the course of the past two weeks, but he REFUSES to try eCS. Why? Because when he sees me work on it, he sees an os that came straight outta 1994. He doesnt care that GNOME modeled itself a little after the functionality of the WPS, that eCS can do most everything his linux distros can. Why? Because it looks like it cant. he was "meh" with linux until he tried beryl and compiz, since then, he plays with linux all day long. This is what eCS must be able to offer. If the user isnt interested, the user wont give it a fair chance. eCS must evolve with the environment, and the environment of today demands "SHINY". As much as I hate it, I love shiny. Its cool, its different, it allows you to make your environment your own. eStyler/Lite affords me a little control, but more would certainly be welcome.
Title: Re: OpenGL / Mesa3d
Post by: The Blue Warper on 2007.11.06, 17:33:30
Well, OpenGL and/or hardware accelerated graphics under OS2/eCS would require more time than I can currently dedicate.  I'll submit some of my thoughts now, which I hope I can integrate later.

First of all, generally speaking, one could implement those nice-looking effects even without accelerated graphics drivers: you would do that by means of software rendering.  But here comes the first point.  When you want too complex graphic effects (for example, font anti-aliasing, leaving alone icon antialiasing; alpha-blending; fast animations, etc.), doing them at software only level would slow down the rendering process, even on a fast machine.  And we're talking about the OS GUI here, not its applications (think about an application who actually heavily relies on graphic computations in order to perform its tasks: for example, a video player app, or a 3d modelling app, a CAD app, an image editing app, etc.), which would raise the computing demands even higher.
This is where hardware accelerated hardware comes.  Basically, it does its calculations in hardware, rather than in software: i.e. it has some dedicated chips specifically optimized for certain purposes (for example, if a game requires a fog effect, or a rain effect, etc., the game rendering engine could render the effect using software-only routines (slower), or 'pass' the 'raining-routine' to the graphics card (faster, 'cause those effects will be treated by a dedicated CPU, which is DESIGNED for performing just graphics-related routines, and which has an own memory, etc.), if it knows that the graphics card CAN actually perform that task in hardware.

And here we reach another point.  How can an app (or the WPS, if this is the case) know whether it can make use of hardware-accelerated functions/routines?  We have here two possibilities (AFAIK, of course):
a) the app can be designed to specifically take care of the graphics card (this is a sort of tight integration between software and hardware: this way you could theoretically achieve a very high-level graphic workstation, but at the expense of portability (as every change in either the hardware or the software would cause a correspondent change in its counterpart));
b) the app can be designed without the need to actually knowing if any hardware-accelerated function is available in the system.  Whenever a graphics output and/or rendering function must be performed, it just passes it to a dedicated module of the OS, who knows if that action can be performed at hardware- or at software-level.  In order to do so, it's essential that the OS kernel is LAYERED, i.e. structured at different layers going from low-level hardware interaction to high-level hardware abstraction.  Every single primitive graphic action should then be defined, so that every time an app (or a process) needs to execute it, the app can call the corresponding routine pre-defined in the kernel.  The Hardware Abstraction Layer (HAL) in the kernel then decides if it must be performed by hardware or by software.  How does the kernel knows that?  It knows because whenever a driver is installed, it 'tells' the kernel what kind of actions its corresponding hardware can do at hardware level and what cannot (i.e. what needs to be executed at software level).  This is basically (according to what I know) the way acceleration works in Windows systems (DirectX).

So I see two issues here with the current OS2/eCS situation:
a) AFAIK, the OS/2 kernel lacks a true (or at least a modern) HAL;
b) in order to get a hardware-accelerated driver, you actually need to know the hardware: I mean, you need to know what a single graphics card can do (i.e. its features) and, above all, how you can have that very graphics card do it for you (in fact, for your software).  In other words, if you want to implement at hardware level certain functions, you need to know the hardware specs of the card, and you need to know how you can interface the card with your software, i.e. how you can 'program' the card.  This is not as easy as it might seem, because the hardware makers use to keep the specs closed, probably in order not to let their competitors know them (and maybe - but this is a actually a guess - in order to get payed by those who need to implement them within their software).  This is one of the reasons I know of why Scitech eventually dropped the development of its graphics drivers suite, because hardware vendors weren't collaborating so much in sharing the specs of their products (especially nVidia, for what I read).

As for the first point (OS2 kernel lacking a HAL), there's not too much we can do about it.  OS2 was designed without a true hardware layering subsystem, at my knowledge (maybe this is not totally true for OS/2 PPC).  But I remember that, starting with WSeB kernel (Warp 4.52) IBM introduced a kind of modules capable of directly interfacing with the kernel in order to 'discard' certain tasks from the kernel to the specific module, and I'm talking about PSD [Portable Specific Device: memory quoting...] modules here.  The best known among them is perhaps OS2APIC.PSD which came with the OS/2 SMP kernel; and the most recent one is the ACPI.PSD component developed for eCS 2.x.  For some reason, IBM didn't make extensive use of this technology, and I myself don't know much about it (it seems that little docs are available on this topic), but I seemed to understand that it could be the way IBM meant to layer (or kind of layering) OS/2.  For example, I remember that in a WSeB Fixpack I saw a file named trident.psd (which I took for a sort of 'layer' module responsible for interfacing between the kernel and the Trident graphics driver: but I'm only guessing here).
The approach undertaken by the ACPI developers seems to show that some kind of hardware layering is possible under OS/2 using the PSD technology (so one would imagine to create for example some PSD modules for the various CPUs: i.e., for example, a Pentium3.PSD, a Pentium4.PSD, an AthlonX2.PSD, and so on, each of which having its dedicated set of instructions specific for that very CPU [one could finally get support for SSE, SSE2, etc., instructions sets at kernel level, what'd mean system-wide, i.e. granting CPU code optimization for all applications]), and so on...

There would be so much more to say about this topic (for example, I think we should look with greater interest at what Netlabs is doing with the Voyager project, which aims in the end to overcome some of these limitations under OS/2.  And for the time being, if one would like to try some visual effect under OS/2, he could try the new icon-addon for WPS Wizard available at Netlabs', which adds antialiasing to the OS/2 icons: the screenshots look very promising, and I installed a former version in my system some time ago...), by I've really got to go now...

Take the above as a contribution to the discussion.  These are my opinions and thought, and please keep in mind that I'm not a developer nor a technician, so maybe I said something technically wrong (but this is information one can easily find and verify).

Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.06, 22:04:16
Hmm, so its clear that software acceleration is out of the question, and I know this already because VESA is NOT bearable at 1280x1024x32bbpx75hz which is the native resolution of my LCD.

Is the SNAP driver package extendable? How about the Nvidia/ATI linux driver packages? ALSA works well for UNIAUD, could we not make a UNIVID that is similar?

I really dont know what is required so forgive my ignorance...
Title: Re: OpenGL / Mesa3d
Post by: 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). Clearly they are way short of their goals but at least with SNAP gone they got enough attention -> ergo; money, to continue their development in a more conservative way. Maybe they won't say that they will bring 3D acceleration today, but if we are lucky and if they survive ... who knows
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.06, 23:44:58
At this point, I would just LOVE 2d acceleration. 3d acceleration is a "it would be nice one day" thing. But Mesa3d/OpenGL and 2d acceleration would be all it would take to have the eCS WPS be really shiny and cool like compviz or beryl, and therefore more attractive to today's ALTOS prospectives. Plus, I wouldn't mind the WPS with some bling :) Also, its SO painful to not have 2d acceleration on a resolution/bitdepth like I am using. Ugh...

How different are each graphics chipset from another?
Should not all Nvidia GPU that support lets say, HW overlay and PixelShader 2 and above or OpenGL 1.5 and above have the same capabilities and be accessed in the same way? So wouldn't we only need to have a simple stripped down driver to call that ability?
Title: Re: OpenGL / Mesa3d
Post by: The Blue Warper on 2007.11.07, 03:32:48
Another fast reply ;-) ...

SNAP graphics was, in my opinion, a very good attempt to bring 2D hardware acceleration to OS/2.  So if your card is supported, you should have good to very good performances with it.  Mesa3D and OpenGL are graphic subsystems mainly targeted at 3D operations, meaning that in a normal desktop environment you don't normally need them (I can think of Vista's visual switching of the apps being executed in the system as an exception where 3D acceleration is really needed at 'desktop-level', so to say).
Where one would really welcome 3D acceleration is when one has to run some apps needing to handle 3D, such as CAD apps, simulation environments, apps doing 3D graphical animation, games, or whatever.
Currently these are areas mostly (or maybe totally) uncovered under OS/2, and it would be fine to have this kind of acceleration, but 3D acceleration is not required in order to have those nice visual effects on OS/2.  We'd need to change those components of the OS responsible for handling the drawing and rendering on the screen, i.e. the GPI unit (the low-level library to which in OS/2 the drawing tasks are committed): I think this task is mostly performed by the PMGRE.DLL (I'm quoting from memory here).
When these OS/2 graphical routines first came out, they were absolutely current if not superior compared to many other desktop OSs for the times.  I remember having read some comments some years ago by a game developer who coded for OS/2 before leaving for Windows, who said that when Warp 4 was in beta ID Software made an OS/2 native version of Doom which was exceptionally fast compared to the DOS one, due to the GPI libraries and the multithreading architecture of the OS, but, misteriously enough (even though we OS/2 users are somewhat accustomed at these kind of 'mysteries'), the GA version was never released.  So IBM slowly lose his technological advantage in this field, as they never managed to market their OS to the desktop/home users, thus never enhancing those parts of the system that could better attract most of them, and about one year later MS shipped Win95, which became the main platform for playing games (what caused - and even boosted - the race in the hardware accelerated video cards).  As MS worked side by side (again, this is what I think about how things went) with some hardware makers, they could get the specifics of the newer OS versions, and the corresponding developing tools before the competitors; and, on the other side, MS could implement the Windows software counterparts that they actually knew would be introduced in the next generation of graphics cards.  And so on.
The OS/2 low-level graphics subsystem imposes some limitations that IBM never managed to overcome.  I could list two of them here.
One limitation is that, as the font rendering is done by the PMGPI unit, and as that only handles monochrome fonts (but this was absolutely normal for the time, and under OS/2 (monochrome) font rendering, though not exactly neat, was/is very fast: that was indeed the reason why they implemented it this way), you can't have the GPI render antialiased fonts (Innotek font engine is a well-done (I think) attempt to bypass the GPI-rendering engine, but that is an add-on, not something that was put there at OS design-time).
Another limitation inherent to the Presentation Manager is that it can't draw non-square windows, and it doesn't know about alpha-blending (so normally no transparency effect).
These limitations could only be overcome by rewriting those parts of the OS that currently handle these tasks.  Hardware acceleration is not strictly necessary to do this (Win95 could draw non rectangular windows at its time, though not antialiased), as one would need to 'just' rewrite the code, but... OS/2 is closed source, so another solution should be found.

For the time being, I'd suggest giving a try to WPS Wizard, which can display some special transparent window (actually widgets) containing useful information about the system, AND antialiased, variable-sized (maybe even user-selectable sized, if I recall correctly now) icons.  The Noia Icon set is very nice.
[2 David Graser: Did you try this WPS-Wizard Icon Addon?  I think you might like it].
For what I was able to understand, this work done on WPS Wizard is part of Voyager developing.  Voyager is perhaps one of the currently most underestimated projects in the OS/2 community.  Maybe this is due to the fact that almost nothing has been released so far.  But, considering the people who are behind it, I think they can succeed in it at last.  Among the other goals, Voyager aims at developing a hardware-accelerated Workplace Shell (and eventually a WPS-like, WPS-compatible desktop).  See the Voyager pages on Netlabs (http://wiki.netlabs.org/index.php/Voyager (http://wiki.netlabs.org/index.php/Voyager)) for further details.

As for HW overlay/PixelShader2/OpenGL question, I'm not a technician, so maybe I'm wrong.  But I'd reply that:
a) HW overlay support for some graphics card (unfortunately not the current ones) does exist for OS/2 (the problem is that few applications are designed to take advantage of it).
b) Pixel Shader 2 and similar 3D-rendering functions need a graphics card that can handle them (unless one wants to have them software-rendered, which probably is not the best solution in terms of speed...), and again, if you don't know how a card is made, how it works, how you can develop for it, which functions you must call in order to make use of its features, you cannot write a full-featured driver.  I know there are Linux drivers for nVidia and ATI cards (never managed to install any Linux yet, though I'd like to do ASAP), but simply having the source is not automatically having the code for another OS, which is especially true in matter of drivers, as every OS has its own driver model.  OS/2 drivers are different from Linux ones, so a great amount of additional work would be needed to adapt the Linux sources to the OS/2 system (and I think the opposite is also true).  That's why I think that many apps were more or less easily ported from Linux to OS/2, though very few drivers.
c) OpenGL 1.4 (I seem to remember) was actually included in the SNAP drivers (at least the latest versions).  It was a software-only implementation (that was reasonably fast, all in all, as from the demos that came with the tuning app), but AFAIK there was (and there is) no graphical app that relied on them.  This lack of demand on the user and/or on the developers' side was probably what caused Scitech not to put too much efforts into developing a hardware-accelerated version of OpenGL.
Title: Re: OpenGL / Mesa3d
Post by: Radek on 2007.11.07, 11:12:04
The Panorama guys have done a very good work. I am using Panorama at 1920x1200x32 (I cannot use SNAP) and I see almost no jerking when I move windows (windows, not frames) or when an app scrolls a long text in a window. Panorama is, in my experience, considerably faster than SNAP VESA.
Nevertheless, Panorama is VESA, that means painitng pixel by pixel, even if using sophisticated algorithms and even if painting by means of a fast video card. You will be never shiny with Panorama.

IMO, we awfully need a "Return of SNAP" of some kind. We need a video driver, which is at least 2D accelerated and which is at least helpful in making the desktop tidy and attractive. Perhaps, the driver will not support all video cards and, perhaps, it will "specialize" only in the most used ones. The driver should also support more complex graphics manipulations (Open GL, perhaps only a subset).

As far as the lack of interest in Open GL among the OS/2 developers is considered, I think it is a result of the current state of OS/2 Open GL. We can draw only small Open GL windows, the Open GL window jerks when it is moved or resized, animation is slow and it loses frames frequently. In the other words - unusable.
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.07, 21:06:06
I would love to support Panorama, but it does not support any of my chipsets, which leaves me with using 2 products that dont support my card. I cant get SNAP to keep noncert on, it clears instantly. I was hoping that forcing acceleration on and forcing noncert would make it accelerate my interface, but I think I need the full version to do that, not the eCS bundled version.

Installed Panorama and turned on Shadow buffer, and WOW. 100x faster than SNAP VESA. So, Panorama is looking pretty good for VESA. However, I still want 2d accel and OpenGL or MesaGL.
Title: Re: OpenGL / Mesa3d
Post by: 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.
Title: Re: OpenGL / Mesa3d
Post by: 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?
Title: Re: OpenGL / Mesa3d
Post by: madcrow on 2007.11.08, 23:39:36
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...
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.09, 00:02:40
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.
Title: Re: OpenGL / Mesa3d
Post by: lwriemen on 2007.11.09, 17:41:39
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.)
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.09, 17:45:06
So on a scale of 1-10, 10 being impossible, how hard would OpenGL/Mesa3d and 2d or 3d acceleration be under OS/2?
Title: Re: OpenGL / Mesa3d
Post by: lwriemen on 2007.11.09, 17:46:01
Did a search on "hardware accelerated 3D" OS/2, and found this link.
http://www.edm2.com/0602/opengl.html (http://www.edm2.com/0602/opengl.html)
...which contains:
First 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.  :'(
Title: Re: OpenGL / Mesa3d
Post by: StefanZ on 2007.11.09, 19:31:16
Have you ever seen this?


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?
Title: Re: OpenGL / Mesa3d
Post by: The Blue Warper on 2007.11.09, 22:34:16
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 (http://ftp://ftp.netlabs.org/pub/odin/Daily/opengl3dfx.zip)
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.10, 05:07:37
 :-[ 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?
Title: Re: OpenGL / Mesa3d
Post by: BigWarpGuy on 2007.11.11, 00:00:29
ftp://ftp.netlabs.org/pub/odin/Daily/opengl3dfx.zip (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
Title: Re: OpenGL / Mesa3d
Post by: magog on 2007.11.15, 03:32:50
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

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

The sample driver includes:

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/
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2007.11.15, 20:44:35
So Magog. What does this discovery mean. Do we have a working basis for OpenGL or Mesa[gl] under os/2?
Title: Re: OpenGL / Mesa3d
Post by: magog on 2007.11.16, 00:26:39
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.

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.

If anyone is interested in the hardware OpenGL DDK package (~9 MB) send a PM.
Title: Re: OpenGL / Mesa3d
Post by: lwriemen on 2007.11.20, 04:26:04
Didn't see a mention of this, so I thought I'd post it.

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.
Title: Re: OpenGL / Mesa3d
Post by: magog on 2007.11.21, 00:28:22
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.

As I said the specs for the G400, the old 3dfx cards and also newer Intel chipsets with integrated video are pretty open.
There has also been done some Reverse Engineering for some older nvidia graphiccards:

And also for the ATI R300/R500 chipset:

Here is a 22 MB source package from Intel:

For the ATI R300 there seems to be enough data out there to get an accelerated OS/2 3D driver working as the code was already used playing Quake 3 on Linux.
Title: Re: OpenGL / Mesa3d
Post by: magog on 2008.04.09, 16:42:22
Now VIA is also starting an open source development initiative:
http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=2088 (http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=2088)

VIA Announces Strategic Open Source Driver Development Initiative
VIA to provide vehicle for improved collaboration with Open Source community with opening of official VIA Linux Website

Austin, Texas, 8 April 2008 – Today at the Linux Foundation Collaboration Summit, VIA Technologies, Inc., a leading innovator of power efficient x86 processor platforms, announced a new initiative to improve support for the Open Source development community.

As the first step in this initiative, VIA will open its official VIA Linux website at http://linux.via.com.tw/ this month. The site will initially host drivers, technical documentation, source code, and information regarding the VIA CN700, CX700/M, CN896 and the new VIA VX800 chipsets, with plans to add official forums and support for more products later on in the year.

Over the following months, VIA will work with the community to enable 2D, 3D and video playback acceleration to ensure the best possible Open Source experience on VIA Processor Platforms.

To further improve cooperation with the community, VIA will also adhere to a regular quarterly release schedule that is aligned with kernel changes and release of major Linux distributions. In addition, beta releases will be issued on the site as needed, and a bug report and tracking feature will also be integrated.

"This announcement is the first step in the implementation of our new initiative to better serve the needs of the Open Source community," commented Richard Brown, Vice President of Corporate Marketing, VIA Technologies, Inc. "We are strongly committed to improving the levels of collaboration with the community and adopting a more consistent approach across VIA Processor Platform technologies."

"We are delighted that VIA has announced its commitment to enhance support for the Linux and Open Source community," commented Jim Zemlin, executive director at The Linux Foundation. "This action will open up exciting new opportunities for accelerating open source innovation around VIA platforms and ultimately delivering a better user experience."

The drivers and documentation will be available later this month on:
 http://linux.via.com.tw/ (http://linux.via.com.tw/)
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2008.04.09, 18:49:01
Yeah :) The unichrome driver project. I have that chipset on my current motherboard, I wonder if eCS would run nice on it?
Title: Re: OpenGL / Mesa3d
Post by: craigm on 2008.04.10, 02:38:12
OpenSNAP is now becoming a reality!!!

Do you all think this can help us with openGL?
Title: Re: OpenGL / Mesa3d
Post by: Saijin_Naib on 2008.04.10, 05:25:10
That's my wish Craig, that's my wish :) I envision eCS with Hardware graphics, OpenGL, and an interface effects engine like compiz-fusion, so that we may draw in those who would otherwise ignore eCS because of how outdated the WPS appears.
Title: Re: OpenGL / Mesa3d
Post by: demetrioussharpe on 2011.01.04, 01:25:32
Hello, I'm Dee from GL/2. 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? To reply, please post your answer at:

http://www.os2world.com/forum/index.php/topic,1940.0.html (http://www.os2world.com/forum/index.php/topic,1940.0.html)