"Ask ATI" dev thread

[bridgman]

Still working through the last few IP issues, probably another 3-4 weeks if I had to guess. In the meantime we have an NDA repository set up so development is proceeding under NDA. The only bad news is that getting the R6xx 3d engine running is turning out to be just as big a pain in open source as it was in closed source. We're bringing in more of the people who were involved in the original R6xx bringup and I'm hoping that will help.

[lucky_]

Still working through the last few IP issues, probably another 3-4 weeks if I had to guess. In the meantime we have an NDA repository set up so development is proceeding under NDA. The only bad news is that getting the R6xx 3d engine running is turning out to be just as big a pain in open source as it was in closed source. We're bringing in more of the people who were involved in the original R6xx bringup and I'm hoping that will help.

Do you have any clue if its development was such a pain on other platforms (win and mac) ?
Could be interesting to know whether or not some difficulties are inherent to Xorg.

[bridgman]

As I understand it bringup on Windows was a bit less of a pain because we had some in-house GPU-specific debugging tools for Windows, but those tools are being ported across to Linux now and we have a beta copy to work with. Other than that, I don't think this is a platform-specific issue -- just that the 6xx virtualizes a lot of the hardware so debugging lockups is more difficult than it is on earlier ASICs. The good news is that there are relatively fewer cases where the chip can lock up.

The bigger problem is that when we have a significantly new ASIC we normally do the initial bringup while the chip is still on the emulator, so if we have a funny lockup we can run the same code in the HW emulator lab and see what is going on inside the chip. The emulator lab is now tied up working on chips for 2009 and 2010, so that's not such an easy option.

The 7xx should be the last generation where we do the open source bringup much later than the closed source bringup, so for future GPU generations we should have a much easier time both with bringup and with obtaining technical information.

[lucky_]

As I understand it bringup on Windows was a bit less of a pain because we had some in-house GPU-specific debugging tools for Windows, but those tools are being ported across to Linux now and we have a beta copy to work with. Other than that, I don't think this is a platform-specific issue -- just that the 6xx virtualizes a lot of the hardware so debugging lockups is more difficult than it is on earlier ASICs. The good news is that there are relatively fewer cases where the chip can lock up.

The bigger problem is that when we have a significantly new ASIC we normally do the initial bringup while the chip is still on the emulator, so if we have a funny lockup we can run the same code in the HW emulator lab and see what is going on inside the chip. The emulator lab is now tied up working on chips for 2009 and 2010, so that's not such an easy option.

The 7xx should be the last generation where we do the open source bringup much later than the closed source bringup, so for future GPU generations we should have a much easier time both with bringup and with obtaining technical information.

Glad to hear it, I've heard about the next gpus to be nicer with linux and was wondering which chip was concerned.
Because judging by the difficulties you (are still facing )faced to produce the r6xx 3D code, I was really wondering if that would really mean being nice hehe.
I wish I could help in anyway.

[gsmd]

Now that OpenGL is out, do you have any schedule on supporting it in fglrx?

[mitch074]

My question is more a 'support' one: are the devs aware of the "checkerboard of doom" rendering bug on HD38xx and HD48xx (where the image seems OK in the backbuffer, but rendered completely scrambled on-screen), and if yes, can you tell us what causes it and if a bugfix is coming - or if there's a workaround?

On a slightly different topic, and that may have been addressed already, I'm having trouble removing tearing from video playback. What solutions exist? Since using
mplayer -vo gl2
triggers the above bug, forcing OpenGL vsync with that renderer makes things less than optimal. I'm using Catalyst 8.7 (from AMD's website), but the bug was already present in 8.6 (much more grave, as it could lead to complete system freeze).

The 4850 card itself if far more powerful (and faster in 2D mode) than the old GF6600 it replaced, but this checkerboard bug is really souring the buy for me.

[mitch074]

Now that OpenGL is out, do you have any schedule on supporting it in fglrx?

I guess you're talking about OpenGL 3.0... I'm interested in knowing that too.

[Nighthog]

I wonder about the "washed out" colour problem when using Xv video output in conjunction to use off TexturedVideo.

Has this been looked into, as I don't find a solution or a bug report anywhere either?

Here is my thread http://www.phoronix.com/forums/showthread.php?t=12020
There is a link to a older thread in it where they take upp the same issue 2 months back and there was suggested to make a bug report but never was clear if one was made or anything as they seemed to go an just use X11 video output instead and thread died after that.

So was this ever looked into?

[Nexus6]

What's the future of FireGL mobility support in fglrx?

I've been struggling to get my ATi V5200 FireGL Mobility card running with fglrx and looking at the ATi driver site, this chipset isn't even listed.

Is this card now a dead end for the fglrx driver?

[Moustacha]

Is there going to be complete open-source support for older (specifically rv360) cards, that includes TV-Out? I've heard TV-out is a proprietary issue, but I haven't had that confirmed really.