Driver Status of Evergreen GPU

[blabub]

Good afternoon



I searched around the forum and the Internet and can not find any news about the gpu support for evergreen.

What I found was only that they want implement it with Gallium3D?


Are there any other information when OpenGL will work? (Basic is enough, performance is at the moment not needed)


I have to buy new computers for OpenGL development and it would be very nice to have a open source driver instead of a closed source blob.


Our project will start in June/July and until then we need the hardware. I want to buy the ATI 5xxx Series cause of the tessellation feature for OpenGL 4 and DirectX 11. Our goal is to release cross-platform based, but with the driver problems at the moment, we can not test our program with Linux and so we can not release it for Linux.


There is fglrx, but the driver is not usable and my developers kill me when they have to use fglrx. (The engine we use is not working well with fglrx and ATI seems to not fix this)

On the other hand, nvidia has no usable product.


Our budge are not to big and we need to go straight forward and can not wait years before we can use a driver. (That should be no flame, I'm so thankfully that there is a open source driver in development.)


Thanks
blabub

[rohcQaH]

The engine we use is not working well with fglrx and ATI seems to not fix this

have you written a test-case and submitted a bugreport to ATI?
(submitting a bug report is not guaranteed to help, but not submitting one is guaranteed to not help )

If it doesn't work in fglrx, it doesn't sound like you're only using "basic" openGL features. What makes you think it'll work with the OS drivers?


From what I hear, evergreen support is a priority for AMD, because it's a requirement for their fusion drivers, which they want to have ready by launch.
Work on evergreen has only recently started though, and estimates are always difficult - a few numbers have appeared here and there, but they're vastly different. Averaging those numbers, there seems to be a good chance for working acceleration in june/july, but I really doubt you'll see mainline drivers integrated into any distro yet. Go for those git repositories and have fun; preliminary bugs and unfinished features included.
I love OS drivers and all, but I'll personally stick with fglrx a while longer


Evergreen support will start on classic mesa, see here and the accompanying forum discussion.

[whizse]

Between Nvidia having no products to your liking, and your developers refusing to run fglrx, I'm kinda curious what it is you're targeting?

Even when Evergreen support starts to come along, it will most likely be GL 2.1 for quite a while, so if you're using GL4/tesselation features you're probably stuck with fglrx for now.

[blabub]

Thanks for the fast answer!

have you written a test-case and submitted a bugreport to ATI?
(submitting a bug report is not guaranteed to help, but not submitting one is guaranteed to not help )

The engine vendor is with ATI in contact to get rid of the bugs.
But it looks like this will take a lot of time until it's working.

If it doesn't work in fglrx, it doesn't sound like you're only using "basic" openGL features. What makes you think it'll work with the OS drivers?

What we need is a general OpenGL support, when OpenGL 4 stuff is not working its not a big problem. But we need to test to core program and for that we need OpenGL (else the engine won't load).
It's too no problem when tessellation is not working, the feature can be later enabled.

From what I hear, evergreen support is a priority for AMD, because it's a requirement for their fusion drivers, which they want to have ready by launch.
Work on evergreen has only recently started though, and estimates are always difficult - a few numbers have appeared here and there, but they're vastly different. Averaging those numbers, there seems to be a good chance for working acceleration in june/july, but I really doubt you'll see mainline drivers integrated into any distro yet. Go for those git repositories and have fun; preliminary bugs and unfinished features included.
I love OS drivers and all, but I'll personally stick with fglrx a while longer

In relation, we will release in 2011/2012, it's quit a long time till then. But our main focus is to be from scratch platform independent, cause of this we need to test as early as possible. Too we're developing with SCRUM and with no test cases there is no development.

Between Nvidia having no products to your liking, and your developers refusing to run fglrx, I'm kinda curious what it is you're targeting?

The problem with NVIDIA is: 1. The new GPU generation is a paper launch, 2. It seems not much user buy this GPU, the price is to high at this time 3. Why testing a GPU where maybe 5% are using?
And yes we plan to buy nvidia GPUs too, but for first development ATI is enough and some 9800er from NVIDIA already ordered.

The problem was, we had a concept and tech. demo phase and run into much pain with fglrx. Tell a developer he should develop with netbeans and fglrx, the scrolling is pain in the ass.

Even when Evergreen support starts to come along, it will most likely be GL 2.1 for quite a while, so if you're using GL4/tesselation features you're probably stuck with fglrx for now.

We release in two years, so this is not a problem. OpenGL 2.1 is well enough at the beginning, the engine scales very well between the OpenGL versions.

[bridgman]

Initial support for Evergreen will use the classic Mesa driver, ie we won't be waiting for a Gallium3D code base that supports 6xx and higher. The open issue is how quickly we jump across to a Gallium3D code base, and current thinking is that may happen fairly quickly depending on how Jerome's work progresses.

Are the fglrx issues you see visible with the GL 2.1 API, or only with the more recent feature additions ?

[jrch2k8]

well, i have my own software development company, i dont program in opengl though, but my devs (that do the gl work) force me to rma my entire brand new firegl cards or they quit (i think that should say it all ;( ). aka fglrx with any newish distro well forget about it, you need a really old distro to get some stability but your program will need a serious debug and hacks to avoid the countless issues you will face, that go from X hangs to massive image corruption (depend the driver version) passing all the way to the weirdest sisgsegv you've seen in your life (i heard that some got fixed in latest driver not sure) plus fight your way through hack the kernel grub lines to remove another whole set of annoying issues. in the end in my case i have to remove AMD gfx hardware support entirely from my product and force my clients to get nvidia hardware and ofc get nvidia hardware myself. so for commertial gl development dont go with amd, now if you need only a render program like maya it should be fine, they already took the time to make it work decently enough on fglrx, i mean you still get some really weird stuff in maya but is not often

now you can always buy an 4800 close to the end of the year and having it for testing the OSS driver or like i did buy a radeon for your personal pc, so you can do the testing when the oss driver get support enough on the gl side or fglrx works decently, whatever happens first.

another advise could be, to avoid compatibility pains try not to use nvidia specific extension or comment your code well enough to remember you need to add the fglrx equivalent.

i dont wanna create a fuss or something here, i know fglrx have gotten better than before, but i can handle issues after issue in my personal pc but in a enterprise focused product you cant, even if nvidia have their fair set of issues too, those are nowhere near those in fglrx. so this become a choice of the less bad driver implementation of both. and in this sector nvidia have more support, stability and compatibility than fglrx beside a way bigger market and apps around that greatly reduce the impact of find a weirdo gl unusable specific implementation, etc.

now on the nvidia side any mid quadro or even a gtx260 should do fine, for budget development.

[rohcQaH]

Tell a developer he should develop with netbeans and fglrx, the scrolling is pain in the ass.

work is being done on 2d accel in fglrx, that particular problem should hopefully be gone soon.

[blabub]

Initial support for Evergreen will use the classic Mesa driver, ie we won't be waiting for a Gallium3D code base that supports 6xx and higher. The open issue is how quickly we jump across to a Gallium3D code base, and current thinking is that may happen fairly quickly depending on how Jerome's work progresses.

Are the fglrx issues you see visible with the GL 2.1 API, or only with the more recent feature additions ?

Ok, that sounds like good news.


How much I know there will be a crash after loading a texture that have the tessellation configured (We can not remove this, until we want to have two project trees).
Too there are some graphic glitches, but thats not a big problem at all.
Suddenly it's too not running very stable for a long time.

well, i have my own software development company, i dont program in opengl though, but my devs (that do the gl work) force me to rma my entire brand new firegl cards or they quit (i think that should say it all ;( ). aka fglrx with any newish distro well forget about it, you need a really old distro to get some stability but your program will need a serious debug and hacks to avoid the countless issues you will face, that go from X hangs to massive image corruption (depend the driver version) passing all the way to the weirdest sisgsegv you've seen in your life (i heard that some got fixed in latest driver not sure) plus fight your way through hack the kernel grub lines to remove another whole set of annoying issues. in the end in my case i have to remove AMD gfx hardware support entirely from my product and force my clients to get nvidia hardware and ofc get nvidia hardware myself. so for commertial gl development dont go with amd, now if you need only a render program like maya it should be fine, they already took the time to make it work decently enough on fglrx, i mean you still get some really weird stuff in maya but is not often

That sounds annoying. I think we run into the same problem, we really have not the time to program hacks and workarounds for driver bugs.
And too we can only hope that the engine vendor is taking up this mess, while we have no source code.

now you can always buy an 4800 close to the end of the year and having it for testing the OSS driver or like i did buy a radeon for your personal pc, so you can do the testing when the oss driver get support enough on the gl side or fglrx works decently, whatever happens first.

I bought already a 4xxx und 5xxx card for the testing. But the our development style does not support testing after a while. Each case should be closed and running on both system.

another advise could be, to avoid compatibility pains try not to use nvidia specific extension or comment your code well enough to remember you need to add the fglrx equivalent.

This is on the engine side, they do with this a good job.

work is being done on 2d accel in fglrx, that particular problem should hopefully be gone soon.

Thanks for the information!

[pingufunkybeat]

I'm not a developer, and the actual developers will not give you any solid dates anyway because they will release them when they're ready.

But if I had to guess, I'd guess that OpenGL support for Evergreen should be around in the second half of the year. Probably OpenGL 2.1, to match the other chipsets. No idea if it will be ready in July, but it should be ready by December, they don't seem to be that far behind.

As for OpenGL 4, tesselation, etc, there are more basic problems to solve in Mesa etc. I don't know when the open drivers will be ready to deal with OpenGL 3+, it could take a while.

[CiNcH]

Are there docus available describing register offsets for vertical/horizontal visible resolution, vertical/horizontal front/back-porch, sync width, pixel-clock for Evergreen GPU series?