"Ask ATI" dev thread

[Heiko]

I would love to see virtualization of gpu's just like the cpu. If there was virtualization for the gpu I would also run windows in VMware. Although off course most virtualization applications don't use the gpu in any way.

[bridgman]

shishir, this thread is really for accumulating "high level" questions for a Q&A article, not support issues. Can you take this to another thread please ? This sounds like more of an install issue than an XGL issue, so maybe start with OS, previous driver history, how you installed, whether you uninstalled previous driver etc...

[brot]

Open Roadmap

Hello everyone.

I would like to ask if there is something like a place with some informations about the next releases, like when they are planned or what features they should have.

While you dont need to open the driver itself, seeing the progress will encourage some people to switch to amd/ati gfx cards. i, myself, switched from a nv 7600gt to a hd3850 mainly because of the improoving support of the cards and amd/ati's linux policy.

So,is something like that possible in the future ?

[d2kx]

That's what Phoronix does, telling you what's about to come

I don't think AMD will tell you these things, as they never were like talking about future improvements.

[bridgman]

As a rule we do not comment on unreleased products or features although we do try to give hints, and in special cases like support for 6xx AGP cards we did publish specific plans once they had become fairly solid.

We can tell you when the releases are coming, of course, but everyone knows that already

As d2kx said; hang around here and you'll get a pretty good idea of what is coming down the pipe.

[curaga]

Here's what Pickup asked in "is ATI really on par with Nvidia now":

How about the old cards? Most of the work in the new drivers is spent for the newer and the less-newer cards and chipsets, but while people is developing a driver for those cards a brand new one comes out. And someone have to write a driver. So, I sense developement resources move continously to the newer and slowly drops the older, leaving drivers for the legacy stuff half-developed.

The question is: will a GPU - any GPU - be "fully supported"?

I'd like to see the answer to that too. Frglx dropped R200 ages ago. People are saying once the new driver model is in place the old will be dropped. What if there's no-one to port S3/Sis/Matrox/etc over?

[Pickup]

Here's what Pickup asked in "is ATI really on par with Nvidia now":I'd like to see the answer to that too. Frglx dropped R200 ages ago. People are saying once the new driver model is in place the old will be dropped. What if there's no-one to port S3/Sis/Matrox/etc over?

Yes but my question was a bit different: IMHO the picture looks like this:
1) video card X is out (let's say, VideoFart VF1000 series).
2) Driver for the VF1000 series is developed, specs-available or reverse-engineered, after six months they manage to run 2D.
3) After an year the 2D accel is getting pretty good, someone starts figuring out how 3D works. In the meanwhile the VF1200 comes out, with new features the VF1000 driver can't handle. Xf86-video-VF1000 driver must be fixed up.
4) a bit of work in the 3d part is done, glxgears seems to work, veeeery slowly but works. But a new memory manager is getting into the picture. The driver must be rewritten for the new memory manager.
5) another year passed, the 3D part is stalled because they planned to work on the new Lithium technology, but this is just in pre-alpha stage, not ready for driver writing yet. The video playback runs almost fine, anyway. VideoFart in the meanwhile announces the new VF2000 for mid-summer.
6) VF2000 is out. The chipset is quite different from the VF1000 series, so the driver developer team splits in two: 1000 guys and 2000 guys.
7) It is advisable to get advantage from the newest MoleculeBios technology... more months in learning MoleculeBios.
8) the splitted team puts more efforts in making the VF2000 run accelerated 2D than in making VF1000 run accelerated 3D. And the Lithium code "begins getting stable"
9) After more then 3 years since the VF1000 came out, VideoFart deploys VF3000 series, and drops support for VF1000 in the (malformed) proprietary driver or moves it in a "legacy" driver which is updated every 2 or 3 new kernel versions.
10) The open team now is split in 3: the new, the older and the oldest. The newer the card is, the more the effort is spent. VF1000 is de facto dropped without a real 3d capable driver.
11) (another year passes) The VF3200+ introduces a completely different architecture, a brand new driver is needed: the GlFartHD, who will split even more the team. By the way, they discuss about dropping the little work spent on a nonfuctional-yet Lithium-based driver for the more efficient Sodium or to give a try in implementing the one developed by the PerFIDIA team, the faboulous [state your favourite chemical element-any but Palladium, PLEASE! ] which runs very fine with the new ProtonBIOS....

I think you get the idea.

Then the question is: will I ever say to a new Linux user, "here, THIS card IS supported"?

[bridgman]

Yeah, welcome to the world of being a hardware manufacturer

This is in part (a) why we developed AtomBIOS, (b) why we don't change the 3d engine architecure as often as the portions which are covered by AtomBIOS, and (c) why we are re-using existing open source Mesa and drm drivers rather than leaping immediately to Mesa-over-...um... Lithium.

My main question about your scenario is that you seem to be mixing open and closed source activities without distinguishing between them. We went through our equivalent of TTM/GEM/Gallium years ago in other OSes and are now able to leverage the same technology on Linux.

Most of the current architectural changes in the open source world are a non-issue for the proprietary driver. DRI2 will help us, and RandR1.3 will hopefully add GPU objects allowing us to make more use of RandR, but (as an example) we started moving to a Gallium-like driver architecture 4 years ago and our equivalent of the TTM/GEM debates happened almost 6 years ago. This was for that other OS but now applies to fglrx as well -- that's where the big OpenGL performance jump came from, as we went from "old style" 3d stack in Linux to the current one.

For open source drivers, one of the main goals of our open source initiative was to make sure that devs working on framework changes have the information, code and support they need to modify our drivers at the same time (the other was giving distros the info and support they needed to provide a good out-of-box experience for users).

If we take your list and change a few things to reflect what has happened so far(I'm assuming you meant open source because you are introducing open source arechitectural initiatives as time-sinks for development efforts):

1) video card X is out (let's say, VideoFart VF1000 series).
2) Driver for the VF1000 series is developed, specs-available or reverse-engineered, after six months they manage to run 2D.

Iif you look at radeon progress, after a couple of weeks modesetting and 2d were running and did not need much additional work - most of the subsequent effort was adding new capabilities to the common code for older chips (EXA Render and Textured Video). The radeon effort initially used PLL code and AtomBIOS parser from radeonhd work so need to figure more than 2 weeks but not 6 months; keys here were atombios and reuse of existing accel code.

3) After an year the 2D accel is getting pretty good, someone starts figuring out how 3D works. In the meanwhile the VF1200 comes out, with new features the VF1000 driver can't handle. Xf86-video-VF1000 driver must be fixed up.
4) a bit of work in the 3d part is done, glxgears seems to work, veeeery slowly but works. But a new memory manager is getting into the picture. The driver must be rewritten for the new memory manager.

Dave got glxgears running the same night we released the docs; re: memory management we try hard to *not* let GPU support be held up by new initiatives; so far it's working.

5) another year passed, the 3D part is stalled because they planned to work on the new Lithium technology, but this is just in pre-alpha stage, not ready for driver writing yet. The video playback runs almost fine, anyway. VideoFart in the meanwhile announces the new VF2000 for mid-summer.

Yep, we got a lot of flak for using "classic Mesa" not Lithium but this is why. There is some parallel effort on Lithium (thank you Glisse and hopefully MostAwesomeDude) and I'm hoping to put some in-house resources on Lithium soon but it's not on the critical path. Lithium is not relevent to fglrx - we already switched to our equivalents of Lithium and TTM/GEM.

6) VF2000 is out. The chipset is quite different from the VF1000 series, so the driver developer team splits in two: 1000 guys and 2000 guys.

VF1000 work is pretty much finished in the sense that it's approaching the limits of the framework; devs are chomping at the bit for 2000 docs and may work on Lithium out of boredom

7) It is advisable to get advantage from the newest MoleculeBios technology... more months in learning MoleculeBios.

It could happen but unlikely; now that we have drivers for modern GPUs we could overlap development of MoleculeBIOS with in-house adaption into OSS drivers; this is one of the reasons why we have in-house developers. For fglrx integration of MoleculeBIOS would definitely happen in parallel with development.

8) the splitted team puts more efforts in making the VF2000 run accelerated 2D than in making VF1000 run accelerated 3D. And the Lithium code "begins getting stable"

9) After more then 3 years since the VF1000 came out, VideoFart deploys VF3000 series, and drops support for VF1000 in the (malformed) proprietary driver or moves it in a "legacy" driver which is updated every 2 or 3 new kernel versions.

It's usually more like 4-5 years but yeah this will happen eventually; The 9700 is already 6 years old. In the case of Linux we would probably transition to open source rather than to a legacy fglrx branch.

10) The open team now is split in 3: the new, the older and the oldest. The newer the card is, the more the effort is spent. VF1000 is de facto dropped without a real 3d capable driver.

What makes this work is that there is a fair degree of architectural commonality between the generations; part of the problem is that older cards tend to get used in older systems so the testing effort goes up exponentially over time and we often can't cover everything; put differently over time the older GPUs stop being able to leverage the same testing done for new GPUs since they are being used in a different environment.

11) (another year passes) The VF3200+ introduces a completely different architecture, a brand new driver is needed: the GlFartHD, who will split even more the team. By the way, they discuss about dropping the little work spent on a nonfuctional-yet Lithium-based driver for the more efficient Sodium or to give a try in implementing the one developed by the PerFIDIA team, the faboulous [state your favourite chemical element-any but Palladium, PLEASE! ] which runs very fine with the new ProtonBIOS....

Yep, again this is why we made a deliberate decision to make sure every GPU has decent support on "already stable" frameworks before we shift efforts to new frameworks.

So... other than the fact you stacked both open and closed source obstacles in front of what I am guessing was supposed to be the closed source development team I think you have a pretty good understanding of what we are all dealing with. This is a bit easier for other OSes which have 5x to 50x the desktop market share but is definitely a challenge for Linux.

[zehnan]

Vertex Texture Fecth Support in GLSL

Hi there,


I have a RadeonHD 3850 agp running with fglrx 8.6 driver.

I've read that Vertex Texture Fetch (VTF) is supported on all r600+ hardware, I'm curious about the driver support though.

I have a vertex shader program using texture lookup that fails to produce any results. If I remove texture2d() lookup function, everything works okay (except the missing functionality of the VTF, of course ). The same program works fine on Nvidia hardware.

I thought it may be a driver issue at first, but then again querying GL_MAX_TEXTURE_VERTEX_IMAGE_UNITS returns 16. As far as I know this means the driver and the hardware should support it. Perhaps I'm using wrong texture format? I tried GL_LUMINANCE_FLOAT32_ATI, GL_LUMINANCE32F_ARB and GL_RGBA32F_ARB with no success.

On windows VTF is supposedly supported since Catalyst 8.5, what about Linux?

Any hints on the topic or ideas where to seek further information greatly appreciated. Thanks,

Marko

[eL_vErDe]

WoW minimap fix

Hello devs,

I'd really enjoy a fix for World of Warcraft's minimap turning white.
The latest driver that worked for me is 8.40 if I remember well.

Thank in advance,

Regards, Adam.