OpenGL 2.0 is out

1

Ok folks, OpenGL 2.0.

The first step for having 3D applications is to have a 3D API available, all the basis/structure for drivers and the communication between them.

With OpenGL 2.0, now we have pixel/vertex shaders and all the new features that only DirectX had made available to developers.

With OGL 2 we now can program the new video boards using them fully.

Having a solid implementation of the standard and creating a very good structure for drivers is the main step to accomplish, I think.

Even that we don’t know how to develop 3D drivers in the actual state, without a base we cannot develop a single instruction. You know what I mean. How could you develop 3D drivers if you don’t know even what functions they should provide?

Thinking about help from the giants: NVIDIA won’t help much (we all know that) but maybe ATI could help just a little. Like they did to the 2D drivers. Came to think about it, why not asking a suggestion for them on how to develop the base structure for the drivers? Why not try? Why not? Nothing officially, just as an suggestion, like we all do here. I don’t see a point why not doing this. I mean not depend on them to develop, but at least take their suggestions (if they are willing to give).

By the way, it’s a (mine) suggestion for the initial release of Haiku. I don’t see a point why not having 3D or why not implement the latest version of a standard.

And I know, I know… I’m saying that like it’s an easy thing to accomplish. But at least, here is my speech.

Well, I know that you all know what is needed and how to develop the kit, drivers, this and that (and off course, could correct a thing or two on what I wrote), but the main intent of this post is the approval of OpenGL 2.0 in Haiku. Nothing that would be decided from a single post, I realize that but at least I’m trying.

Thanks for reading.

Doca

2

Haiku is using MESA for OpenGL, so if MESA supports OpenGL 2.0, Haiku will too. Simple as that.

3

I just don’t like MESA…

But well… who am I to tell a word about it…

4

Feel free to code a complete, just as fast, DRI supporting GL library.

If no-one does, MESA will be used.

5

I was wondering when that kind of post would happen :stuck_out_tongue:

Well… there are OpenAL, OpenML and OpenThis, OpenThat

Well

Just my 2 thousand cents … waste

nevermind
duh

topic closed

.
EOF
^Z
0xFFFF
fileHandle.Close();
shutdown -h 0
Over and out.
Death

Man I think I got some serious problems

6

Hey Doca,

OpenGL support is improtant, but first having an actual working OS is more important. Anything that isn’t in R5 won’t specially be added - as it all takes time, and I want to boot Haiku R1 as soon as possible!

Simon

7
Doca wrote:
I just don't like MESA...

Could you expand on why?

AFAIK, there’s not that much OpenGL 2.0 open source implementation available outhere. MESA is one of them. The singlest one, IIRC.
I don’t see why not using it…, it’s our best option to get some 3D hardware support one day and, even if it’s far from being easy, it’ll be far easier than write a OpenGL 2.0 API compliant kit from scratch !!!

8

the only problem with Mesa, is that it’s an additional layer between you and the hardware. For ‘the BeOS’ that’s bad. But apart from that there is nothing else that makes it an unworthy choice for implementation in BeOS or haiku. What could be better? Xfree86 / DRI?

9

Opengl would make porting game easier.

Hey lets hack and steal directx code.

10
euan wrote:
the only problem with Mesa, is that it's an additional layer between you and the hardware.
Introducing an abstraction layer between hardware and the graphic API was the exact goal of OpenGL since day one, and the recipe for his success IMHO. Being an open source OpenGL implementation, Mesa follow this design, like every other implementations available. DirectX too is an "additional layer'" between Windows games and gamers hardware, an C++ one even, and nobody complains about speed issue due to the "layering".
euan wrote:
For 'the BeOS' that's bad. But apart from that there is nothing else that makes it an unworthy choice for implementation in BeOS or haiku. What could be better? Xfree86 / DRI?
It seems you make the exact same confusion that many people do with Mesa and Xfree86/DRI.

Lots if not all DRI drivers are staticly linked against Mesa core source code, wiring what can be done in hardware but still relying on Mesa “software” code to provide all the rest of OpenGL API.

For the best (in hardware support term) DRI drivers, it means that most of gl*() OpenGL calls go straight to the gfx hardware and Mesa core code only provides the gl*() calls dispatching mecanism. For all others, Mesa code is used for OpenGL APIs not supported by the considered hardware.

These days, XFree86/DRI and Mesa share a lot, and you see the same DRI contributors working on Mesa code…

11
nickjw wrote:
Hey lets hack and steal directx code.

yea, that’ll make porting games much easier =)

IMO at some point, we need Direct3D too… since it appears that many of the important game developers are ditching OpenGL and favoring it for some reason.

12
kurtis wrote:
nickjw wrote:
Hey lets hack and steal directx code.

yea, that’ll make porting games much easier =)

IMO at some point, we need Direct3D too… since it appears that many of the important game developers are ditching OpenGL and favoring it for some reason.

s/important/new

id are still on OpenGL, Sports Interactive have MOVED to OpenGL so they can do Mac ports, and so on

Its only new developers like Rockstart that are using D3D, and thats only on Windows - they use a cross platform programming model to target the PS/2 as well, so getting OpenGL support into the cross platform model would be better than supporting D3D…

13
phoudoin wrote:
snip...

what I was trying to say is that mesa would be an extra layer between the userland and the opengl driver. Basically I get the impression that it’s not as efficient or lean as I would like. As it comes from a software rendering background, that’s probably why I get that impression. I’d rather just see two layers. Userland, and hardware access. I can’t remember if Mesa works that way. I have looked at the DRI and mesa source, as well as a graphics vendors own implementation. The anonymous graphics vendor’s version is much leaner, and well, I guess tidy. :slight_smile:

14

If I have understand MESA and OpenGL (I hade the same idé about MESA being waste of resources).

OpenGL are not as free as you can imagine and usually to companies!?
MESA is free and are to some point OpenGL compatible.
MESA are not used with OpenGL but rather “instead” of OpenGL driver

15
ModeenF wrote:
If I have understand MESA and OpenGL (I hade the same idé about MESA being waste of resources).

OpenGL are not as free as you can imagine and usually to companies!?
MESA is free and are to some point OpenGL compatible.
MESA are not used with OpenGL but rather “instead” of OpenGL driver

Eh?? You understand wrong.

OpenGL is a standard. A Free standard. MESA is a very fast software OpenGL rendering implementation, that can be used with DRI for hardware rendering.

16
ModeenF wrote:
If I have understand MESA and OpenGL (I hade the same idé about MESA being waste of resources).

OpenGL are not as free as you can imagine and usually to companies!?
MESA is free and are to some point OpenGL compatible.
MESA are not used with OpenGL but rather “instead” of OpenGL driver

Eh?? You understand wrong.

OpenGL is a standard. A Free standard. MESA is a very fast software OpenGL rendering implementation, that can be used with DRI for hardware rendering.

17
ModeenF wrote:
If I have understand MESA and OpenGL (I hade the same idé about MESA being waste of resources).

OpenGL are not as free as you can imagine and usually to companies!?
MESA is free and are to some point OpenGL compatible.
MESA are not used with OpenGL but rather “instead” of OpenGL driver

Let me see if I understand it properly…

OpenGL is an API for software to render models/graphics (generally 3d)… the speed means nothing as far as the specification - no hardware is required at all to implement OpenGL, it’s just a specification, an interface you might say.

MESA is an OpenGL implementation that aims to be OpenGL 2.0 compliant (have all the appropriate APIs and have them actually do what they’re supposed to) - still no special hardware required to do this… in other words, MESA provides OpenGL 2.0 software-rendering without any special 3d video cards.

Next comes the hardware acceleration - in theory, any OpenGL API in MESA can be passed onto hardware to do the dirty work, as long as the hardware specifications are known… so, a driver writer, with proper knowledge and specifications can write a hardware acceleration layer that passes all the OpenGL API calls from Mesa to the video card with minimal performance loss.

If i’m not mistaken, this is exactly how it’s supposed to be done… OpenGL and DirectX (and the now-extinct Glide) are simply 3d-abstraction layers - there is no specific reason why one is better than another, other than developer preference.

I think that MESA would be an excellent starting point as it fills in all the gaps:

A driver writer can focus on hardware acceleration of the most important OpenGL APIs first, and let MESA’s software rendering take care of the others until there is time to implement them properly…

18
MYOB wrote:
ModeenF wrote:
If I have understand MESA and OpenGL (I hade the same idé about MESA being waste of resources).

OpenGL are not as free as you can imagine and usually to companies!?
MESA is free and are to some point OpenGL compatible.
MESA are not used with OpenGL but rather “instead” of OpenGL driver

Eh?? You understand wrong.

OpenGL is a standard. A Free standard. MESA is a very fast software OpenGL rendering implementation, that can be used with DRI for hardware rendering.

SGI wrote:
Application developers do not need to license the OpenGL API. Generally, hardware vendors that are creating binaries to ship with their hardware are the only developers that need to have a license
SGI wrote:
For hardware developers, SGI had various licenses in the past including level 1, 2, or 3 licenses, university licenses, and embedded-system licenses. The open sourcing of the S.I. simplified the licensing issue.

It look’s like it would be free for Haiku but not for Be?
But on another line its fre for all :slight_smile:

What talk against MESA is (to me) a native implementation are always faster (if it is dune right) then a port. But the again it’s probably the only way to have some kind of OpenGL. (OpenGL 1.5)

19

SGI’s OpenGL implementation is just one of many. Haiku is not using it. BeOS R5 DID use it. Haiku is using MESA, which is a full OpenGL 1.5/2.0 implementation, is FREE, is opensource and is much, much faster than SGI’s software one.

20

Like Urias, I don’t really know much about OpenGL or MESA but I would like to understand it all a bit better.

If I understand correctly, ‘OpenGL’ is just a definition that describes a set of functions, constants, etc. that developers must work to. It consists of no code or hardware whatsoever.

MESA is a software implementation of the OpenGL specification. So this bit provides the code that application developers can use to program in OpenGL.

The bit I’m not clear on is whether or not device drivers have to be written to conform to OpenGL as well? For example, I’ve installed the Radeon driver available from BeBits to get R5 to recognise my Radeon 7500 card - would this driver need to be re-written so it can be accessed by OpenGL? The nice ‘rotating teapot’ demo works fine on my BeOS computer, but presumably this is all being handled through software, rather than features available on the graphics card itself?

Chris