If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

thx for that hint, is there no wiki site or any other site that links to this and describes it, how are you supposed to find it, search mesa*.tar.xz over google file search?

Sorry want to stop bitching ^^ but at least I get know a valid hint.

For all the others I alraedy said that mesas version scheme is not the primary problem here, and that I find that archlinux is the main problem for me here.

To give another 2 example that its not normal, fedora... they have rawhide but they branch from that a current +x version when x is out the final version not a rc or beta. Or take ubuntu they also only announce the branch of ubuntu next wenn ubuntu is out.

like I said distros are maybe something different.

But the main point I was saying is that calling it version X+1 when version X is not out (as final x.0 version) is very strange, I dont know any other projekt that does that. Like the kernel they call it NEXT not x+1 till x is out.

Firefox the same libreoffice the same...

is kde doing this? they have a very special version system so maybe they do that too? special in maybe extreme classic, so when its done its done instead of the now in bigger opensource projects main scheme release to a date and look whats done till then. thats a bit like mesa? not having fixed release dates. But I think they also dont do that? I am not using kde so I am not shure here? Or give me another 1 bigger projekt that does call its next branch official version xy. Or is it only a branch but no tag? A branch I would think is okish.

The main problem I have here is I think that they dont tagged any 9.2ish version. no 9.2 rc1 or at least beta 1 or something. make at least one rc1 if you really want to "freeze" it very long make if you want 1000 rc-s but dont release nothing.

google -> "mesa git arch" 5th link but anyway it can be google remembering stuff i looked for

about mesa releases cycle are actually pretty sane, about your confusion is that sometimes Distros want a very recent feature that is only in mesa git, so they checked a specific revision from git and test it as much as they can and package it to offer certain feature first, so you end up with a package mesa-9.2-as557fdsd where "9.2 is current master" and "as557fdsd" is partial git hash but of course mesa has not released 9.2 and they don't care since they can't control what distros maintainers fetch to their packages.

In the case of arch they simply stick to released mesa that should work for everyone and let the testing versions rest in pkgbuild, so they dont affect users that want stability over performance/features, at ost i think you should propose this links get included into the wiki to make life easier for early testers like you

google -> "mesa git arch" 5th link but anyway it can be google remembering stuff i looked for

....

if you wanna know the current official releases check mesa3d.org

I find it not very early... its more like different grades of stability different projects wait for before they release their stuff, you see that in arch linux had kernel 3.10 very early while fedora has mesa 9.2 for 2 months or so included. and the freeze time of the kernel is I think way shorter than that of mesa and it has probable more changelines per release.

So I think streamlining different projects that depend on each other would be a good idea, you need kernel 3.10 and mesa 9.2 for uvd with radeon so releasing it several months differently is not helpful.

like I said you can see that different then me but I think tagging it something like rc1 or beta1 would be helpful. I mean gnome does the same they try to release new versions of every projects that is a part of it, and the X stack should not have complete different releasedays/schemes.

its basicly the most difficult part of linux updates and the most important in the same time, replacing the driver-stack, so making it even more complicated dont help.

The linux kernel uses a short merge window per release cycle when all the new features go in, so arguably the freeze time for the kernel is most of the release cycle and hence longer than the freeze time for Mesa. Mesa uses a pipelined model instead of merge windows, so freeze time of one release happens in parallel with development for the next release.

Merge windows make sense for Linux because there are a large number of largely independent subsystems which come together from different development branches during the merge window. That's not the case to the same extent for Mesa, so a single development branch and pipelining is probably a better fit.

(for pattern folks, a single development branch and pipelining via a major release branch is effectively the same as having a single subsystem and a zero-length merge window, but of course you already knew that )

There is a lot to be said for having all the components of the graphics stack on aligned release cycles, and things do seem to be heading that way.

Yes exactly, I have 2 monitors. I do not want to deactivate any of them because i use them a lot (usually while coding, i have my references on one and code in another). The fan sounds like a jet engine.

Droste, can you also test the performance of flightgear and virtualbox with the new radeon drivers? I wanted to compare the performance with catalyst. I havent installed 3.11 kernel yet, I was using a liveUSB to test the new radeon drivers.

I took a look at the bugreport and I will add to it detailing what I see in my system (Radeon HD5700), and will have a look at the source code to try to figure out the bug.

I could. Is there a flightgear benchmark, timedemo or something like this? I'm also not sure what you want me to do with virtualbox. It worked for me for ages with windows xp/7 guests and is mainly a CPU intensive task isn't it?

I could. Is there a flightgear benchmark, timedemo or something like this? I'm also not sure what you want me to do with virtualbox. It worked for me for ages with windows xp/7 guests and is mainly a CPU intensive task isn't it?

In flightgear, there is an option to display the FPS. I usually do my benchmark with flightgear on full screen (so I know the resolution), and 1 test with rembrandt OFF and another with rembrandt ON. (the rest of the settings does not make a big difference, maybe 1 FPS at best).

In catalyst, with rembrandt OFF I get about 60 FPS, with it ON, I get around 23. However, with the recent versions of catalyst, its a bit hard to test, since the clouds are all black and the shader does not work properly. (it is a catalyst problem - it "broke" before, was fixed with 12.3beta3 and the bug "reappeared" with 12.6 . Really bad!!!) I am just interested with the screen resolution vs FPS. (both rembrandt on / off)

I sometimes use virtalbox to make 3D models (autodesk), and use it to play some directX games. I just want to know how well it runs on catalyst. Lastly, when I get home in about 2 days, I will try the 3.11git myself. Sounds like the open source driver made a lot of progress and I can finally ditch catalyst!