@kas1e

As far as I remember I had the first workable pre-alpha version around end of September 2009, so after three monts I had hardware 3D rendering. This of course was just a proof-of-concent which allowed me to apply for the bounty. Then it took until January 2010 to release something to wider audience and until May 30th to finalize the bounty (yes, the bounty was "done"). Please keep in mind that between January and May I also implemented AGP subsystem in AROS as well as ported the 2D driver. So all in all it took me roughtly 11 months to get the work done.

About speed - right now on my GF6200 Quake3 does 30 FPS (1024x768x24). The nouveau is nowhere near to beating MorphOS radeon driver. On the other hand however, Mesa supports OpenGL 2.1 with GLSL, something that (AFAIK!) neither TinyGL nor MiniGL can do at the moment, meaning you can actually compile more recent games.

_________________
https://www.axrt.org

@deadwood
Quote:

GF6200 Quake3 does 30 FPS (1024x768x24)

Its SW mode you mean ? (because if its HW, then 30 fps for x86 with normal card its nothing and very slow of course)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@all

Complaining about the speed of Gallium is pointless, moreover if you're comparing it to the official Catalyst drivers from AMD. One thing is being the creator of the hardware, knowing how the metal works and write your own drivers, one completely different story is doing reverse engineering, and write a driver with a huge "try and check" effort. AMD released some interesting informations about its latest GPUs, but as far as I could see in the Linux world, it didn't help making much better open-source Radeon drivers. Like it or not, Gallium is the only serious 3D graphic subsystem available in the open source world, so any operating system vendor that wants to provide such a subsystem has only a few roads to choose between:

1. porting Gallium3D

2. Write its own

The first choice has its drawbacks: relies on hand-made drivers made by independent developers, who might take much time before a new card will be supported. Maybe it's not the best option for a mainstream OS producer (like Apple with MacOS X, for instance), but it's practically a forced direction for little ones, who can't deal with the needed economic effort for option #2. The best thing about option #1 is that once port has been done, it requires less effort to keep everything up-to-date.

The second choice is obviously the one that gives the best result. But you need money, LOTS of money, to convince AMD, Nvidia and Intel they should port their drivers to a particular architecture, moreover if doing this means rewriting the drivers from scratch.

Formerly the Amiga world choose a third path which is basically a compromise. They gave support for a limited range of graphic chips (and GPUs) with a tiny OpenGL subset, which is however nor perfect nor future-proof. Yes, today there are good Radeon drivers for the R200 series which can even beat far better cards using the Gallium3D driver, at least from the framerate point of view, and this is good. But 3D graphics is not all about the framerate, there are also important features that today's graphic cards can do, and R200 can't. Shader languages for instance. GPGPU even better. And to handle all this stuff you don't need only a better GPU than a R200, but also a better API to work with. That's why the Gallium3D effort is so important: it might not be fast, but it can open door to much more better games and applications. The may run slower than on Windows or MacOS X, but they will RUN. There's always time to fine-tune drivers, once they are written.

@paolone

We all know about pluses of new 3d layers, but performance for slow ppc machines its 50% of success. Thread mostly start in terms of aos4 drivers , so its very logical that we all (aos4 users) in hope that gallium3d drivers will fast enough.

If they will be slower than MiniGL current drivers, not sure that it will have much success on aos4 then. But well .. we will see in end.

We (on aos4) already have many games and apps, which as you say "RUNS", but some of them run very slow. And if they will runs even slower over Gallium, then .. then for users all that technical and perspective words will mean nothing.

But that all only speculation, we can see all the stuff later and compare. But all what i can say already: if on modern HW, with modern gfx card, in HW mode, gallium give 30 fps in quake3 , then .. then its very very bad. Because even on my peg2 with slow minigl/warp3d i have about 20.

Last edited by kas1e on 09-Jan-2011 at 10:29 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

As Paolo say the good news about Gallium is that once port has been done it requires less effort to our devs to maintain everything up-to-date, so for example evental future updates in term of performance can be availible on Amiga in a reasonable time, almost this is the hope!

We also hope about future Gallium updates and why not, also about our Amiga specific improvement, we'll see ... cross finger !

Quote:

But that all only speculation, we can see all the stuff later and compare. But all what i can say already: if on modern HW, with modern gfx card, in HW mode, gallium give 30 fps in quake3 , then .. then its very very bad. Because even on my peg2 with slow minigl/warp3d i have about 20.

Just 20 FPS and in which resolution ?

I have 14.6 FPS at 640*480 on my Flex 800 (crappy Radeon 9250 64 bit) while for example NubeCheCorre runs at 18 or so FPS on it's Sam440ep, so a Pegasos II at 1 Ghz must be somethings around 25/28 (with a decent GFX off course)

I mean always in 640*480, almost good as resolution for me

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@paolone

right argumentation but there's a thing that I cant catch...

Why AMD and nVidia will write own closed source video drivers for their video hw when a better driver support(i.e. releasing the drivers as open-source or similar) will permitt to create (really)easly good drivers with better performaces than the current and makes ppl using it happier to use and to BUY their video hw?

They was scared to spread some know how or similar?

I cant get that really...
Something like the closed source Flash player code(more players around more flash apps around...)...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Hans

Thank you!
Thats exaclty the answer I would get...
Better to dont buy anithing now and wait atm...so no risk to trash away money...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Quote:

Tuxedo wrote: @paolone right argumentation but there's a thing that I cant catch... Why AMD and nVidia will write own closed source video drivers for their video hw when a better driver support(i.e. releasing the drivers as open-source or similar) will permitt to create (really)easly good drivers with better performaces than the current and makes ppl using it happier to use and to BUY their video hw? They was scared to spread some know how or similar?

Basically, yes to the last question. NVidia refuse to give out hardware documentation to anyone (IIRC, the noveau driver is the result of reverse engineering), and ATI refused to give out documentation until they got bought out by AMD. Even now that they have released open documentation, some parts (the Digital Rights Management stuff) they cannot disclose.

Factor into this that, when AMD did release documentation, they already had their Catalyst driver system, which was much better than anything available from the open-source community. Continuing with developing their own - more advanced - solution makes sense, particularly if their Windows, Mac, and Linux drivers share a lot of code (which is very likely).

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@deadwood

So it takes one person 11 months to 'port' Gallium to system X, Y or Z. Then a small handful of developers working on it should take half this time. Assuming 3-4 developers work purely on Gallium for OS4, it will be done by the summer. Now what you waiting for!

_________________

@kas1e

Quote:

Its SW mode you mean ? (because if its HW, then 30 fps for x86 with normal card its nothing and very slow of course)

No, in hardware. Not however that this is nvidia driver. It speaks little how radeon driver would work. Even for nouveau there are actually 3 drivers (GF 5/6/7, GF 8/9/GTS250, GF 450) and each of them can have very good or very bad performance.

Generally what I heard was that Gallium 3D driver for R300 cards was more mature than nouveau drivers.

_________________
https://www.axrt.org

@djrikki

Yes, especially if the work full time. I worked "evenings time". Though I'm not sure you can scale the development to more than 2 people. Mesa and gallium are a straigh compile. Problems start when you need to connect gallium driver to hardware managing driver.

_________________
https://www.axrt.org

Quote:

kas1e wrote: @samo79 Yep, i think that Warp3D is the main reasson as well.

I'm really not sure.

Warp3D lacks modern features and can certainly be way faster. But with a pure Warp3D (non MiniGL) engine, I can draw 15.000+ textured/lighted/whatever polygons 1920*1200*32 at 40+ fps.

Of course my engine is not OpenGL compatible. But that was just to tell we can have excellent "fillrate". With MiniGL, a few thousand polygons is enough to slowdown the framerate, even with low resolutions.

Last edited by Crisot on 10-Jan-2011 at 10:36 AM.

_________________
AmigaOne XE --- 7455A@1400 --- Radeon 9000 Pro --- RAM 2GB --- SSD 40GB

@deadwood

Quote:

No, in hardware. Not however that this is nvidia driver. It speaks little how radeon driver would work. Even for nouveau there are actually 3 drivers (GF 5/6/7, GF 8/9/GTS250, GF 450) and each of them can have very good or very bad performance.

People complaining about poor performance of Quake III on a GeForce 6200 should remember that the GeForce 6200 is - no offence to anyone - one of the worst performing products from Nvidia, expecially in the low-end cut-down versions with 64-bit wide memory bus and shared memory with system RAM. We all agree 30 fps at 1024x768x32 are not good with a old game like Q3A, however I can tell that the same game, with a old and cheap GeForce 7800 card, is just good to play at any higher resolution.

AMD Releases Radeon HD 6000 Series Open-Source Support
http://www.phoronix.com/scan.php?page=news_item&px=ODk4OQ

Quote:

AMD's Alex Deucher has pushed out the patches to the Linux kernel DRM, Mesa, and xf86-video-ati DDX that enable the support complete with 2D and 3D (OpenGL) acceleration. The Mesa support is initially for the classic Mesa driver, but the Gallium3D support should arrive literally at anytime now.

_________________

Here is an interesteting benchmark comparing Nouveu with binary nVidia driver on Linux:

http://www.phoronix.com/scan.php?page=article&item=nvidia_nouveau_q111&num=3

The second graph shows performance of nouveau vs nvidia in OpenArena which I think is the closest comparison we can get with Quake 3. If you check nVidia binary driver for GF8400 GS you will see 89 FPS. So nVidia produced driver on a card that is several generations newer than ATI 9200 gives two times worse results than MorphOS driver Fab mentioned. "beeing newer" does not equal "beeing faster".

_________________
https://www.axrt.org

@Crisot

Quote:

Crisot wrote: Quote: kas1e wrote: @samo79 Yep, i think that Warp3D is the main reasson as well. I'm really not sure. Warp3D lacks modern features and can certainly be way faster. But with a pure Warp3D (non MiniGL) engine, I can draw 15.000+ textured/lighted/whatever polygons 1920*1200*32 at 40+ fps. Of course my engine is not OpenGL compatible. But that was just to tell we can have excellent "fillrate". With MiniGL, a few thousand polygons is enough to slowdown the framerate, even with low resolutions.

Perhaps you could take a look at the MiniGL source code then, and see if there is anything that could be optimised.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

The GF8400GS results are not surprising. It's a low end board. It is way faster than a Radeon 9200 as long as you use modern functions, Quake3/OpenArena doesn't.

OpenArena is also slower than Quake 3 even with the same engine: maps are bigger and more detailed (and most of the time: awful. But that's another point).

The really interresting part of this benchmark is the NVidia/Gallium comparison. On a low end board, Gallium is "just" 2 times slower. On a "high end" board (well, a 8800 GT is all but high end actually), Gallium is nearly 10 times slower. That's frightening...

Last edited by Crisot on 10-Jan-2011 at 08:50 PM.

_________________
AmigaOne XE --- 7455A@1400 --- Radeon 9000 Pro --- RAM 2GB --- SSD 40GB

Quote:

Hans wrote: @Crisot Perhaps you could take a look at the MiniGL source code then, and see if there is anything that could be optimised. Hans

That's would be a pleasure and an honor, but I'm really not sure to be good enough.

My cup of tea is low level optimisation, basically I'm an ASM coder with basic C/C++ knowledge. I can do all what I want with my code but I'm also very bad when it comes to work on a complex project not from me.

But if your offer is really serious, I'm ready to spent time on it, learn, and see if something can be done.

_________________
AmigaOne XE --- 7455A@1400 --- Radeon 9000 Pro --- RAM 2GB --- SSD 40GB

@Crisot

Quote:

Crisot wrote: Quote: Hans wrote: @Crisot Perhaps you could take a look at the MiniGL source code then, and see if there is anything that could be optimised. That's would be a pleasure and an honor, but I'm really not sure to be good enough.

There's no harm in trying. If you spot something that can be optimised, then great. Otherwise, the worst that could happen is that you have to enter "svn revert" to get back to the svn version of the code.

You can checkout the code as follows:
svn checkout http://www.hyperion-entertainment.biz/svn/MiniGL/trunk MiniGL

Just enter "make" in the MiniGL base directory to compile. You will need to have using "*" as a wild-card enabled in DOS prefs, but that's it. If you manage to make any improvements, there are plenty of people who will test it for you, and you can send patches to me to commit to the SVN.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

1) IMO the matrix.c code should be rewriten using assembler routines in the first place. (Hope I'm not wrong - can't find optimized/assembler sources if that's already done.) There's some work done in altivec_math.c, but it will (of course) not affect Sam440's. Efficient matrix code should speed up Sam440 machines the most.

2) I failed to find any documentation on the Sam440's auxiliary FPU instruction set. All the documents I read refers mainly to the IBM 440 FP2 (dual) implementation. The best I found was: link. It introduces the 440 FPU's instruction set, but can't tell how much it's compatible with the AMCC implementation....

_________________