AMD vs NVIDIA drivers, that big difference?

[LinuxID10T]

the tesselation unit in hd2000-4000 isn't openGL4 compatible and this oldstyle trueform tesselation unit in 2000-4000 is just broken for unigine in generall.

your talking isn't so smart because in unigine2 nvidia is the clear winner because the benchmark is 100% nvidia focused.


the hd6870 will have a very fine tesselation unit ;-)

When I originally tested the first Unigine for linux, tesselation did work on my 4650 or 4350, however, it was BEYOND SLOW. Now, tesselation on those older cards is broken.

[LinuxID10T]

When I originally tested the first Unigine for linux, tesselation did work on my 4650 or 4350, however, it was BEYOND SLOW. Now, tesselation on those older cards is broken.

BTW, it is compatible with OGL 3.3. The only real difference is that OGL 4.0 allows for FAR more tesselation. I think it is 4 times more, but I could be wrong.

[rohcQaH]

Andre just committed a fix related to lodbias (lodbias affects which level of the mipmap is selected when texturing), not sure how much of the mipmap issue that addreses.

just tested on ioquake3, couldn't see any improvements to mipmap rendering at all.

The commit looks like it was a pain to track down, kudos on that.

[nanonyme]

<offtopic>Speaking of hardware tessellation, does the opensource documentation cover how to use it or are there IP issues?</offtopic>

[bridgman]

We haven't gotten as far as looking at the tesselator yet re: working out programming documentation, ie the only issues so far are time and competing priorities. I don't expect that IP issues will get in the way other than the usual time-consuming process of ensuring that there aren't any serious IP issues

[nanonyme]

We haven't gotten as far as looking at the tesselator yet re: working out programming documentation, ie the only issues so far are time and competing priorities. I don't expect that IP issues will get in the way other than the usual time-consuming process of ensuring that there aren't any serious IP issues

Hmm, I was kinda thinking of the tessellator in r600 series. But yeah, sure, higher priority things first.

[Panix]

Hardware Acceleration on Evergreen/HD5xxx is almost at the same level as 6xx/7xx, with the caveat that acceleration is only supported when running with KMS. As of yesterday there were known issues related to mipmap support and stencil buffer handling.

Andre just committed a fix related to lodbias (lodbias affects which level of the mipmap is selected when texturing), not sure how much of the mipmap issue that addreses. Looks like the fix should get rid of some unpredictable behaviour, so at worst it will probably make the remaining issues easier to diagnose and fix.

KMS is work in progress? There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup. If there's major revisions of the kernel, is KMS particularly effected?

I read this:

http://www.h-online.com/open/features/Kernel-Log-New-X-Server-3D-drivers-for-Radeon-5000-and-new-stable-kernels-1065375.html

I guess that's more open source driver related but for me, I'm wondering about the options of using the binary v.s. open driver. Not a question just stating what I'm mulling over.

[bridgman]

KMS is work in progress?

I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.

There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup.

Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.

If there's major revisions of the kernel, is KMS particularly effected?

KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.

I read this:
http://www.h-online.com/open/feature...s-1065375.html

The article was a bit off near the end... it talked about the Evergreen code being "still located in various development branches", but there is only one branch (evergreen accel branch of xf86-video-ati, created only because there was a release in progress out of master at the time) and all of the other code is in master for the 3D and kernel drivers. I guess maybe it was saying "the code is scattered across all these projects" but that's just how the open source driver code is managed.

I guess that's more open source driver related but for me, I'm wondering about ...

We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.

[Panix]

I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.

Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.

You answered the question, thanks. I was just speculating whether work on KMS was particularly complicated. I have read here and there of discussion about disabling KMS and I was wondering why it seems to be a task done somewhat often. I was wondering if changes to KMS might result in problems that influence a user into disabling KMS. Glad to hear the current state is one in which problems are rare.

KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.

Okay, good to know.

I guess maybe it was saying "the code is scattered across all these projects" but that's just how the open source driver code is managed.

I was interested in getting an analysis of the article so thanks.

We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.

I think it's safe to say I was aware of that. Yes, we were talking about the open drivers but I thought it was time to include closed drivers in the discussion since we're in the binary section of the forum. I read a post of yours relating to the complexity of having both types of drivers 'installed' at the same time or should I say 'able to co-exist?' I hope this can be accomplished; it would be very convenient for users, right? I'm just mentioning it because there are owners of the card who want certain features and they might have to switch back and forth just because they want a certain feature. Even if the plan is to have the FOSS drivers implement "most" (?) of the features, they might have to wait. I believe I would include myself in that group. It depends on what's working and what I wish to do, of course.

Thanks for the replies. I hope those are questions that weren't answered before. I also want to assure anyone who's tired of my questions that I'd do my best to contribute if I ultimately buy an ATI card.

[cutterjohn]

I've been using AMD/ATI HD4870 on Kubuntu x64 for a while now, and then I decided to try out (borrowed) NVIDIA GTX 260 - which is a slightly worse card (on Windows). I also tried NVIDIA 8600 GT which is a quite crappy card.

The results were quite sad, and I'm considering that I failed (Multiple times? Seems odd.) with the AMD/ATI drivers. Please note that glxgears isn't much of a benchmark, but it does show me something.

fgl_glxgears
5500 FPS NVIDIA GTX 260
2100 FPS NVIDIA 8600 GT
2200 FPS ATI HD4870

glxgears
110k frames / 5 seconds - GTX 260
40k frames / 5 seconds - HD4870 and 8600 GT


Here sure is a big difference.

I also tried Wine World of Warcraft, which resulted in about 2-3 times more FPS on GTX 260. And the FPS on 8600 GT was as good or better than HD4870.
I did try a small particle OpenGL program I wrote, which resulted in about two times more particles at higher FPS - on both NVIDIA cards (CPU bound) compared to HD4870.

Do anyone else have any experience using ATI and NVIDIA? It feels like the performance on ATI should be better than this - or is this a common problem?
I'm right now considering buying a NVIDIA Fermi card (as soon as Coolbits is working, and ETA yet?).

NVIDIA Drivers:
256.53
ATI Drivers:
10.8, 10.7, 10.5.

Easy:
nVidia knows how to write decent drivers, while ATI fails miserably at driver implementations. ATI's linux/X drivers are particularly bad, while their Windows drivers are mostly acceptable.

fglrx has been one long trip to bugginess for me with linux, which means this is my first ATI GPU in almost 10y and the experience has been less than pleasing.