Are the benchmarks valid? Because, if so, I thought that Gallium was somewhat.. better, performance wise.
Dunno how valid those benchmarks, but i think they valid. As i say we not need here to think about exact FPS on those benchmarks, we can only see here, that Galium in latest benchmarks start to be faster than plain mesa. FPS itself here make no big sense.
@MrodFr Imho you need try to write questions more detailed, and without that strange ??? after every word. Its like saying : Opengl ?? Galium ?? TCP/IP ?? Information !!! I.e. many words without logical connection beetwen. And rogue's "One word - Eh ?" mean "I understand nothing from what you saying (and not because he not know about mesa/galium, but because almost no-one imho understand what you trying to ask).
Would be nice to have the exact benchmark conditions, because from what i can see with the OpenArena test, I get better results on a stone-old r200 on a stone-old pegasos2 with tinygl/morphos, which is somewhat unexpected, compared to the tested setups (R300/CoreDuo). The R5xx/CoreI3 performance also looks really quite poor.
For the first benchmarks which was done in June was used:
Quote:
For our testing, we used the Linux 2.6.35-rc1 kernel to take advantage of the latest Radeon DRM code and then checked out the Mesa Git code on 2010-06-03, which is Mesa 7.9-devel with Gallium v0.4. The rest of the software stack was an Ubuntu 10.04 installation with X.Org Server 1.7.6, GNOME 2.30.0 with Compiz, and xf86-video-ati 6.13.0. To show a look at where things are in comparison to what is shipping with Ubuntu 10.04 LTS, we also re-tested the stock Ubuntu installation with its Mesa 7.7.1 stack and the Linux 2.6.32 Ubuntu kernel with its back-ported 2.6.33 DRM.
Our test system was an Intel Core i3 530 CPU clocked at 3.32GHz, an ECS H55H-M motherboard, 2GB of DDR3 memory, a 64GB OCZ Vertex SSD, and an ATI Radeon X1950PRO (RV570) graphics card.
For the latest one (28 october) was used:
Quote:
For these new tests, a Lenovo ThinkPad T60 notebook was used with an ATI Radeon Mobility X1400 128MB (RV515) graphics processor. Other hardware specifications on the ThinkPad included an Intel Core Duo T2400, 1GB of system memory, and an 80GB Hitachi HTS541080G9SA00 HDD. Besides running the latest Mesa and Linux kernel development versions, the rest of this OS installation was Ubuntu 10.10 with GNOME 2.32.0, X.Org Server 1.9.0, xf86-video-ati 6.13.1, GCC 4.4.5, and the EXT4 file-system. Compiz was left enabled during testing.
But imho will be better if someone with linux box can try the very latest ones , just to give more detailed info.
Btw, i think that those FPS can be slow here, because they used for tests some open source ATI 2d-drivers, but not Catalist or how it called
Yeap, almost my thoughts too. I find the benchmark's result extremely poor given the setups. And as kas1e said, someone, should take the same test and post the results of a linux box, along with specs, for some of the games already mentioned. I find it hard to believe that my old Athlon@1Ghz oc at 1.13Ghz, Asus mobo, 512MB 133Mhz Ram, GF3 Ti200 128MB oc as Ti500, IDE HD Hitachi 320GB, WinXp Prof SP3 is faster or almost equal to a modern Intel Core i3 530 CPU @ 3.32GHz, ECS H55H-M mobo, 2GB DDR3, 64GB OCZ Vertex SSD, with an ATI Radeon X1950PRO (RV570) running latest Ubuntu (perhaps Compiz enabled does effect the outcome? I dunno). Hell, even the ThinkPad T60 notebook should crush my old setup.
After the port to AROS, AOS4 will use all of them ??
Translation:
Want to know if AOS4 will use:
1- MESA and GALLIUM from AROS. or 2- OPENGL (new port) and GALLIUM from AROS.
I want to know the origin because if all ports for AOS4 are new that mean some time to be made and if based on AROS, less time to be made, thats all...
As hans answered recently MESA and GALLIUM, for me the port for AOS4 is 99% based from the AROS port (of course IMHO)....
but Kas1e allready explained on his post #29 that not will be so easy because AOS4 have some differencies he has well explained...
@kas1e
OpenGL (???): just mean unknown origin and one, two or tree ??? is allways the same question
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
I mean that Galium on aos4, will use Radeons drivers (which done special for aos4), while AROS version of Galium use noveau/nvidia open-source drivers, what mean that "plain re-port from aros to aos4" will make no sense. I also think, that aos4 version of galium should be even better, just because we have aos4-native drivers for radeons, while aros use that 3d party drivers ported to aros (noveau).
I don't see the connection. There is nothing preventing AROS from using the Radeon drivers, and nothing preventing AmigaOS 4.x using the nVidia drivers.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
I don't see the connection. There is nothing preventing AROS from using the Radeon drivers, and nothing preventing AmigaOS 4.x using the nVidia drivers.
I am about 2d drivers. Of course everything possible, but for now, AROS have only nvidia drivers (i am about 2d), and aos4, have 2d radeon drivers (as i know aros do not have 2d radeon drivers). So Galium for aros for now works only in softpipe + nvidia, but for aos4 it will works in softpipe + radeon.
Of course it possible to write 2d drivers for nvidia for aos4, and write 2d radeon drivers for aros, but i am about current state. And while AROS 2d drivers are "port", aos4 2d drivers are not. That is plus for aos4 realisation.
And main idea why i say that before: it always better to have native done 2d drivers, which will works with 3d layer later, if compare with ported 2d drivers (which can have slowdowns, not implemented features , not woring about aos-related specific stuff and so on).
For example few days ago i see that deadwood add to Noveau drivers on AROS screen scrooling (not dragging). What again mean, that writing drivers from scratch to amigalike os are better (because of all that specific stuff), and in end (in theory), native 2d driver for AOS4, should give better perfomance when galium 3d radeon drivers will works over that 2d drivers.
@Mrodfr The only problem for now, its the final result and perfomance which we will get. Just a port of galium and mesa from *unix wolds can be not enough (just as i see on aros-exec, deadwood all the time update something in the 2d/3d drivers and it works faster and faster with every release).
The good think with Galium/Mesa is that aos4 developers need one time spend energy to understand how better port all of this, and later, they will just update Mesa and Galium code from the main repositoryes (on which works many developers). In end , we will have modern, feature-compeleted realisation of 3d API, which will mean not only latest OpenGL, but also latest DirectX (10/11), what mean, that we will have not only all that games which have Linux world, but also all the stuff from Win32. What in end, can give us everything we need in terms of games and many new apps. We will not think anymore "did that fucntions are supported in minigl ? did minigl works somehow different ? did minigl buggy, or my code buggy ?" , because everything will be the same. And even ports will be more stable and better.
All that stuff about gallium/mesa its 100% right steps from aos4 developers, and even if the first realisations can be buggy/not-good-by-perfomance, i am pretty sure that its have a real future. Today many linux distros start to include Galium , and as i see by logs/tests/benchmarks , gallium start to be better and better (and good thinks here, that aos4 developers not need spend their energy on 3d stack anymore, its will done by the whole world for now).
After the port to AROS, AOS4 will use all of them ??
Translation:
Want to know if AOS4 will use:
1- MESA and GALLIUM from AROS. or 2- OPENGL (new port) and GALLIUM from AROS.
OpenGL is a standard, and MESA is an implementation of that standard. This is why what you're asking doesn't make any sense.
Like Rogue said, MESA and Gallium are not from AROS. We are not porting the AROS version; we're porting MESA + Gallium. While a few fragments of the AROS port's code might come in handy, AROS and AmigaOS 4's graphics systems are quite different at the driver level, so most won't be.
We really don't need to tell Rogue and Hans how to do their jobs so lets leave the AROS stuff to aros-exec.org from now on. Thanks.
Did you read whole topic before posting ? The whole topic its topic of interest and discussion about how, what and for what. And if aros code even can help (As Hans say), i think it will be pretty strange to not say about AROS at all, you don't think so ? I hope you doesn't mind that we discuss benchmarks of galium/mesa on PC ?
The whole topic its topic of interest and discussion about how, what and for what.
That isn't an English sentence I can understand. But the topic is the news about "Gallium being ported to OS4". No suggestion there that we should lecture Rogue/etc on how to do their job! But maybe nice to speculate about what it will mean for OS4 in the future...
And if aros code even can help (As Hans say), i think it will be pretty strange to not say about AROS at all, you don't think so ?
Gallium is a Linux driver project, so you could argue this is about Linux.
Mesa has been ported to Windows, so you could argue this is about Windows.
Gallium has been ported to AROS. So you could argue this is about AROS, as much as it is about Windows or Linux.
Yes, a look at the AROS code might be interesting, but the chance is that it isn't because the driver side of things is very different. Also, our memory architecture is quite different as far as I understand; that makes it next to impossible to use code from an AROS version. We're not going to port the AROS code. We're going for a clean-room port of the Linux code.
So, to reiterate, we are not going to port Gallium from AROS. We are not going to port Mesa from AROS. It would be completely pointless anyway, since Mesa is independent from the OS as far as possible, minus the glue required for context creation etc.
We are also not doing this because AROS did it. We're doing it because it makes sense. As I pointed out elsewhere, we're not developing based on envy or because of competition; we're developing based on what we think makes sense and what our users might need. As such, the decision to go for Gallium3D is not based on the fact that it was ported to AROS, as a matter of fact, the idea is quite old already, and we even had contact with the Gallium team a couple of years ago, but at that time the only supported platforms were software and the Intel I915 chips.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
But maybe nice to speculate about what it will mean for OS4 in the future...
From what I gathered, Gallium3D covers the 3D part quite nicely; it has an abstract internal API and translates external API's into a collection of states and resources, which is why they call for example EGL a state tracker.
With that in mind, OpenGL is just one way to access gallium. The next logical step would be to remove the custom Compositing code and move the compositing to Gallium as well, i.e. have graphics.library be a state tracker/client for Gallium3D as a backend for compositing. In theory, this can continue for drawing operations as well.
It will also make the Cairo hardware backend as we have it now more or less redundant. While that is based on the CompositeTagList call in graphics, it could be moved to glitz, and we could eliminate further maintenance requirements.
Our ultimate goal is to replace the current graphics system entirely. As I pointed out on Amiwest, some of the mechanisms we are using are anachronistic.
Let me pick an example here - screenmode id's. While it was a good idea in the days of Amiga custom chips (being able to identify the output device along with very specific parameters of the display) this kind of idealization is no longer required, and might even be counter-productive. To illustrate that, picture a video playback at 30 FPS running on a 70 Hz display. Since the output device's frequency is not a multiple of the playback speed, tearing and/or flickering is mostly unavoidable. If you could configure the display to use 60 Hz, or 90 Hz, you could very well fit the frame flicks into the VBI, making for a much more stable display.
Obviously, on a TFT this issue isn't as obvious as on a CRT, but it's just one of the examples were a freely configurable display (from an application's point of view) makes more sense than a fixed set of resolution/color depth/frequency settings.
Another example is true multi-display support, with the usual stuff like extending a screen to two or more displays, dragging windows across, etc. While this could be retrofitted to the current system, it would be an ugly thing.
All these changes will take time though, and for the moment, we'll be concentrating on the issues at hand.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Can we stop quoting benchmarks until the thing actually works ? For all you (and me) know, it might be drm that's slowing it down, or kernel switches, or bad weather.
Geez, sometimes, I really don't get it. Sorry.
Edit: Should learn how to spell correctly one of these days :|
I want to know the origin because if all ports for AOS4 are new that mean some time to be made and if based on AROS, less time to be made, thats all...
I finally got what you mean. No, the ports will be new and not based on AROS code, and yeah, it will mean it will take a while, but as has been pointed out, the code base from AROS would not work anyway.
Quote:
As hans answered recently MESA and GALLIUM, for me the port for AOS4 is 99% based from the AROS port (of course IMHO)....
This doesn't have anything to do with IMHO. Your statement is, or rather is going to be, wrong.
Quote:
OpenGL (???): just mean unknown origin and one, two or tree ??? is allways the same question
As Hans said, OpenGL is an API specification, while Mesa is an implementation. OpenGL alone isn't the answer either, you have to have glue code as well. For X, this is glX, for Windows WGL; EGL and GLUT try to be mostly OS independent. AGL is used by Apple. They're all rather small API's and their only purpose is to create OpenGL contexts and associate them with something that can be displayed.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Another example is true multi-display support, with the usual stuff like extending a screen to two or more displays, dragging windows across, etc. While this could be retrofitted to the current system, it would be an ugly thing.
Actually, what I'd love to see is the possibility to drag windows from one screen to another (on a single display).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
