@Hans

Quote:

Usually, when I give any estimates, two things happen:

- I miss the deadline
- People start whining about "broken promises".

So I made it a rule not to give any dates anymore, unless I know we can keep them (like with the classic release).

Having said that, I am working on OpenGL support, but it will take quite a while until that comes anywhere near a releasable state.

@BillE

Quote:

The feature will be usable eventually when a new SDK comes out, but right now, there is nothing that keeps people from starting a project.

You are the author of Digital Universe?

@Helge

Quote:

What is it that would prevent any willing developer to use the current one? Why is the current SDK suddenly not good enough? What do people actually expect from the new one?

@Alkaron

I think I found the graphics corruption problem and I should now have working MediatorLT support. The kernel is currently being tested, and we'll make it available as soon as it is finished as a hotfix on the web page.

@Amigaz

That is, in fact, the reason why it slipped in testing. I was aware of the problem, but thought it was only triggered by a specific program.

@orgin

I personally think of OS4depot as a place where I can go and download programs for OS 4. Whether they are native or 68k doesn't really matter, as long as you know that things you download from OS4depot will simply work.

My personal ?0.02

@nubechecorre

I knew about that graphics corruption problem but I thought it only occurred when running a PCIScan or ShowConfig, so I didn't want to delay the release for that. Unfortunately, we didn't have many beta testers with Mediator 1200/Voodoo combination, so it went largely unnoticed. I'll try to find out what is wrong, and will try to get a fix out as soon as possible.

@nubechecorre

Did you check the "Default" checkmarks in the Screenmode prefs? The screenmode file is auto-generated, so you need to check the "Default" checkmarks in the screenmode prefs program if you change the resolution. Unfortunately, I only noticed that after the manual was in print.

The two "Default" checkmarks are next to the width and height fields, below the list of screenmodes.

Edit: Okay, saw you did already find out yourself

@Hans

Quote:

I found that these problems go away with using the pull mode of the GPU, but as I explained elsewhere I couldn't get that to work reliable. I ought to have another look, really.

@Richi

Are you sure you are not mixing things up?

Nouveau is a DRI driver for nVidia cards. Gallium3D is a replacement driver architecture that replaces DRI.

(edit) Ah now I get what you mean... Yes Nouveau is 2D too, but that 2D driver cannot be used; in fact, not even the 3D driver can be used by AmigaOS, lacking DRI and X.

@nubechecorre

Did you run ShowConfig or any such program? I heard that ShowConfig could cause corruption (still investigating why) but the normal operation should work.

I don't quite get what you mean with "wrongly displayed".

@Richi

It would require a 2D driver as well.

@MichaelMerkel

Quote:

I didn't say that. As a matter of fact, I have done some work already. It's just not going as fast as I hoped because of other tasks.

Quote:

We are not talking about "enhancements" but about total replacement. What use is it to build a concrete skyscraper on top of a wooden shack? OpenGL rather belongs at the foundation of a graphics system, not on top of it, so that the graphics system can make use of OpenGL, not the other way around.

@afxgroup

As I tried to point out, it's not about the hardware itself. I do have documentation on the R100 and R200 and could write a Mesa driver myself given enough time, including hardware T&L, but that is not the point.

@Hans

Yes Gallium3D looks quite good, but they are still quite a bit away from a working system AFAIK. It's something to keep a very close eye on, though.

@Hans

Quote:

Even the OSMesa uses the MESA->driver API. However, implementing a hardware driver means re-implementing a good part of the Mesa internals, since this overrides the default implementations of the MESA pipeline. For example, you can use the software T&L module (which is done in OSmesa) but you would need to re-implement it for your specific card when you want to make a driver that has hardware T&L support.

Just have a look at the sheer amount of code in the drivers subdirectory of the Mesa tree, and there you only see part of it, the rest is in DRM which is a Linux kernel module, both a generic one as well as a hardware-specific one.

Just for giggles I ran a "wc" on it, the common plus radeon part in the Mesa tree is about 30k lines of code. I think people tend to underestimate the complexity of this.

@Elwood

Quote:

Actually, I am about the only one that could do it, or someone/some group from the AmigaOS team. This is no task that could be performed by any outsider, it ties too deeply into the system itself.

@afxgroup

That doesn't work either. See my post. It's not only the drivers. For the same reason you cannot use ATI's Windows driver on Linux, and vice versa.

There seems to be a lot of misconception about what OpenGL is.

OpenGL is a specification, nothing more, nothing less. It's a description of a bunch of API calls and what they are supposed to do, much like e.g. the sockets API of the original BSD is. Like with the BSD network layer, a number of implementations may exist.

Mesa3D is one such implementation. As a matter of fact, it is more like a set of library routines that can be used to create an OpenGL implementation. One such implementation is OSMesa, included with the Mesa source code, which is an off-screen memory buffer implementation of OpenGL 2.1.

More importantly, there are external things beside OpenGL that need to fit in. The OpenGL specification does not say anything about a "struct Window", about a X11 "Window", or a Win32 Window. There is always a "native binding" part, a part that glues the OpenGL API calls to render to a "struct Window" or "struct BitMap".

Finally, the most important thing, there is a hardware dependent part that instructs the graphics hardware to render USING the graphics hardware. This part is called a "driver". In the past, attempts were made to use Warp3D as a driver, and in fact, StormMESA did do that (more or less) successful. However, for several reasons, this is not feasible anymore, one of them being that Warp3D does not support hardware T&L.

Writing a hardware driver for Mesa does require both intimate knowledge of Mesa's internals, as well as intimate knowledge of the hardware, AND intimate knowledge of the underlying operating system. For that reason, you cannot just simply compile Mesa on AmigaOS 4.0 and get a working 3D hardware acceleration.

Now, we do face a number of issues with this. Even if we assume someone had the time, knowledge, and means to implement this, we have some architectural problems. For one thing, there is a second entity (Picasso96) fighting for the control of the graphics hardware. Warp3D has to take a lot of tight corners to work at all, and it doesn't work as well as it could.

What people do not seem to understand is that having a MiniGL itself is not the biggest issue, especially with the latest additions of Display Lists. In most cases, a program (especially games) do not use all of OpenGL (who has ever used the imaging subset, I wonder). A game like Quake 3 uses only what is in MiniGL anyway. The problem with the current MiniGL is that is does not use hardware accelerated T&L. If it had that, and a few added features (like selection) then the whole discussion wouldn't be so much in focus anymore. An additional problem is the speed at which the hardware evolves and keeping track of that, and keeping step with the latest developments like OpenGL 2.0 and the GLSL. Mesa does that to a certain degree, but even they have some trouble (lack of documentation from graphics cards manufacturers for example).

What needs to be done is a few fundamental changes in the graphics subsystem to allow an OpenGL port (and that means ANY OpenGL, not just Mesa but even a custom, vendor-specific implementation) to integrate with the graphics system in a consistent, supported, system-friendly and FAST way. Right now, this is not possible. It will require work, work that needs to be performed by the AmigaOS team (and WILL be), and cannot be performed by third parties because anything that third parties will come up with will only be a hack, as Warp3D is now.

@Elwood

Quote:

Time and money. If I had both, I'd have an OpenGL running already. Problem is I get sidetracked a lot, so I cannot work on it a lot..

@nubechecorre

Quote:

I suppose you will notice the difference, but I don't have any benchmarks that would illustrate it. I don't think that it will make a major difference, really.