Hmm, thanks for the info.
Originally Posted by agd5f
I'll look into it.
Yep, from the log messages your driver is a couple of months old, which would normally be fine but it won't include the recent tear-free work.
Is that tearing the driver itself or bad vsync? Seen plenty of that kind of tearing in (unrelated) landscape-mode for Opera Mobile currently.
Originally Posted by bridgman
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.
Originally Posted by bridgman
At least there's some information for moving forward.
Last edited by NuShrike; 12-30-2008 at 08:53 PM.
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.
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...
Having todays HW tomorrow!
Originally Posted by octoberblu3
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.)
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; 12-31-2008 at 01:53 AM.
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
12-31-2008, 09:09 AM
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.
Originally Posted by RealNC
Of course the film processing apps they themselves develop and sell are all closed sources, but surprisingly most of them have linux versions