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.
Based on the error message, I expect the radeon code in the latest package might not be new enough. Can you get a date or commit number from your log ? The tear-free code only went in a couple of weeks ago.
Is that tearing the driver itself or bad vsync? Seen plenty of that kind of tearing in (unrelated) landscape-mode for Opera Mobile currently.
NuShrike, as I mentioned before AMD have announced plans to sell the Imageon division. I have asked internally about the possibility of providing open source support for the handheld products, but I don't think that is likely to happen until new owners have a chance to participate in the decision.
Thanks for an answer, even if it seems to me there would be complications with the Imageon sharing some internal elements with older Radeons such as raster op codes.
At least there's some information for moving forward.
Tearing is caused by drawing to the same part of the screen that's being scanned out. Right now, there isn't a good way to get rid of it without a performance hit (the radeon anti-tearing code stalls drawing until the scanline has passed the part of the screen the program wants to draw to.) In the future, there's talk of making a double-buffered framebuffer and pageflipping between scanouts.
It's already happened. Alex has been sitting in on some of the next-generation GPU design meetings and we are already going through the internal docs for the next couple of generations. We still don't plan to write much more than sample code until after the product launches, but we should at least know how to make the chip run by launch time. For some products we will want to have completed drivers at launch, but those will be handled on a case-by-case basis.
Catching up quickly with 6 years of hardware development was really difficult. We're hoping that keeping up will be easier.
Yes, this is a good idea. When you think of the delay from Windows driver support to Linux (fglrx) for some series ATI did not look good at all - NV always provided beta drivers for new products. Longest delay maybe 1-2 weeks.
I think part of the problem is the fglrx release cycle. It works great for open projects because you can always get the latest features as soon as they're coded while at the same time providing a predictable release schedule for distros that include your program.
But for closed software like fglrx you really lose both of those benefits, since it often means long waits for the release of implemented features, plus, since you can't easily test pre-release code you can't even rely on features to be available or stable at release.
Making "test" builds easily available might fix a lot of that problem, but would probably also be a lot of extra work on such a frequent and rigid release schedule.
Just my thoughts.
/me off to pray to the video acceleration gods for documentation + fglrx support
I think it's more than that. We all tend to forget a bit what "open" means. It mainly means that those corporations have access to the source and that brings some benefits, like being able to adapt the code or pay someone to adapt it (or fix it) to their needs. The romantic part of "open" is nice to read about, but we mostly care about the practical benefits. It would be nice if I could fix or pay someone to fix fglrx for me, no?
For example movie studios like Dreamworks who build render farms and workstations with high performance needs have a bunch of in-house techs customising their linux workstations and servers for their specific benefits. Under a closed Unix model they had to rely on the OS provider for customisations which invariably means more cash.
Of course the film processing apps they themselves develop and sell are all closed sources, but surprisingly most of them have linux versions