01:23 fudgespinner: I'm not sure if it's isolated to Debian, but in some desktop environments. nouveau with DRI3 has issue where it expose odd resolution that is totally unsupported by monitor. this in turn also breaks VESA modes, causing some mode to display incorrectly or go out of monitor's range.
01:24 imirkin: fudgespinner: in certain situations we will add fake resolutions
01:24 imirkin: what's your setup?
01:24 imirkin: s/we/xorg/
01:24 fudgespinner: so what info do I need to supply?
01:24 imirkin: mmm ... well, are you using X?
01:24 fudgespinner: yes.
01:25 fudgespinner: so X config files?
01:25 imirkin: what kind of display is it
01:25 imirkin: no ... X adds in modes automatically, very hard to prevent it
01:25 fudgespinner: An 17-inch, 1280x1024 LCD monitor connected to VGA port of my 9500 GT.
01:25 imirkin: (tbh not sure how one might do that, without disabling a lot of "new" functionality)
01:25 imirkin: early LCD?
01:26 imirkin: and the non-working resolutions are like 800x600 or whatever?
01:26 fudgespinner: Some resolution are way too low, and yes it also breaks other VESA resolutions like 800x600 and 1024x768
01:27 imirkin: can you pastebin your xorg log somewhere?
01:27 fudgespinner: if 2008 was early for LCD, I'm not quite sure if it's monitor's fault or driver.
01:27 imirkin: 2008 was not early for LCD
01:27 imirkin: 2000 was early for LCD
01:27 fudgespinner: with DRI3 enabled, right?
01:28 fudgespinner: and then with DRI2, then...
01:28 fudgespinner: if so. hang on tight.
01:28 imirkin: DRI2 vs DRI3 shouldn't matter
01:29 imirkin: (it it does matter, i'm even more curious about the log contents)
01:29 fudgespinner: I did forgot how to get X logs
01:29 imirkin: usually in /var/log/Xorg.0.log
01:29 imirkin: unless you have systemd
01:29 imirkin: then it's lost forever.
01:30 imirkin: (not really, but i also have no idea how to get logs with systemd.)
01:30 fudgespinner: thankfully the logs is there in /var/log
01:34 fudgespinner: here's the log https://pastebin.com/MEbP0f5A
01:35 imirkin: hmmm ok
01:35 imirkin: actually this monitor does include lots of various modes in its timings list
01:35 imirkin: here's how the edid decodes: http://hastebin.com/raw/volituluqa
01:36 imirkin: which modes don't work?
01:37 fudgespinner: any modes outside native resolution, 800x600 skews the output and 1024x768 cause monitor to pop up 'out-of-range' error
01:38 imirkin: and you're saying this changes depending on the settnig of the "DRI" option in the xorg config?
01:38 fudgespinner: Yes. that log was with DRI2. which both modes will display fine
01:39 imirkin: ok, so ...
01:39 imirkin: that's very odd.
01:39 imirkin: one difference with DRI3
01:39 imirkin: is that we allow "page flipping"
01:39 imirkin: so a buffer from the compositor can end up sent directly to the video card
01:39 imirkin: without an intermediate blit step
01:40 imirkin: however ... this has absolutely no effect on the mode itself
01:40 imirkin: i'm at a bit of a loss
01:40 imirkin: skeggsb_: can you think of anything?
01:40 fudgespinner: is this the first time this occurred?
01:41 imirkin: i've never heard of anything like this
01:41 imirkin: and i've been involved with nouveau for ~8y now
01:41 imirkin: i don't hear/remember everything, of course
01:43 imirkin: i really can't think of any modesetting-related difference between having DRI3 enabled and not
01:51 fudgespinner: Or maybe it doesn't have anything to do with DRI at all. but improper X config. I did recently changed to DRI3 and restart the session, the issue didn't occur. but after I delete said config files the problem reappear...
01:52 imirkin: ah yeah, probably nouveau vs modesetting
01:52 imirkin: if you're on debian or redhat/fedora, they default to modesetting instead of nouveau
01:52 fudgespinner: https://pastebin.com/ZGXR4YTZ
01:52 imirkin: which causes endless problems for users
01:52 imirkin: yeah. note "modeset" instead of "NOUVEAU"
01:53 fudgespinner: ah, thank you...
01:59 fudgespinner: Also some more question, if there's issue with Wine games. it has to be reported with Wine maintainers, right?
02:00 imirkin: depends on the issue
02:00 imirkin: which game, what's the issue?
02:01 fudgespinner: The PC version of Final Fantasy XIII, which has unique issues on its own with both binary driver and nouveau.
02:03 imirkin: mmm
02:03 imirkin: well, it's not one i know offhand
02:03 fudgespinner: For nouveau, there's severe graphical artifacts at certain parts of the game and Wine will constantly throws up out of memory error. Upon starting the Pulse Vestige level, severe textures glitches where it seems like the game has random texture applies all over the area.
02:04 fudgespinner: *out of video memory error.
02:04 imirkin: the tesla generation (of which your G96 is one) has a variety of generic problems with nouveau
02:05 fudgespinner: I see... there's nothing we can do...
02:05 imirkin: well
02:05 imirkin: not nothing
02:05 imirkin: but no easy fixes :)
02:05 imirkin: i have a theory
02:06 imirkin: but i haven't had time or motivation to investigate it in ... many years
02:06 imirkin: and i doubt anyone else cares much about tesla graphics
02:06 imirkin: [and apparently i don't either]
02:07 imirkin: i assume you see messages in dmesg as well when these out of memory errors happen?
02:07 imirkin: if not, it could be something silly relating to 32-bit memory space exhaustion
02:07 imirkin: in which case something _could_ be done
02:07 imirkin: we could unmap buffers more aggressively
02:07 fudgespinner: In terminal since I run the game there to see if there's odd issue like I've seen in binary driver.
02:11 fudgespinner: and while binary drivers are more stable, it also has issues on its own. Such as black screen after loading saves or character model not render properly (also applies to nouveau) missing graphical effects (also applies to Windows in certain circumstances, but easily broken even with normal settings on Linux)
02:12 imirkin: yeah, blob driver is a _lot_ more stable than nouveau
02:12 imirkin: it's not 100% perfect
02:12 imirkin: but it's also a lot better than it used to be a while back
02:15 fudgespinner: ended up devoting my time to test the game and have no time to play FF13. the port is known to be broken back when it was released as well, but I can't fathom how fragile it can be by running it under Linux.
02:16 fudgespinner: On my system, the game didn'
02:16 fudgespinner: ..didn't perform well, but it's to be expected.
02:41 imirkin: if there are straightforward rendering bugs, you can report them
02:42 imirkin: "harder" stuff is not likely to get too much attention
03:19 fudgespinner: thanks, and since the game is quite unpredictable and unusually fragile. I think there's nothing we can do for this issue.
03:20 imirkin: (i mean, you can report it either way, just tempering your expectations)
03:24 fudgespinner: I doubt it's the issue with nouveau alone, considering that Steam defaults to DXVK for everything, which fixed everything about FF13 and 13-2. This might need to be fixed on both sides
03:24 fudgespinner: *this might need a fixes on Wine on some degree
03:34 HdkR: DVXK solving everyhing just means that Nouveau needs to be converted to a Vulkan driver right? ;)
03:41 imirkin: dunno if the tesla boards will be able to expose enough vk for dxvk to be happy
03:41 imirkin: semi-recently i did push out ES 3.1 support on the DX10.1 ones though
03:42 imirkin: it's like ... 99% there. no textureGather with explicit component ... but i feel like we can be forgiven on that point
03:43 imirkin: (also compute/graphics sync issues, but what else is new)
13:41 tagr: imirkin, karolherbst: thanks for forwarding that Tegra issue on gitlab
14:49 karolherbst: tagr: how should we deal with that in the future though?
14:50 tagr: karolherbst: perhaps it'd be best to create a new module/component/whatever-gitlab-calls-it for Tegra
14:50 karolherbst: the easiest for us would be tegra having the issue tracker on gitlab, then we could just move the bugs :D but we can also just label those bugs once they appear and you can subscribe on that label
14:51 karolherbst: is there an issue tracker at all for tegra? If not you could just open a project and make it issue only
14:51 karolherbst: at drm/tegra maybe?
14:51 tagr: so far we haven't had the need for an external bug tracker because people would usually report them on the mailing list and then we'd either address them quickly enough or track them internally
14:51 karolherbst: okay
14:52 tagr: yeah, that seems like the easiest
14:52 karolherbst: then just let us mark them via the label and you make sure you get the emails or something :D
14:52 tagr: I suppose it wouldn't have to be "issue-only", we could also keep libdrm and mesa forks there for example
14:52 tagr: and maybe also track these nouveau/tegra integration issues there
14:52 karolherbst: sure
14:53 karolherbst: tagr: also.. fun bug but it's a nouveau issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/119
14:54 karolherbst: guess stuff like that could happen more often on tegra devices actually
14:55 tagr: yeah, I think it's rather common for people to stick a dGPU into one of those devices and then run the proprietary stack on it
14:56 tagr: but this doesn't even seem like a Nouveau bug, it's more of a general kernel module issue
14:56 karolherbst: yeah...
14:57 tagr: I /think/ there might be a way to use module aliases to prevent a module from being bound to a given device, but I don't remember the details
14:58 tagr: actually, I'm not sure how that would work... once the module is loaded, it's really up to the kernel to deal with this and there's nothing there that I know of that would allow a specific device to get skipped
14:58 karolherbst: yeah..
14:59 tagr: what I've done in the past on desktops where I wanted to run a mix of nouveau and nvidia, I would usually let either one take over both (by denylisting the other), then unbinding one device via sysfs and then manually modprobing the denylisted one
14:59 tagr: but yeah, has the caveat that imirkin mentioned with the console
14:59 tagr: sometimes it can work automatically if one of the GPUs is old enough for the proprietary driver to refuse to bind to it
15:01 karolherbst: yeah...
15:01 karolherbst: I am also not sure if mixing both will always work.. like think of laptops and drivers starting to do some ACPI stuff
15:02 tagr: yeah, luckily on laptops you often don't have the option of plugging in a GPU to begin with
15:03 karolherbst: Thunderbolt
15:03 tagr: not sure how firmware would deal with those "external" GPU things
15:03 karolherbst: not at all I think
15:03 tagr: probably don't touch them at all, I would guess
15:03 karolherbst: there are some thunderbolt things going on, but nothing important
15:03 karolherbst: at least.. nouveau or nvidia wouldn't touch it
15:04 karolherbst: hot unplugging is quite broken with nouveau anyway
15:04 tagr: I had done some work on that a while ago but never got around to polishing the patches
15:05 tagr: I guess it wasn't really for hot unplugging in the sense of PCI
15:05 tagr: it was more about making sure we could properly unload the driver (I think that might currently be broken on Tegra) and suspend/resume properly
15:06 tagr: can't do a proper hot unplug with the built-in GPU for testing, unfortunately =)
15:06 karolherbst: yeah...
15:09 ajax: you... kinda can
15:09 ajax: you could coerce the pci layer into disabling all of its pci decodes