Problems with nouveau driver on linux #914
Comments
|
Thanks for the report. Interesting that you're using nouveau, that's not a driver I've tested before. It might be a couple of weeks before I'm able to test on nouveau here as GDC is coming up next week. Are you able to try testing with the nvidia binary driver? I'd be curious to know if swapping that changes anything. If you're not in a position to try that then fair enough. |
baldurk
added
Bug
|
Ah, wasn't even thinking about it! (the machine is a loaner from work) Installing the proprietary nvidia drivers did indeed fix the problem :) |
|
Interesting. I'll still try to test out on nouveau and see if it's anything I can fix, but I'm glad you got it working 😄. |
|
Some followup that might be interesting: I'm debugging a fairly simple scene that draws some text with a blurred shadow. This calls for 4 passes: draw text, blurx, blury, combine text and blurred text. The recording I made on nouveau shows these 4 passes, and I'm able to view it now that I have the proprietary drivers set up. The textures in the final pass all make sense, but the textures from the earlier passes seem to be full of corrupted garbage from my desktop? Is that expected?
The recording I made on the proprietary drivers, by contrast, only seems to show the final pass! (and possibly the work the preceeding passes do as just loose commands?)
|
|
My guess would be that whatever problems I have on nouveau also affected the readback of texture contents, so what you're seeing is 'archived' garbage from a failed readback. Does that tally up with what you're expecting to see? I'm not sure if you're saying that the latter case looks as it should or not. |
|
The latter case is rendering right, but the events are either very simplified or just actually missing details. Is that just par for the course with blob drivers? (this is presumably unrelated to the original bug, just figured I'd mention it since this gives me some motivation to use the nouveau drivers again if I can) |
|
I'm not entirely sure I know what you mean about the events being simplified or missing details - it seems like the second capture is missing debug markers, is that what you're meaning? The "Color Pass #1" in the second screenshot is added by renderdoc in the absence of any pre-existing debug markers/regions. The drawcalls themselves seem to be the same, at least from the partial screenshots. Those markers are added by the application and don't really depend on the driver implementation at all since renderdoc intercepts them immediately. The only thing I can think of is that some difference between the drivers is causing an feature-detect codepath to do something different on the side of your application. I'm not sure what that would be though. |
|
Ah ok, that could very well be it; thanks! |
baldurk
changed the title
|
It took longer than expected (I couldn't find a way to run nouveau on a system with nvidia binary drivers already configured without messing it up), but I tested on nouveau with mesa 18.0.5 and a GTX 970, and it worked OK in my testing. I'm not sure if it's a hardware difference, or the newer mesa version, or some other factor, but I'm going to close this down either way. If someone has a specific issue that might be because of nouveau please feel free to open a new issue. |
Description
For example in the texture viewer, much of the content is just old pixels from previous tabs or resizing the window, as if that part wasn't being repainted.
Previous discussion/debugging with @baldurk here: https://twitter.com/baldurk/status/973609191511330821
Repro steps
Load any capture and try to use the texture viewer
Environment
qrenderdoc logged graphics info
glxinfo
The text was updated successfully, but these errors were encountered: