Open-Source NVIDIA Driver Is Still Sour For Some GPUs

[phoronix]

Phoronix: Open-Source NVIDIA Driver Is Still Sour For Some GPUs

Nouveau, the reverse-engineered open-source NVIDIA Linux graphics driver that's been in development now for the better part of a decade, is working brilliantly for some NVIDIA GeForce graphics cards while for other NVIDIA GPUs the experience is a sloppy mess. Using the Linux 3.13 kernel and Mesa 10.1-devel Gallium3D driver code installed on top of Ubuntu 13.10, here's what the experience is like when trying a number of GeForce graphics cards with this latest open-source driver code.

http://www.phoronix.com/vr.php?view=19754

[imirkin]

Please tell the nouveau project about your issues!

To anyone who is seeing these sorts of issues with nouveau -- please report them! If we don't know about it, we can't fix it.

See the Bugs wiki page for some basic information that bug reports should have. We do try to address them. In case of a regression like these, a bisect within drivers/gpu/drm/nouveau shouldn't be too time-consuming either and should vastly increase the chances the bug will be resolved.

I realize that Michael doesn't have the time/inclination/whatever to help fix these, but if you -- as a user -- are experiencing these types of problems, help us help you

[curaga]

Some of that corruption is beautiful. I wonder if that's Nvidia's firmware engineers from the past communicating with us.

[AJenbo]

To anyone who is seeing these sorts of issues with nouveau -- please report them! If we don't know about it, we can't fix it.

See the Bugs wiki page for some basic information that bug reports should have. We do try to address them. In case of a regression like these, a bisect within drivers/gpu/drm/nouveau shouldn't be too time-consuming either and should vastly increase the chances the bug will be resolved.

I realize that Michael doesn't have the time/inclination/whatever to help fix these, but if you -- as a user -- are experiencing these types of problems, help us help you

I actually consider setting up a system to test GPU's on a semi regulare basis. Any suggestions on what would be the minimal (especially in terms of maintainable) set up that would give you guys the best information?
(I'm mostly used to Ubuntu, but I use GIT on a daily basis)

[imirkin]

I actually consider setting up a system to test GPU's on a semi regulare basis. Any suggestions on what would be the minimal (especially in terms of maintainable) set up that would give you guys the best information?
(I'm mostly used to Ubuntu, but I use GIT on a daily basis)

Well, for nv50-family, the differences tend to occur at nv50, nv84, nv92, nv94, nv98, nva0, nva3 chips (note -- marketing names have little correlation with the actual chipset). But there are also lots of other factors, like the types of connectors used, the specific scripts in the VBIOS (e.g. recently tracked down a regression that caused HDMI to sometimes fail to modeset on some NV96's due to a vbios command that wasn't quite working right). 3d-wise, nv84+ are basically all the same (within nv50), except some later chips have some additional features. Apparently a bunch of people with nva3-8 have major problems with gpu lockups, but it works just fine for others. Someone recently ran piglit on the original nv50, and apparently it has a lot of problems.

I'm less well versed in fermi+ differences -- 3d-wise fermi and kepler are pretty similar, it's largely the same until gk110/gk208 which use a different shader isa. On the kernel support end nvc0+ are also pretty similar, except for pgraph configuration, which is at least a little different on basically every nvcX card.

For older-than nv50, the differences tend to run in families, i.e. all nv40's are pretty similar, all nv30's are pretty similar. This is less true as you get older and older, e.g. nv17 introduced stuff that wasn't in nv11. And nv11 has stuff that wasn't in nv10/nv15. But I doubt you were talking about GeForce4 and older...

But really, any specific bug reports will always be appreciated -- you don't have to have the ultimate GPU collection to do that. Join us at #nouveau on freenode if you want to talk more specifics!

[AJenbo]

But really, any specific bug reports will always be appreciated -- you don't have to have the ultimate GPU collection to do that. Join us at #nouveau on freenode if you want to talk more specifics!

Actually I was thinking more in terms of software setup. For hardware I am pretty much locked to what i have laying around, but in fact i do belive i have one or two working TNT2 cars

I think I will run threw piglets ons a month and swap threw the GPUs I have lying around connected to a VGA monitor. If i do crash in to any issues with a card i will stop testing and instead focus on bisecting/reporting the issue. So a semi automatic test.

[benmoran]

Just wanted to say thanks to the Nouveau devs for their work, in case any of you guys are reading this. I have a bit older discreet Nvidia card in my workstation at work, and the desktop compositing and basic 3D performance is spot on. It works great with hot-plugging multiple monitors also. The Proprietary driver would hang X about once a day on average, but the open source driver has always been smooth and pleasant. I use all AMD hardware for my personal machines, but I'm sure glad Nouveau exists for the ones I don't own. Cheers guys.

[stalkerg]

Results of Michael as the paintings of Malevich.

[devius]

Some of that corruption is beautiful. I wonder if that's Nvidia's firmware engineers from the past communicating with us.

Maybe it's the software! It's become self-aware and decided to devote itself to art

[leif81]

To anyone who is seeing these sorts of issues with nouveau -- please report them! If we don't know about it, we can't fix it.

See the Bugs wiki page for some basic information that bug reports should have. We do try to address them. In case of a regression like these, a bisect within drivers/gpu/drm/nouveau shouldn't be too time-consuming either and should vastly increase the chances the bug will be resolved.

I realize that Michael doesn't have the time/inclination/whatever to help fix these, but if you -- as a user -- are experiencing these types of problems, help us help you

I've seen a similar "failed to idle channel" gpu hang as Michael, but on my GTX 580, Michael saw it on a GTX 650.

I originnally filed a bug here, https://bugzilla.redhat.com/show_bug.cgi?id=860477

But then later found an upstream report, https://bugs.freedesktop.org/show_bug.cgi?id=54437

There seems to have been next to no visible progress related to this bug. I suspect this is either a lack of resources in terms of people or access to a GTX 580 to debug. A couple different people have added dmesg logs to the FDO bug report, is there enough info provided there? Can I add anything else? I still have access to a GTX 580 and am keen to help in anyway to see it work with nouveau.