google -> "mesa git arch" 5th link but anyway it can be google remembering stuff i looked for
Originally Posted by blackiwid
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
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.
Originally Posted by jrch2k8
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.
Last edited by bridgman; 08-14-2013 at 01:52 PM.
Does anyone still have the loud fan issue with the radeon drivers with dpm enabled on 3.11git ? I have this issue on an HD5700, and cant seem to solve this.
Additionally when switching OFF vblank, my screen goes dark!
Do you have 2 monitors attached?
Originally Posted by xtachx
If that's the case see: https://bugzilla.kernel.org/show_bug.cgi?id=60523
My current workaround: Deactivate one screen when I don't use it.
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.
Originally Posted by droste
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.
Originally Posted by droste
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?
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).
Originally Posted by droste
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!