Author Topic: OpenGL / Mesa3d  (Read 20860 times)

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
OpenGL / Mesa3d
« 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..

lpino

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Re: OpenGL / Mesa3d
« Reply #1 on: 2007.11.06, 12:51:17 »
Two problems here:

- Lack of hardware acceleration
- Lack of real interest on the OS/2 community

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
Re: OpenGL / Mesa3d
« Reply #2 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?

John

  • Newbie
  • *
  • Posts: 41
    • View Profile
Re: OpenGL / Mesa3d
« Reply #3 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?

Regards.

jep

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 421
    • View Profile
Re: OpenGL / Mesa3d
« Reply #4 on: 2007.11.06, 13:44:34 »
Hello,

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
Jan-Erik
« Last Edit: 2007.11.06, 20:28:33 by jep »

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
Re: OpenGL / Mesa3d
« Reply #5 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?
« Last Edit: 2007.11.06, 14:01:48 by Saijin_Naib »

Radek

  • Full Member
  • ***
  • Posts: 201
    • View Profile
Re: OpenGL / Mesa3d
« Reply #6 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!"

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
Re: OpenGL / Mesa3d
« Reply #7 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.

The Blue Warper

  • Full Member
  • ***
  • Posts: 116
    • View Profile
Re: OpenGL / Mesa3d
« Reply #8 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).

Regards

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
Re: OpenGL / Mesa3d
« Reply #9 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...

lpino

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Re: OpenGL / Mesa3d
« Reply #10 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

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
Re: OpenGL / Mesa3d
« Reply #11 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?

The Blue Warper

  • Full Member
  • ***
  • Posts: 116
    • View Profile
Re: OpenGL / Mesa3d
« Reply #12 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) 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.

Radek

  • Full Member
  • ***
  • Posts: 201
    • View Profile
Re: OpenGL / Mesa3d
« Reply #13 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.

Saijin_Naib

  • Hero Member
  • *****
  • Posts: 1357
  • Birdie Num-Nums
    • View Profile
    • Synperz Domain
Re: OpenGL / Mesa3d
« Reply #14 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.

Edit:
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.
« Last Edit: 2007.11.07, 22:13:36 by Saijin_Naib »