Qt status

On an entirely unrelated note, QScintilla2 as released has some optimisation taken out because it wasn't working with our port of Qt. When that is fixed, JuffEd should speed up.

@Chris
Quote:

What you mean ?

If you mean current one, then yes, sure, old cards will use warp3d as they use now, but they will not have any gallium related parts.

But if you mean, that Gallium will have support for old cards, and those old cards support will be done via gallium->warp3d , then that will be not done officially because of time wasting and limited resources. Not the latest moment that gallium stuff will works over new drivers, and only new radeonhd drivers have all necessary code to easy gallium integration (while old ones are not, and no one worring with old drivers in that terms).

Quote:

Anyway, small speedup fill not help much .. As if we want QT apps for everyday use, they should works lightly fast as native ones.

For users imho the only way its wait one more year (when aos4.2 with all the stuff will be released) and then QT apps can be usable as native ones (imho of course).

Or maybe alkfil can take warp3d sources from hyperion (what will be very hard for sure), and add frame-buffer-objects :)

@kas1e

Yeah, that'll be the day!

Quote:

Yes, that's what I mean. Gallium is just one "driver" for OpenGL, Warp3D will be another. OpenGL will work without Gallium. That's my understanding anyway, maybe I'm wrong.

@Chris

Not that I have any insider knowledge, but I would asume, that there is too much functionality missing in Warp3D that it can be used as a basis for a full mesa implementation. I might be wrong though .

@Chris
Quote:

If you mean that new coming opengl, in mesa implementation will works not only over gallium/new radeonhd drivers, but also over warp3d, then imho nope, because:

1. Even if someone will write a part of code for MESA to handle warp3d, we will have in end the same slownes (and even worse) as with minigl, and the same problems with unsupported shaders and so on. So there is no sense to even waste a time on it (as it done by old stormmesa and make no sense anymore).

2. Technically mesa already integrated with the gallium in the main repository, and cut-off gallium, writing new warp3d related parts again make no sense, because its all alread done via minigl+warp3d combo (or like kind of before with stormmesa+warp3d).

3. Time and priorities. Mesa/Gallium working over new radeonhd drivers make sense, but spend a lot of time on the rectreating the same as done via StormMesa for example, make no sense.

The only some more or less real stuff (if rogue or hanz will found a time for , what is unluckily due to priotites) its that they will write one more gallium3d driver, which will use old radeon card drivers (without warp3d, to avoid warp3d problems, and because when gallium done, warp3d no make sense by itself), and which will works partially in HW (what is possible to get from old cards) and partially in SW (as it now, for Transofmation, Clipping and Lighting).

But it will be for sure lowpriority, and for sure will be harder to make a gallium driver over the old-radeon-2d-driver, which not have any solution for such integration (and so, such old 2d drivers need to be rewriting, wich also will take a lot of time, and which will make and no sense, and no priotires).

All in which we can hope initially, its just for HW working gallium over new radeonHD drivers , which integration will be done fine enough to be faster than minigl+warp3d combo.

So, if back to topic and to summorize: if any of peg2 users want new gallium and fast working QT apps, they should change their pegs on sam460/x1000. That only one real solution for now imho.

So no hope to get Qt working decently on Pegasos2...

Hope that maybe someone will upgrade Warp3D/minigl in some way...oe someone will get a trick to get PCI HD cards tol work on Peg2... :P

I had assumed that our current MiniGL would be used by opengl.library when Gallium3D+Mesa could not be used. Might be wrong though.

@CrhisH
Even if there will be added fallback to minigl/warp3d when gallim/mesa can't works, its still not helps QT users without gallium , as it all will the same slow as it now.

@Kas1e

TinyGL vs MiniGL shows that TinyGL is not just a tiny bit faster but a lot faster, something is horrible wrong whit Warp3D/MiniGL implementation, a new 3D system will most likely not have the same problems, and there for there is possible it might be faster, even on Sam440 and AmigaOne computers, if AmigaOS4 developers take the time to port it from the old 3d system to the new, and optimize it.

Yes new graphic cards have new and better features, that old graphical do not, this way there will be fallback mode, for missing features, so the speed depending what is needed for QT, it might be that it will be a none issue or it might a big issue, we see when we get there.

@LiveForIt
Quote:

New implementation should be faster for sure, just because for first RareonHD drivers done from scratch, and for second Gallium3d/mesa done not by small amiga group, but by big group of unix developers in the whole world. At least it for sure will have HW accelerated TCL, better optimisation of critical parts and no more warp3d layer will involved to.

To be honest, i even today not so understand what the real problems with warp3d, and why minigl works slow over it. That "frame-buffer-object" stuff because of which QT works slow can't explain the other slowdowns in compare with tinigl. Maybe warp3d use some functions from p96 which works slow, or kind ..

As Hanz say, he make his radeonhd drivers with as much as possible less releies on the p96 and as much possible abstract and less hardcore, so its all should eliminate all possible problems which we have currently.


Quote:

Imho, we can't count on any kind of fallbacks for the first releases of gallium/mesa. Maybe it will come later, maybe not. Maybe fallback will works fine, maybe not. Maybe they will found a time to write a gallium driver for radeon9200/9250 , but pretty possible that nope (due to other hi-priorities).

In theory,of course will be cool to have gallium driver for old radeons as well, but that mean rewriting of the current 2d radeon driver, which, very possible, have all the problems because of which warp3d are slow (pretty possible as well) and need totall rewriting. That all time consuming, and maybe even 3d party developers should to worry about it after all.

@kas1e

AFAIK Gallium have drivers for Radeon9800 as described on my topic on AW:

http://www.amigaworld.net/modules/new ... opic_id=33018&forum=14&92

As the above topic have clarify Gallium on AmigaOS4 may or not may support it...
So me realy hope that at Gallium release(maybe at Xmass or a bit later just togheter A1X1000?) Radeon9800 will "automatically" be supported so we Pegasos2 users can buy a second hand 2x Radeon9800pro card to get maximum performances from our hw...and I think that also Radeon9800 with Gallium will be really faster than my 9000pro...

Actually I dunno who from developers team can answer to that question...

@Tuxedo

Quote:

The problem is will new radeonHD drivers support radeon9800 or not ? Imho nope. And because of this there is no luck:

Because gallium3d drivers works over 2d drivers. If 2d drivers not done (or done in wrong way) there is no luck to have automatic or easy-done gallium3d drivers.

In case with radeon9200/9250/9800 our 2d drivers are not ready for gallium integration, and because of this imho better to not have false hopes.

@kas1e

no real hopes or what...simply waiting...but wasnt a problem to get a bit of hope no?
However if someone forom devs will answer to that I think that was only a good thing...