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.
Announcement
Collapse
No announcement yet.
"Ask ATI" dev thread
Collapse
X
-
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...Test signature
Comment
-
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 ?
Comment
-
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.Test signature
Comment
-
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"?
Comment
-
Originally posted by curaga View PostHere'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?
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"?
Comment
-
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.
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....
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.Last edited by bridgman; 10 July 2008, 10:31 AM.Test signature
Comment
-
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
Comment
Comment