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.
IIRC the thinking was "the code is in a CM system, so you can go back and create a branch from any point you want if needed", ie the branch doesn't have to be created today. All previous versions of the code are in the CM system and available by rolling back to an earlier commit.
Really, all I want is not to have what happened to Catalyst (to the R300 and earlier stuff) to happen to the old Mesa drivers. IDK, silly really.
Unless you are running a distro that doesn't support it or are running Solaris/BSD. I mean, why not just leave the code in a branch as unmaintained. I mean, it would just be nice to have if you are running said older hardware.
But they won't build and no one is updating them. Why keep it in the tree? They are readily accessible locally via git or old tarballs or on the web via cgit. Keeping them around, even if they are not being built just causes problems when things are changed or new features are added since you end up having to wade through extra confusing deprecated crap.
DVI was not work with fglrx, but radeon was with both VGA/DVI until 3D is on with DVI then monitor go to sleep - just like with current driver.
Fglrx on Windows and Catalyst on Windows both give blurred fonts on VGA, DVI on Windows is OKish - on Linux both are good (with bug on DVI).
Video playback is good with VideoOverlay on, direct3d on Windows, Overlay on UMS and KMS's only TexturedVideo explicitly needs compozite naci-vblank (dia-tear) which halfed vsynced 3d;(.
Need to change cables (etch/fglrx was not work when both are pluged in), i'll become blind with VGA on XP.
Hi, I have just tried a simple glxgears test with all the desktop environments I have. I have to say that the results are quite astonishing. It proves that the testing methodology of the article is flawed and the presented results are unfair to say the least. Now the comparison (rounded to tens):
The article is comparing Catalyst and R300g and at the same time it's comparing Unity and Gnome 2 (why?). We know from the article that Catalyst+Gnome2 is faster than R300g+Unity. We can say for sure that Catalyst is likely faster than R300g in most or all tests, but we already know that from previous benchmarks. We also know that Gnome 2 is faster than Unity. What the article doesn't show is how much exactly Catalyst is faster than R300g, because it doesn't compare the two in the same desktop environment.
Michael, next time you make an article, please do it at least right.