00:01ineedhelpfast: Help me please.
00:02ineedhelpfast: Attempting to play a game (Minecraft) with Nouveau drivers; the game is constantly crasing with the message java: pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed.
01:29kurobeats: howdy all, just wondering if OpenCL is far off? The reason I ask is I'm hoping to one day rid myself of the nvidia drivers but continue to do password cracking for my job
02:41mishehu: greetings, folks, I'm having some troubles with nouveau on an atom-ion system. I could only get video output in X, no fbcon, on 4.6.5, and on kernel 4.8.4, I'm getting nothing at all. running slackware64 14.2. All details here: http://shavedgoats.net/picture_library/tasrit-nouveau.txt
03:37mishehu: actually had a dns issue, you can also see the configs/details at http://kusit.com/picture_library/tasrit-nouveau.txt as well.
03:37mishehu: any help is appreciated
05:39saintdev: Is DisplayPort 1.2 MST supported for multiple monitors on Maxwell?
05:40saintdev: xrandr only shows one display, but everything does show up mirrored
05:41airlied: not yet
05:41aethe: hey goys
05:42saintdev: airlied: darn, thanks. Kind of figured that would be the answer
05:42aethe: I am getting a monitor out of range error on my monitor when trying to install via live usb
05:43aethe: happens with every distro i have tried
05:43aethe: the boot menu is ok and i select to install. it shows the text ok. after the text, my monitor says out of range
05:43aethe: gpu is gtx1060
05:44aethe: here is a forum thread that i replied to. my username is logboy.
06:56mishehu: well folks, nm, it at this time appears that my nvac was suffering from the problem outlined here: https://lists.freedesktop.org/archives/nouveau/2016-October/026242.html
06:56mishehu: I commented out that line, rebuild the module, and now I've got video output.
08:00karolherbst: aethe: we are very interessted in mmiotraces of your GPU ;)
08:20karolherbst: aethe: we really don't know yet how the pascall GPUs work in detail, so we need a lot of information
08:21karolherbst: aethe: would be awesome if you would create an mmiotrace : https://wiki.ubuntu.com/X/MMIOTracing
08:21karolherbst: also it would be nice to wait until the driver reclocks the card to full speed
09:25karolherbst: jo, will get a 4K display most likey, I could test with my testa on this one a little :O
09:25aethe: karolherbst, i will see what i can do
09:26karolherbst: aethe: would be really awesome, then I could take a look at reclocking, especially memory
09:35aethe: karolherbst, can i do the mmiotrace in windows?
09:35aethe: with some kind of emulator?
09:36karolherbst: doubt it
09:37aethe: well i ordered a dp cable (currently using dvi)
09:37aethe: not sure if that will even make a difference
09:37aethe: but if works i will do the mmiotrace
10:00aethe: karolherbst, what about virtualbox?
10:05karolherbst: because you can't let the vm access your gpu
10:05karolherbst: well, there are extensions though
10:06karolherbst: but you need a compatible CPU, motherboard and sometimes even GPU
10:06karolherbst: well, but mmiotrace is a kernel feature
10:06karolherbst: so you could also do it with a live cd
10:06karolherbst: and save the trace on a USB driver or something
10:07karolherbst: ohh, but nvidia isn't there
10:07karolherbst: aethe: okay, here is what you do
10:07aethe: well i cant even boot into a live cd
10:07karolherbst: aethe: install with nouveau.nomodeset=1 set
10:07karolherbst: or boot
10:07karolherbst: this basically disables nouveau
10:08karolherbst: so you get crappy firmware display
10:08karolherbst: and then you can install nvidia
12:16kwizart: question about recent nvidia hw, can we expect them to be accelerated by llvmpipe, so it's possible to use under an usual GNOME3 desktop and others ? or is there too much missing ?
12:16Calinou: kwizart: llvmpipe is CPU-only
12:16Calinou: also, it's too slow to use GNOME at 60 FPS
12:17Calinou: and obviously gaming, WebGL, video are a no-go
12:18kwizart: okay, but I expect I've run llvmpire on jetson tk1 gnome, so as soon as there is enought to drive a display all needed function will be there to run the gnome application
12:19kwizart: that unless you are running llvmpipe on old gen atom or older
12:19kwizart: if one is using a current CPU with a pascal GPU, can we expect it should work ?
12:20Calinou: no, not even an i7-6700K can drive LLVMpipe smoothly
12:50karolherbst: kwizart: why not using actual hw accell on the jetson?
12:50karolherbst: the jetson should be way too slow for llvmpipe to use anything useful with gnome afaik
12:51kwizart: hum that was an example, I think the first step was to have llvmpipe working, but I stil wonder if it can work without patches from xorg-server and mesa ?
12:52karolherbst: kwizart: you have to wait until nvidia unscrews the user having maxwell2 or newer GPUs, for now
12:52kwizart: even maxwell2 ?
12:52karolherbst: kwizart: it can't cause X can't handle that and I doubt anybody puts enough energy into that, except embedded device devs
12:52karolherbst: kwizart: well, it is good enough for maxwell2, but your are stuck at lowest clocks
12:53karolherbst: kwizart: the etnaviv devs are working on that, I think
12:53kwizart: is this issue easier with wayland ?
12:54kwizart: I mean the nouveau for gpu vs tegra devices for display ?
12:55karolherbst: uhhh, no idea
12:55karolherbst: I would expect it to be easier
12:56karolherbst: I am sure you could start weston with DRI_PRIME=1 weston
12:56karolherbst: never tried it though
12:56kwizart: at least there are patches needed, I don't know their upstream status: https://github.com/Gnurou/weston/commits/gk20a
12:56karolherbst: mupuf might know more
12:57mupuf: you need patches if you want to get any desktop environment on the jetson
12:58mupuf: kwizart: the patches are not upstream, neither for modesetting (X) or for weston
13:02karolherbst: mupuf: I guess nobody cares enough to actualy work on this? (except maybe us and etnaviv)
13:02mupuf: yeah, sort of
13:03mupuf: it is linked to gralloc and the big wayland discussion from xdc
13:05karolherbst: I hope somebody will come up with something actually useful
18:29orbea: This looks like a memory leak in nouveau? Tested by opening the latest RetroArch master and then selecting exit in the menu. http://dpaste.com/37EPCTV Full valgrind log - http://pastebin.com/542b7x50 Somewhat connected RetroArch issue - https://github.com/libretro/RetroArch/issues/3857
18:31imirkin_: orbea: that leak is expected. not an issue.
18:31orbea: alright, that is good to know
18:31imirkin_: it's pretty minimal
18:42mupuf: imirkin_: hmm, seems like the problem with the copy class failing to be allocated was due to my version of nouveau
18:43mupuf: using a vanilla 4.8 seems to work well
18:43mupuf: although, I did also remove one gpu, so let me try this
18:43imirkin_: ah ok
18:43mupuf: I may be affected by this bug: https://bugs.freedesktop.org/show_bug.cgi?id=96937
18:44imirkin_: ah yeah, can't help you with that one :p
18:46mupuf: nah, may be something wrong with the way I compile my kernel then
18:46mupuf: it complaining about a missing vga arbiter
18:46mupuf: anyway, let's actually run rendercheck
18:48imirkin_: mupuf: there are some fails but they also happen on GK208
18:48imirkin_: and pretty sure other GPUs as well
18:49mupuf: ok, cool, I will compare to modesetting
18:49imirkin_: modesetting passes (with an updated rendercheck)
18:49imirkin_: i looked into why triangles was failing, and i get it
18:49imirkin_: i just don't feel liek fixing it
18:49imirkin_: updated as in - git head
18:50mupuf: ah, ok
18:50imirkin_: but that test fails on every nouveau gen
18:50karolherbst: hakzsam_: want me to post a new patch for that cse thing?
18:50imirkin_: including NV34
18:50karolherbst: hakzsam_: results: https://gist.github.com/karolherbst/6c9f7797578895da41ea18b95de53903
18:50mupuf: I will do this and apply my patch to know which tests fail exactly
18:50imirkin_: mupuf: wait, what's your patch?
18:51hakzsam_: karolherbst: no, it's fine, I will amend the commit
18:51karolherbst: hakzsam_: thanks
18:51mupuf:doesn't like that only groups are reported as failure
18:51hakzsam_: karolherbst: we have a ton of shaders now :)
18:52karolherbst: hakzsam_: yeah, I noticed
18:52mupuf: imirkin_: if you can make sense of Eric's reason not to merge the patch, I would love to hear it
18:52karolherbst: hakzsam_: I started a list to note which shaders were generated with the new stuff
18:52hakzsam_: yeah, I saw that file
18:53hakzsam_: karolherbst: I'm going to push your cse patch
18:53karolherbst: hakzsam_: mareko looked into the SSO mixing optimisation thing (dropping inputs/outputs) and said that those dx9 eon games actually need this to get more perf
18:54hakzsam_: yep, but imirkin_ is working on this I think
18:54karolherbst: ohh does he?
18:55karolherbst: I thought he was looking into those constant outputs
18:56hakzsam_: ah, probably not the same thing actually
18:57karolherbst: what I mean is, dropping outputs/inputs for real and DCE all the stuff
18:57imirkin_: hakzsam_: no, i'm not working on it.
18:58hakzsam_: karolherbst: pushed
18:58karolherbst: allthough, shouldn't be too hard, right? Except when inputs get DCEed away later on
18:58karolherbst: hakzsam_: thanks
18:59karolherbst: hakzsam_: you also wanted to look at the postraconstfolding thing again
18:59hakzsam_: sure :)
19:02mupuf: imirkin_: looks fine though
19:03mupuf: I tested some gtk apps, since they are the ones that actually use the GPU
19:03mupuf: and EXA
19:03imirkin_: mupuf: awesome
19:03imirkin_: i'll push then
19:03mupuf: go for it :)
19:03imirkin_: can you confirm that the copy class got allocated properly?
19:03imirkin_: (in your xorg logs)
19:05mupuf: still there
19:05karolherbst: hakzsam_: could you test something?
19:06mupuf: 4.8.4-1-ARCH, X.Org X Server 1.18.4
19:06hakzsam_: karolherbst: depends what you want me to test? :)
19:06karolherbst: good stuff
19:06karolherbst: improves f1
19:07hakzsam_: imirkin_: I didn't test EXA on my gm107 though, but whatever
19:07karolherbst: not much though: total instructions in shared programs : 298995 -> 298956 (-0.01%)
19:07imirkin_: hakzsam_: no worries. i tested it a tiny bit.
19:07hakzsam_: karolherbst: ahah, F1 still crashes :)
19:07karolherbst: k, so no test
19:07imirkin_: hakzsam_: feel free to play with the sched codes
19:07karolherbst: I was thinking about your late algebraic opt again and your bb check
19:07hakzsam_: imirkin_: sure
19:07karolherbst: seems like removing that checks improves stuff
19:08hakzsam_: without breaking anything?
19:08karolherbst: why should it break anything?
19:08karolherbst: you can have also silly things like BB1: insta BB:2 /*empty*/ BB:3 instb
19:09karolherbst: it's SSA, you can usually ignore the BB bounds
19:09karolherbst: gpr pressure may increase though
19:09hakzsam_: yeah okay, feel free to improve it :)
19:09karolherbst: you have to look at dx9 eon shaders more
19:09karolherbst: some have like 600 instructions and 200 BBs
19:09karolherbst: 80% empty ones
19:10hakzsam_: any games in particular?
19:10karolherbst: all dx9 based eon games
19:10karolherbst: they just do crazy things
19:11hakzsam_: but like which game?
19:11hakzsam_: do we have shaders in our shader-db?
19:11karolherbst: I think I saw it in the saints row shaders
19:11karolherbst: maybe also bioshock, allthough it isn'T dx9 based
19:11hakzsam_: I have never look at those yet
19:12hakzsam_: I tried to improve perf with elemental demo today, seems like I have +6% on fermi/kepler
19:12hakzsam_: I need to check on gm107
19:12karolherbst: good example
19:12karolherbst: 801 instuctions, 270BBs
19:13karolherbst: check out the tgsi
19:14hakzsam_: ah actually I already saw something like that
19:14hakzsam_: but I don't remember which game
19:14karolherbst: most likly a eon based one :D
19:14hakzsam_: probably :)
19:14hakzsam_: yeah, I'm sure we can do something much better there
19:14karolherbst: one reason I usually don't care about the BB boundaries
19:15karolherbst: except I see that the pass may improve gpr pressure a lot
19:15karolherbst: yeah, I tried
19:15karolherbst: doesn't make a difference though
19:15karolherbst: not much
19:15karolherbst: and my pass for this was hell
19:15karolherbst: ;) https://github.com/karolherbst/mesa/commit/d9c247e643a1a65a23fe59626db136e928bc3218
19:16karolherbst: all the bad things you never want to do
19:21karolherbst: uhm the d3d9 mesa repository is gone? :/
19:22imirkin_: karolherbst: https://github.com/ixit/mesa-3d
19:22karolherbst: I meant the one with patches for mesa master
19:23imirkin_: not sure what you mean
19:23karolherbst: there was a repository which had a patch which could be applied on mesa master for recent changes
19:23karolherbst: but maybe the want to push stuff more often now
19:23imirkin_: not aware of such a thing
19:23imirkin_: either way, probably a question fro #d3d9
19:28mupuf: https://avatars2.githubusercontent.com/u/5074954?v=3&s=200 <-- AHAH
19:33RSpliet: mupuf: you hadn't seen that before?
19:34RSpliet: karolherbst: do you need another pass of DeadCodeElim before _and_ after EmptyBranchElim?
19:35karolherbst: RSpliet: the pass is pointless. it is super complicated and reduces instructions count by 0.01%
19:35karolherbst: and it even breaks stuff
19:35karolherbst: a different approach is needed anyway, so I don't really care about this patch
19:35karolherbst: mupuf: you are slow
19:36mupuf: RSpliet: nope :D
19:36mupuf: I never go to the organization
19:36karolherbst: mwk asked for it, so I made it
19:36mupuf: ah ah
19:41mwk: oh yes, it perfectly matches the specification
19:41karolherbst: which nobody believes
19:43AmarokNelg: I have a nvidia gtx 750ti which I'm using with the nouveau driver on debian jessie, and sometimes the driver seems to crash with a message gpu lockup switching to software fbcon
19:45AmarokNelg: Oct 22 17:34:11 rousdower kernel: [13072.311845] nouveau E[ DRM] GPU lockup - switching to software fbcon
19:46imirkin_: AmarokNelg: what does it say before that?
19:47AmarokNelg: on that time, almost 30 minutes before that: Oct 22 17:09:06 rousdower kernel: [11568.823339] ieee80211 phy0: rt2x00usb_watchdog_tx_dma: Warning - TX queue 2 DMA timed out, invoke forced forced reset
19:47imirkin_: AmarokNelg: huh, so no messages from nouveau warning of impending death?
19:49AmarokNelg: I see other things probably from system startup related to nouveau
19:50AmarokNelg: here, I'll do this:
19:51AmarokNelg: http://pastebin.com/j8qNis7N - messages probably from system startup
19:51AmarokNelg: http://pastebin.com/yEYvbp3t - crash nouveau messages
19:52imirkin_: huh. so it just kinda hangs.
19:52imirkin_: sorry, no help from me =/
19:54mupuf: os_schedule: Attempted to yield the CPU while in atomic or interrupt context --> oopsie :D
19:54mupuf: that's from nvidia
19:55mupuf: I am trying again to figure out what to do with these loud fans
19:55mupuf: I thought I had an idea... but it did not pan out, so trying again
19:55imirkin_: disconnect them?
20:51mupuf: ok, give up again, I see nothing in the bios that could explain why suddenly, we need to set the duty between 0 and 0xd instead of 0 and $div like all the others
20:51mupuf: this makes absolutely no sense at all
20:51karolherbst: mupuf: related to what?
20:51karolherbst: ohh fans
20:52karolherbst: mupuf: is the vbios somewhere?
20:52mupuf: yeah, just pushed it
20:53mupuf:wanted to check out the table at offset 0x50
20:53mupuf: but it is not present
20:53karolherbst: I had the same idea
20:53karolherbst: but yeah, fancy stuff is kepler+
20:53karolherbst: that voltage map table
20:54karolherbst: seriously, that is a tesla faking to be a fermi card
20:54mupuf: ah ah, possible
20:55karolherbst: any clue what "0x49" is in the temperature table?
20:55mupuf: well, it has been there forever
20:56mupuf: still don't know what it means
20:56karolherbst: that vbios looks like crap somehow...
20:57karolherbst: I am sure my reclocking patches will crash with that one
20:57mupuf: the blob writes to PWM_VID_DIV and PWM_VID_DUTY
20:58karolherbst: what is the duty?
20:59mupuf: I reboot the machine
21:00karolherbst: mupuf: maybe something is inside the 0x18 or 0x24 table
21:00karolherbst: but somehow I doubt this
21:00mupuf: have you checked the table 0x24?
21:00karolherbst: let me guess, empty?
21:00mupuf: header size is 0x3 :D
21:01karolherbst: 0x18 looks maybe like something
21:01karolherbst: mhh 01 01 00 0c 00 40 00 00 c4 09 8c 00 d5 ff 0f 0f
21:01mupuf: PTHERM.PWM_VID_DIV => 0x360
21:01karolherbst: and duty is between 0x0 and 0xd?
21:06karolherbst: mupuf: no clue, it doesn't make any sense, 0x18 table is my best bet, otherwise the tempterature table
21:48mykon: how to turn on power management in nouveau?
21:48mykon: my fans are running 100% speed all the time
21:48mupuf: well well, this is what I am checking how to fix right now
21:48imirkin_: mykon: as long as you don't explicitly turn it off, it should be basically on
21:48mupuf: this is a bug
21:49mupuf: or a missing feature
21:49mupuf: karol made me look at a table in the vbios and ... guess what ... he was right
21:49mykon: still on 4.X series?
21:49imirkin_: mupuf: been known to happen...
21:49imirkin_: mykon: which GPU do you have?
21:49mykon: I actually don't want to 'turn off' completely
21:50mupuf: I have found what looks a way to specify in the vbios a scaling factor for the PWM controller
21:50mupuf: still makes no sense why anyone would need this, but it seems like it is needed
21:50imirkin_: mykon: interesting. not aware of any gk104's with issues.
21:52mupuf: well, seems like this table is gonna be fun, it has a different mode on gk104
21:52imirkin_: mykon: send mupuf your vbios
21:52imirkin_: mykon: cat /sys/kernel/debug/dri/0/vbios.rom > /tmp/gk104-vbios.rom
21:52mupuf: imirkin_: found one nve4 that needs it
21:52mupuf: so... it is a wide-spread problem
21:53imirkin_: mupuf: can you check if my GK208 is affected?
21:53imirkin_: its fans don't work either
21:53mykon: it does make sense, not having to hear the fans at full blast for one when doing absolutely nothing.
21:53imirkin_: mupuf: https://people.freedesktop.org/~imirkin/traces/gk208/gk208-vbios.rom -- i *think* that's mine
21:53imirkin_: mupuf: er no. 2015. nevermind.
21:54mupuf: imirkin_: yes, it is impacted
21:55imirkin_: mupuf: i'll put up my real one at some point
21:55mupuf: imirkin_: I used the one from the vbios repo
21:57imirkin_: mupuf: have i uploaded one there?
21:57imirkin_: perhaps you did for me :)
21:57imirkin_: what about my GM107? https://people.freedesktop.org/~imirkin/traces/gm107-vbios.rom
21:57mupuf: Martin Peres 2015-07-19
21:58mupuf: already there too, but I do not have your strap peek
21:58imirkin_: that sounds wrong. i didn't get the GK208 until like ... march
23:18mishehu: hi folks. I'm trying to playback video on my atom-ion board (mcp79/mcp7a) , and vlc freezes up all of X until it's killed. Might anybody have any thoughts/ideas how to resolve this issue? http://pastebin.ca/3732882
23:50imirkin: mupuf: ok, here's my *actual* vbios for the gk208: https://people.freedesktop.org/~imirkin/traces/gk208b-vbios.rom
23:51mupuf: imirkin_: care to give us the strap peek too?
23:51mupuf: nvapeek 101000
23:52imirkin: mupuf: GM107: 804000aa, GK208B: 80405c86
23:53mishehu: nouveau 0000:03:00.0: DRM: GPU lockup - switching to software fbcon
23:53mishehu: that doesn't look good.
23:53imirkin: mishehu: no, not good at all.
23:54mishehu: imirkin: it's related to my trouble at http://pastebin.ca/3732882
23:54imirkin: mishehu: quite likely.
23:54imirkin: mishehu: fwiw i only ever tested vdpau with mplayer.
23:55imirkin: mupuf: anything else you want me to check?
23:55mupuf: imirkin_: that should be enough for the vbios repo
23:55imirkin: mupuf: k
23:56mishehu: imirkin: I've had vpdau working with vlc before, no problem. even this exact build. I'm fairly sure the issue is on the nouveau side of things. I had to do this code change just to even get video output in the first place --> https://lists.freedesktop.org/archives/nouveau/2016-October/026242.html
23:56imirkin: mishehu: my point is -- i've only ever tested nouveau vdpau with mplayer.
23:56imirkin: or are you saying it used to work fine on this box?
23:57imirkin: if so, figure out what changed.
23:57imirkin: mesa 12.0 is likely to have pretty buggy vdpau support for nouveau, try mesa 11.2
23:57mishehu: imirkin: I've had this build of vlc work with other systems with other chipsets supported by nouvea on earlier kernels.
23:57mishehu: mesa-11.2.2-x86_64-1 on this box
23:58imirkin: well, so what changed?
23:58mishehu: whatever it is it seems specific to the mcp79/mcp7a.
23:58imirkin: mishehu: doubtful.
23:58imirkin: skeggsb: btw -- another user having trouble with that workaround on NVAC.
23:58mishehu: I don't see why that's not at all feasible
23:59imirkin: mishehu: you don't have enough information to say one way or another.
23:59mishehu:points to the link above that he had to implement the change for, even one stupid line of code, just to get video output period.
23:59imirkin: mishehu: yeah, that was a very recent change that went into kernel 4.8, based on information from nvidia.
23:59imirkin: and has *nothing* to do with vdpau