Announcement
Collapse
No announcement yet.
AMD Releases Open-Source R600/700 3D Code
Collapse
X
-
Originally posted by bridgman View PostBased 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.
Originally posted by bridgman View PostNuShrike, 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.
At least there's some information for moving forward.Last edited by NuShrike; 30 December 2008, 08:53 PM.
Comment
-
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.
Comment
-
Guys, tearing is fixed on R500!!! Don't spread an old myth, now. (or at least it doesn't work for TechMage89)
You should always use the most up-to-date stuff, though
I'm just soooo happy about the tearing being gone, I placed it as my status in Facebook... I'll keep repeating it over and over... and over...
Comment
-
Originally posted by octoberblu3 View PostAbsolutely fantastic! Thank you everyone for working towards a better ATI/AMD tomorrow.
Well.. It would be really great if communications developed to the point of having programming specs earlier than cards...
(Yes if coding specs change last minute then drivers need minor change + rebuild.)
Comment
-
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.Last edited by bridgman; 31 December 2008, 01:53 AM.Test signature
Comment
-
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
Comment
-
Originally posted by RealNC View PostI 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?
Of course the film processing apps they themselves develop and sell are all closed sources, but surprisingly most of them have linux versions
Comment
Comment