00:24 imirkin: karolherbst: RT_HORIZ is set in nvc0_validate_fb.
00:24 imirkin: karolherbst: and the whole glReadPixels thing is the thing i said was broken with MSAA visuals
00:25 imirkin: so like glReadPixels isn't aware of MSAA. and so if you try to do it on a MSAA fb, then you get a GL_INVALID_OPERATION. makes sense, right?
00:25 imirkin: but no, if you have a MSAA visual, then the fb that's displayed is implicitly resolved
00:25 imirkin: and so when you do a glReadPixels, you're supposed to do an implicit resolve
00:25 imirkin: we don't handle that properly.
00:26 imirkin: [resolve == operation that takes a MSAA fb and comes up with a single color per pixel out of all the samples. in the case of stencil and other integer buffers, that means "take the value for sample 0"]
00:27 imirkin: [and to all the people sitting around laughing and saying, "ha, this guy doesn't know shit about opengl" -- please speak up and correct me.]
00:34 airlied: I'm laughing, but it sounds correct :-)
00:36 imirkin: airlied: in case you care to laugh some more: https://www.youtube.com/watch?v=5FFRoYhTJQQ
02:01 Llmiseyhaa: Good evening folks
02:04 Llmiseyhaa: I have been working through various troubleshooting and FAQs but I still have a persistent problem with my system hard locking... strangely, particularly when I go to a map site like maps.google.com. Both firefox and chrome. Sometimes I can SSH in and kill chrome (or X) and get things moving again, other times not.
02:04 Llmiseyhaa: GF108 on a GT730 board
02:04 gnarface: got swap?
02:05 Llmiseyhaa: 16GB of swap, 16GB of main memory
02:05 gnarface: hmm. i'm not sure if it's a known issue or not. what kernel & mesa versions?
02:06 gnarface: sometimes newer is better. sometimes not.
02:07 Llmiseyhaa: 4.12.10, though I've had it off and on since 4.10 or earlier
02:07 Llmiseyhaa: mesa 17.0.6
02:07 gnarface: well that's all pretty new
02:07 gnarface: hmm
02:07 Llmiseyhaa: xorg-server 1.19.3, running glamor though I had the same issue with the nouveau ddi
02:07 Llmiseyhaa: err, ddx
02:07 Llmiseyhaa: https://gist.github.com/anonymous/d7ab2e577440599fabbb137d243caca5
02:07 Llmiseyhaa: that's the relevant kernel messages, including bringup for the gf108
02:08 Llmiseyhaa: Ryzen 7 1700, Corsair memory in stock speed (not X-AMP), half of my memory is in 8x1GB hugepages that I use for a Windows VM, and I have an AMD GPU that I pass through to Windows. Other than vfio-pci though nothing under Linux touches that and I'm booting UEFI without CSM so while both are brought up during boot, Linux only ever does anything with the GF108.
02:10 Llmiseyhaa: I haven't run into swap to my knowledge, though I set it up as back in the day like kernel 2.2 or something the Linux kernel did not care for having no swap and I wanted to have the option of suspend-to-disk. Have since decided not to use it, but, eh, storage is cheap.
02:11 gnarface: hmmm
02:11 Llmiseyhaa: Thank you for the replies, by the way. I didn't see any known bugs that covered this.
02:11 gnarface: well i'm sorry, i've got nothing to help
02:11 Llmiseyhaa: If I missed one, I certainly apologize.
02:11 gnarface: i can guess it could be a memory leak or other such problem with mesa though
02:12 gnarface: 17.x is pretty new and chrome and firefox both use opengl-accelerated rendering by default
02:12 Llmiseyhaa: Hrm. Maybe, but it seems to happen just as easily right after I boot as later.
02:13 gnarface: i wonder if it would happen with any opengl program at the same speed/rate
02:13 gnarface: i wonder if it would not happen when running something else entirely non-opengl
02:13 gnarface: the only fixes i can suggest are deductive
02:13 gnarface: i guess that means they're not really fixes, just tests
02:13 Llmiseyhaa: Well, I've tried setting chrome to disable OpenGL via commandline; not sure if it does what it says though or if it lies to me.
02:14 Llmiseyhaa: That gist would seem to -- though I'm not discounting your theories, and I appreciate them -- some form of driver or card error. It always starts with a "DATA_ERROR" of the type "INVALID_BITFIELD". Often channel 4, though I'm not sure if that's just coincidence or not.
02:14 gnarface: i would think there'd be a noticable change in the amount of ram it takes to render a page
02:15 gnarface: hmmm
02:15 gnarface: i don't know enough about the driver to know what that means, but it does sound suspicious
02:15 Llmiseyhaa: No segfaults either since I got a stepping 1 Ryzen off of AMD RMA
02:16 Llmiseyhaa: and no other messages in kernel logs or dmesg that would indicate any hardware issues.
02:16 Llmiseyhaa: (I keep suspecting bum RAM, but I'd expect to see other issues in userland there.)
02:16 gnarface: data error, invalid bitfield... what could that mean? it gets passed the graphical data with an alpha-channel it's not expecting? something like that?
02:17 gnarface: if you could trigger it more reliably, that would help narrow the issue
02:17 Llmiseyhaa: Oh, I can. Every time I try to go to a map page, it may happen immediately or it may happen after a bit.
02:17 gnarface: what's the browser doing usually when it locks up? is it always on a page with ads, or video?
02:17 Llmiseyhaa: Even embedded OpenStreetMap stuff. I've literally booted, relaunched my browser, and had it.
02:17 gnarface: oh right, you said maps
02:18 Llmiseyhaa: If I by some chance manage to load them, the moment I click and drag in one, it locks. Cursor still moves, but I can't interact with anything strangely.
02:18 gnarface: now that's odd
02:18 gnarface: using desktop compositing?
02:18 Llmiseyhaa: Yeah, XFCE
02:18 Llmiseyhaa: Hadn't thought to disable it. Let me go do that now.
02:19 gnarface: i'd try disabling desktop compositing AND opengl in firefox, then aggressively see if maps would still lock it up
02:19 gnarface: then if they don't, i'd run glxgears or some gl screensavers of some sort until it locked up
02:19 gnarface: and if that didn't lock it up, i'd just never turn on compositing again
02:19 Llmiseyhaa: Weirdly I've not actually seen any GL screensaver lock. o..O
02:20 Llmiseyhaa: I use the one that shows a car engine because I'm a wrench wench when I'm not working on computers.
02:20 gnarface: the guys who actually know stuff are usually in here earlier in the day
02:20 Llmiseyhaa: Holy shit I turned off compositing and my window movements got slower. o..O
02:20 Llmiseyhaa: I... did not expect that. Well, wish me luck.
02:20 gnarface: good luck
02:20 gnarface: oh, yea compositing smooths stuff out a bit
02:20 gnarface: but how much slower is it?
02:21 Llmiseyhaa: Drastically slower.
02:21 gnarface: if it's TOO much slower, it might be a sign of something else wrong
02:21 Llmiseyhaa: I am running the card at PCIe x4, and I'm in the glamor DDX
02:21 Llmiseyhaa: and firefox just crashed, no nouveau errors but firefox died.
02:21 gnarface: hmmm
02:21 Llmiseyhaa: switching to nouveau DDX
02:21 gnarface: which distro is this you're using?
02:21 Llmiseyhaa: Gentoo.
02:22 Llmiseyhaa: brb
02:22 gnarface: doing anything crazy with the compilation flags? compile the kernel or mesa with -O3 or anything edgy like that?
02:22 gnarface: sometimes stuff isn't stable above -O2
02:24 gnarface: i'd be curious if it still happens on something older, like devuan jessie
02:25 gnarface: you might just have run into a new bug. not a lot of people are using all this bleeding edge software with nouveau
02:26 frobos: had the same problems with a 660ti and random system hangs
02:27 frobos: dmesg didn't help
02:27 gnarface: i don't know anything at all about glamour
02:27 frobos: the answer I got is that nouveau can't track it down without nvidia's full docs
02:28 frobos: I was on gentoo as well, compiling all with O2 and many software versions
02:28 frobos: tried reclocking as well
02:28 frobos: nothing solved the problem
02:29 Llmiseyhaa: Nope. -O2
02:30 Llmiseyhaa: and I can't run anything older because Ryzen 7
02:30 Llmiseyhaa: Anyway, on the nouveau ddx and everything is snappier than I remember it being, well, pretty much ever. Guess the card isn't that capable of doing 2x 1440p screens with compositing. I am asking a lot of an old GF108.
02:31 Llmiseyhaa: Though before folks suggest newer: I can only fit a single slot card for my Linux video
02:31 frobos: yea, with nvidia for full support you will need proprietary driver
02:31 frobos: this nugget would save me hours of bug hunting
02:31 duttasankha: can someone help me about the purpose of the code inside nvkm/engine/gr?
02:32 gnarface:can't
02:34 Llmiseyhaa: Well, confirmed; I still get the crash with compositing off and using the nouveau ddx
02:35 Llmiseyhaa: Unfortunately I was not able to get it to sync the logs to disk before rebooting so I can't be certain of the error messages but every time I have borrowed my wife's computer to SSH in and reboot, I've had the same messages.
02:36 gnarface: maybe imirkin knows something about it
02:36 Llmiseyhaa: Notably, while the rodent doesn't lock up the keyboard handler in X does. o..O
02:36 gnarface: you could set up network logging
02:36 Llmiseyhaa: (At least I presume it's in X, because I can't even turn off numlock.)
02:36 Llmiseyhaa: I could. We do have a home server. I've simply been lazy.
02:37 Llmiseyhaa: I wish I could get Intel graphics, but being an AMD Ryzen that's pretty impossible.
02:37 duttasankha: gnarface: maybe imirkin knows something about it ....was that for me?
02:37 gnarface: sorry, no duttasankha it wasn't intended to be, but coincidentally it also probably applies to you
02:38 duttasankha: :)
02:39 duttasankha: no worries..thanks...and sorry to coming in between the conversation
02:39 Llmiseyhaa: So failing that, when I go water cooling I'll likely modify some dual-DVI AMD GPU board to fit in a single slot with a water block on it. Until then, though, I've got to keep this working. Though I've been pondering a GT1030... GP108 is rather newer.
02:39 Llmiseyhaa: It's single slot, two DVI outputs, etc so it might do me. Both my monitors are dual-link DVI _only_. Yeah... annoying and weird, but... is what it is.
02:40 Llmiseyhaa: How's the Pascal support doing, does anyone know?
02:41 rhyskidd: Llmiseyhaa: Pascal support is limited; without more on your desired use case, it's probably not what you want
02:42 rhyskidd: Absence of acceleration means cards are *slow*, even if you aren't affected by chip specific problems nouveau has
02:42 Llmiseyhaa: Two 1440p displays and basic desktop stuff.
02:42 Llmiseyhaa: All of my games get run under Windows; good to know before I go invest in a GP108.
02:42 rhyskidd: Laptop? OPTIMUS?
02:42 Llmiseyhaa: Desktop.
02:42 Llmiseyhaa: Ryzen 7 1700
02:42 rhyskidd: I think we only have basic display output working for GP108, no accel or others
02:43 rhyskidd: Absence of redistributable firmware for the GP108 hampers us
02:43 Llmiseyhaa: Yeah, that won't do me and I'm not sure I trust the nVidia drivers on a system meant for PCIe passthrough.
02:44 rhyskidd:checks again for GP108 in linux-firmware.git ... not there
02:47 Llmiseyhaa: Hrm. Only vaguely related question, but should the GF108 be as... struggling as it is driving 2x 1440p displays for basic desktop usage (browser, SSH terminals, chat apps, etc)
02:47 gnarface: maybe, if reclocking isn't working
02:47 Llmiseyhaa: With the caveat that I can only run it at PCIe x4, but it's still slower than I remember desktop apps... ooooooh.
02:47 gnarface: i thought i heard it was for those cards, but maybe i'm wrong
02:48 Llmiseyhaa: How can I tell? It does hover right at 45C so you might be right about that.
02:48 gnarface: i'm not sure how to tell
02:48 gnarface: maybe with envytools?
02:48 gnarface: with the proprietary drivers you can just see it in nvidia-settings
02:49 Llmiseyhaa: ooooh, may have found it
02:50 Llmiseyhaa: well, looking at /sys/kernel/debug/dri/0/pstate
02:50 Llmiseyhaa: I've got four listed... 03, 07, 0f, and AC.
02:51 Llmiseyhaa: judging from the listing, I'm on 07, because 07 and AC are the same. So 405MHz core, 324MHz memory
02:52 Llmiseyhaa: aw bugger, nope, no reclocking on GF108
02:52 Llmiseyhaa: "Function not implemented" when trying to write to the pstate file
02:53 Llmiseyhaa: hey, looks like Pascal is (or already has) gotten 2D/3D accel in 4.12 (=
02:55 gnarface: honestly that's still a really nice card for a multi-headed linux desktop, with the proprietary drivers. i hear ya on the security concern though.
02:55 Llmiseyhaa: Oh, the current proprietary drivers work?
02:55 Llmiseyhaa: I thought GF108 was so old it wouldn't do it
02:56 gnarface: you said it was a 780?
02:56 Llmiseyhaa: GT730, GF108 chip, NVC0 family
02:56 gnarface: current drivers still support back to 500 i think
02:56 gnarface: definitely 600, maybe also 500
02:57 gnarface: you're right they'll roll off support eventually, but i'd guess you have a couple years before that happens
02:58 Llmiseyhaa: Well I'm not so worried about the security (I mean I am but I use google fi, have a google phone, etc so I'm already snooped so much)... it's more
02:58 Llmiseyhaa: PCI passthrough rigs are already touchy
02:58 Llmiseyhaa: I'm afraid the nVidia drivers will do something that screws up my PCI passthrough
02:58 Llmiseyhaa: and yeah, I know, I'm buying myself trouble with that but hey
02:59 Llmiseyhaa:installs nvidia-drivers
03:01 gnarface: the other thing that the nvidia proprietary drivers drop the ball on is xrandr layout syntax
03:02 Llmiseyhaa: Yeah, that I'm not too worried about as long as I can get my screens side by side.
03:02 Llmiseyhaa: well, and these things have corrupt bum (I know, I know) EDIDs
03:02 gnarface: if you were doing something too fancy or cute with your multi-monitor layout, you may end up having to re-do it for the more limited feature set
03:02 Llmiseyhaa: But nah I'm just doing side by side
03:02 gnarface: side-by-side with the first one on the left should not be a problem
03:02 Llmiseyhaa: yup that's how I run 'em
03:08 Llmiseyhaa: updating to 4.13.5 while I'm at this.
03:17 imirkin: Llmiseyhaa: what's the quick summary of your issue? random hangs with nouveau when accessing maps.google.com?
03:17 gnarface: in chrome AND firefox, with or without opengl rendering and compositing in xfce
03:18 imirkin: anything interesting in dmesg?
03:18 imirkin: oh
03:18 imirkin: Oct 12 18:23:46 gryphon kernel: nouveau 0000:21:00.0: X[843]: nv50cal_space: -16
03:19 gnarface: "DATA_ERROR" of the type "INVALID_BITFIELD". Often channel 4, though I'm not sure if that's just coincidence or not.
03:19 imirkin: that means "congratulations, you have run out of vram"
03:19 Llmiseyhaa: Well that makes sense.
03:19 Llmiseyhaa: 2x 1440p displays.
03:19 imirkin: the fact that this happens *after* the various data errors is definitely rather odd.
03:20 imirkin: 4GB of vram is quite a bit, too
03:20 imirkin: so i'm not sure how this would happen
03:20 imirkin: btw... wtf kind of board is this? 21:00.0 for the pci device id?
03:20 Llmiseyhaa: Well, maybe maps just request a gigantic surface?
03:21 Llmiseyhaa: Ryzen 7 1700
03:21 Llmiseyhaa: MSI x370 SLI Plus
03:21 gnarface:is so jealous
03:21 imirkin: are there 21 pcie slots?
03:21 Llmiseyhaa: Nope.
03:21 Llmiseyhaa: But lots of onboard stuff and numbering is weird
03:21 Llmiseyhaa: because there's a bunch of lanes off the CPU then a bunch of lanes off the 'northbridge'
03:21 imirkin: i guess each onboard thing, yeah
03:22 Llmiseyhaa: I'm running this off the northbridge since any cards I put in my two CPU powered slots get stuck in the same IOMMU group
03:22 Llmiseyhaa:shakes fist at MSI firmware devs or whoever's responsible for THAT map.
03:23 imirkin: well, this is weird
03:24 imirkin: Oct 12 18:23:42 gryphon kernel: nouveau 0000:21:00.0: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 4 [00ff941000 X[843]] subc 0 class 9197 mthd 0fc0 data 3f800000
03:24 Llmiseyhaa: Yeah.
03:24 imirkin: that's inside of MSAA_MASK
03:24 Llmiseyhaa: Huh
03:24 imirkin: while that's clearly a 1.0 float value
03:24 imirkin: [which would not be appropriate for the MSAA_MASK]
03:25 imirkin: this points to some kind of grctx restore failure
03:25 Llmiseyhaa: Hrm.
03:25 imirkin: skeggsb: what do you make of it?
03:25 imirkin: that happens before any "X[843]: nv50cal_space: -16" messages
03:25 imirkin: and then 4s later, total fail
03:26 imirkin: i wonder if there's some kind of grctx restore failure condition under vram pressure
03:26 Llmiseyhaa: What's really strange (to me) is the cursor never dies.
03:26 Llmiseyhaa: I can move the rodent and the cursor follows but nothing responds at all.
03:26 imirkin: that's normal
03:26 Llmiseyhaa: Aaaaah, just seemed really weird to me. Sorry. (=
03:26 imirkin: well, cursor position is just updated directly
03:26 imirkin: it's composited in hardware
03:27 imirkin: when you see a hang, your system is actually totally fine
03:27 imirkin: with the minor small inconvenience of not getting anymore screen updates
03:27 Llmiseyhaa: Oh, I know. I can SSH in and sometimes if I kill X (or chrome/firefox) I can recover it but sometimes not.
03:30 Llmiseyhaa: Sometimes firefox just crashes, other times lockup I can recover over SSH, and finally there are times I can't recover it... X is dead, kill -9, not in ps aux... but display still shows the same thing
03:30 imirkin: wait
03:31 imirkin: are you using the modesetting ddx?
03:31 imirkin: or nouveau?
03:31 Llmiseyhaa: I've tried both
03:31 Llmiseyhaa: modesetting ddx with glamor and nouveau ddx
03:31 imirkin: nouveau definitely is going to handle funny cases much better
03:31 imirkin: i'd strongly advise against using glamor with nouveau
03:32 Llmiseyhaa: Ok, at least somewhere on the page they suggested using the modesetting ddx + glamor for newer cards
03:32 imirkin: ok
03:32 skeggsb: imirkin: pretty sure context switching doesn't go through the class interface, and restores the "strands" instead, so they wouldn't trigger class errors
03:32 Llmiseyhaa: But I'm good with whichever
03:32 imirkin: i guess they would advise to use glamor. but i would advise to not use it :)
03:33 imirkin: skeggsb: well, i just mean if some bit of context got restored "wrong"
03:33 imirkin: skeggsb: so that when process the "next" fifo command it lost its place
03:33 skeggsb: yes, but those errors are triggered in response to decoding methods, which means they came through the push buffer somehow
03:33 imirkin: skeggsb: i guess that'd be a FIFO "concern", not a GRAPH concern...
03:33 Llmiseyhaa: I did have some cases where the nouveau ddx would repaint the entire contents of the screensaver that was stopped minutes ago over the screen then anything else would just update over top of that so you had to go through each window to get it back.
03:34 Llmiseyhaa: Both my wife and myself have had that particular bug on the nouveau ddx with a GF108. Minor though.
03:34 imirkin: Llmiseyhaa: the nouveau ddx is hardly perfect. but what it does do is error handling.
03:34 Llmiseyhaa: I'm not trying to argue, I apologize if it came across that way.
03:34 Llmiseyhaa: I was more trying to explain myself there, is all.
03:34 imirkin: imho that's a very important quality in an xorg ddx. others don't agree.
03:36 imirkin: skeggsb: i guess some kind of multithreading thing could trigger a similar problem. that's the only thing i can think of for how you might end up with a 1.0 in MSAA_MASK. the next theory goes along the lines of memory corruption.
03:36 imirkin: skeggsb: speaking of... how's the mt stuff going? :)
03:37 imirkin: Llmiseyhaa: btw, i lied. "X[843]: nv50cal_space: -16" is actually indicative of running out of pushbuf space (sorta)
03:37 skeggsb: imirkin: sidelined for the moment...
03:37 imirkin: this happens for two reasons - #1 - gpu has hung, #2 - you're submitting commands *really* fast
03:38 imirkin: skeggsb: =/
03:42 Llmiseyhaa: ok, well, for now BRB gonna try the nvidia binary drivers. Thanks for the help folks
03:59 Llmiseyhaa: well, know this isn't quite the channel for it but nvidia binary drivers work and don't kill my PCI passthrough
04:00 Llmiseyhaa: for the time being I'll keep it set up where I can swap back and forth between them and try nouveau now and again, thanks for the help guys. If anyone thinks of stuff they'd like me to try and/or log, I will (=
08:22 giovdav: Hello!
08:23 giovdav: some one can help me? I have some troubles with nouveau on Centos 7.4 with KDE4
08:30 karolherbst: imirkin: yeah makes kind of sense, because glReadPixels reads the Stencil buffer and the values look the same with apitrace, where I suppose it does a texture view or something like that and not glReadPixels
09:01 karolherbst: imirkin: but in the end it actually reduces my confusion, because now my observation starts to make sense
09:16 karolherbst: giovdav: uhh, that's like ancient software. What GPU do you have?
09:16 karolherbst: giovdav: bugfixes are usually not backported to _very_ old software
09:17 giovdav: karolherbst: ug :( i have a Quadro K600
09:17 karolherbst: gk107
09:17 karolherbst: okay, so you want a kernel like 4.12
09:17 karolherbst: and mesa-17.1 at least
09:17 giovdav: karolherbst: so your advice is to update the kernel?
09:18 karolherbst: my advice is to update everything
09:18 giovdav: ahahah :D
09:19 giovdav: yes could be a good solution! :)
09:20 karolherbst: I have no clue what the code is on centos 7.4
09:20 karolherbst: it might be all recent enough and maybe not
09:20 karolherbst: who knows
09:20 karolherbst: skeggsb might know it :D
09:23 airlied: 17.0.1
09:23 karolherbst: airlied: yeah, but I was more thinking about the kernel side
09:23 karolherbst: or more worries about that
09:23 karolherbst: *worried
09:24 giovdav: i'm searching about the kernel update on Centos.. and what about the proprietary driver? someone have some experiences on it?
09:24 karolherbst: I saw it has pascal support, but no idea what the actual source code is
09:28 karolherbst: giovdav: but what are your troubles explicitly? Maybe it is one of those which isn't fixed yet
09:30 giovdav: karolherbst: after a computer hibernation my desktop hang/freeze .. and xorg appear dead .. -.-"
09:30 giovdav: karolherbst: i also have some glich in daily use .. some pixels are not displayed well ..
09:31 karolherbst: pmoreau hat at some point working live images with recent nouveau code, no idea what the status is here
09:32 pmoreau: karolherbst: They are still being compiled every week with the latest version (except when they break of course) :-D
09:32 karolherbst: :)
09:32 karolherbst: giovdav: so you might try those
09:32 airlied: tge centos kernel makefilechas a drm version in it
09:32 karolherbst: pmoreau: is it possible to install like KDE 4 on those?
09:33 pmoreau: I don’t think there is enough free space left on the images for that.
09:37 karolherbst: pmoreau: I meant on the live system. It's usually stored in RAM
09:37 karolherbst: I hope it doesn't take too much space though
09:40 pmoreau: True it is usually stored in RAM, but installing more than 10–50MB (of the top of my head) results in some error about not enough space, or failed to write to device. I haven’t investigated it.
09:41 karolherbst: I see
12:27 karolherbst: giovdav: in any case, it would be nice to get some info out of dmesg or the X logs or anything. Maybe it is a known issue, maybe it is something new, maybe somebody can reproduce this and we could try to fix it
12:28 aphirst: btw i can't remember which username i was speaking to the other day about the HDMI audio thing, but i saw in the mailing list thread that they'd "think about it" and get affected users to test it as and when ready
12:29 aphirst: so I just wanted to say that I'm willing to do that, and am (almost) always online
12:30 giovdav: karolherbst there was nothing
12:30 karolherbst: giovdav: :/
12:31 giovdav: i have read now about the improvements of nouveau in the 4.3 kernel
12:31 karolherbst: giovdav: idea: next time ssh into the machine and try to kill X
12:31 giovdav: by the way for now i have installed the proprietary driver
12:31 karolherbst: giovdav: on CentOs I wouldn't rely on kernel versions at all. it might be that you have a 4.2 kernel with 4.10 drm subsystem or something
12:33 karolherbst: giovdav: can you run uname -r?
12:58 giovdav: karolherbst: 3.10.0-693.2.2.el7.x86_64
13:19 imirkin: giovdav: kernel 3.10 was released June 30, 2013. believe it or not, but there have been one or two fixes in the past 4 years.
13:19 karolherbst: imirkin: CentOs ;)
13:19 imirkin: irrelevant.
13:19 karolherbst: no, it is
13:19 karolherbst: they have pascal support
13:19 karolherbst: ;)
13:19 imirkin: but who knows how
13:19 karolherbst: exactly
13:19 karolherbst: but usually they rebase new code on 3.10
13:20 karolherbst: and stay with 3.10 like forever until there is a new major release
13:20 karolherbst: I wouldn't be surprised if there is the 4.10 drm code in it or so
13:21 karolherbst: airlied said that the exact drm version is in one of the files in the sources, but I am too busy right now to look it up
14:34 giovdav: yes imirkin you have reason, i'm thinking to update kernel with elrepo
14:35 imirkin_: that said, my recollection is that KDE + nouveau = fail, so perhaps that won't help
14:36 imirkin_: dunno what other people's experience is. i never use KDE or GNOME or any of that stuff.
14:37 karolherbst_: well with KDE 4 it shouldn't be as bad though
14:37 karolherbst_: dunno
14:52 gnarface: anything with compositing on by default is gonna be like punching yourself right in the nuts
14:52 gnarface: i can't imagine it'd still be a problem if you can turn it off though
14:53 gnarface: (which i think is possible in KDE but not in Gnome anymore? not sure)
15:04 loonycyborg: nouveau is used by default in fedora, so they'd have to make it work
15:04 loonycyborg: at least on newer cards
15:11 karolherbst: loonycyborg: and who is paying them to do so ;) just asking about why they _have_to_ make it work
15:11 loonycyborg: well fedora is base for red hat linux
15:12 loonycyborg: so the answer would be "Red Hat" :P
15:12 karolherbst: okay let me rephrase: who of the users is paying
15:13 karolherbst: it is all fun and games until somebody starts to say somebody "has to" get something work, then it gets difficult
15:13 karolherbst: if you want somebody to have to getting it to work: pay, if you can't pay, then help out yourself
15:14 loonycyborg: I mean they'd have to either make nouveau+gnome work or lose support for nvidia cards
15:14 loonycyborg: since they're not using blob by default
15:15 karolherbst: no, they don't "have to". It would be nice it they did and they are also working on it and have paid devs who do this, but technically they don't "have to". I am mainly complaining about the term "have to" and what it's implicit message here is
15:15 loonycyborg: anyway, I'm actually running fedora+gnome with nouveau on other pc
15:16 loonycyborg: and it works nicely once it's using fermi based card
15:16 karolherbst: yeah and most here are actually interested in fixing bugs
15:16 loonycyborg: before that there was geforce 6800GS and it broke horribly with updates
15:16 loonycyborg: both with nouveau and nvidia-drivers
15:17 karolherbst: uhh, makes sense
15:17 karolherbst: I guess they started to use advanced GL features nobody cares about on a 6800GS
15:18 loonycyborg: I didn't have much luck running kde+nouveau on this gentoo desktop though
15:18 karolherbst: I hope I will be able to build some reliable nouveau CI, so that we actually are able to prevent regressions, because this is something we don't do for nouveau right now
15:18 loonycyborg: it works basically but there are occasional hangs and gpu lockups
15:19 karolherbst: interesting
15:19 karolherbst: even on 4.13 with mesa 17.2?
15:19 karolherbst: with 4.13 I mean the kernel, not kde4
15:19 loonycyborg: I don't remember which exact versions I used last time
15:19 karolherbst: okay
15:25 peterius: for anyone who is interested, those 10 second hangs were not because of any of the firmware things, they were, I think, because of tracing in the kernel
15:25 peterius: I saw the trace_printk warnings in dmesg but didn't think that could cause such hangs but I guess somehow either nouveau or i915 interacts badly with kernel tracing
15:25 peterius: at least on my card
19:25 karolherbst: imirkin_: does the code in nvc0_miptree_transfer_map needs to be adjusted for that implicit resolve or at some earlier point?
19:25 imirkin_: no, that sounds right
19:25 imirkin_: and transfer_unmap
19:26 karolherbst: okay
19:27 karolherbst: the samples=2 case is fun, because half of the read out pixels are correct
19:28 imirkin_: iirc i tried to fix it up
19:28 imirkin_: but it was non-trivial.
19:28 imirkin_: and felt unimportant at the time, so i gave up
19:28 karolherbst: mhhh, wondering if I actually need to put that stuff into nve4_m2mf_transfer_rect or not
19:28 karolherbst: feels like the right place
19:29 karolherbst: fun fact though: nvidia uses the 2X1_D3D ms_mode
19:30 karolherbst: mhh, I am wondering
19:32 imirkin_: like i said, it wasn't a trivial fix
19:32 imirkin_: i went around in circles thinking "oh, is this the right place to put it"
19:33 karolherbst: mhh
19:33 karolherbst: I made a diff from the mmt traces and there it looks rather trivial, now I am wondering if we actually miss to set some stuff as well
19:42 karolherbst: imirkin_: do you know why nvidia uses those weirdo pitch values? like 0xfffffc28
19:43 karolherbst: or is it the way how the handle mirrored stuff?
20:04 imirkin_: pitch values?
20:07 karolherbst: eg: GK104_COPY.DST_PITCH