00:02 karolherbst: ohh that is new
00:05 karolherbst: I got this after nouveau was loaded: https://gist.github.com/karolherbst/15cccdfa5dd9dc855a043eb51a2bade1
00:06 karolherbst: DROPPED_MMU_FAULT mhhh that doesn't sound so good
00:07 imirkin: those things get pretty heavy
00:07 imirkin: every so often you drop one
00:07 karolherbst: no idea, something while loading nouveua went wrong
00:08 imirkin: skeggsb: ping
00:08 skeggsb: imirkin: hey
00:08 imirkin: skeggsb: did you have any ideas for that guy with the div-by-0 in DP code?
00:08 karolherbst: well most likely my fault, cause I stresstested engine reclocking
00:09 imirkin: skeggsb: the field corresponding to link_nr == 0 on a warm boot -- it's weird.
00:10 imirkin: i made him file a bug with the various info
00:11 skeggsb: yeah i took a look, but haven't been able to do anything properly about it yet - have been working away from the office the last couple weeks. i'll attempt to fix a few things i know need fixing next week when i'm back, and see if they help him
00:11 imirkin: ah ok
00:11 imirkin: vacation?
00:11 imirkin: or just working remotely?
00:11 skeggsb: not exactly, working remotely due to a number of family things on
00:11 imirkin: ah ok
00:13 imirkin: even if manage to solve this issue, it'd probably still make sense to guard divisions on values gotten from hw
00:13 imirkin: i guess it's a lot of code to audit =/
00:14 skeggsb: well, it's not supposed to even be possible in this case - but there's a bug elsewhere which makes it possible
00:14 skeggsb: we program this value into the hw, it *should* always be valid
00:14 imirkin: the hw can always make it possible :)
01:11 imirkin: hakzsam: are you planning on working out the SM35 ISA bits for images?
07:14 hakzsam: imirkin, yep, I started yesterday
09:25 maquis196: Morning (or evening all). I was just curious about nouveau and supported hardware. Does it only support x86/arm?
09:26 maquis196: I ask because I have a PCI geforce 2 mx on a DEC Alpha, and was curious
09:57 RSpliet: maquis196: DEC, wow... but erm, there's an indication that nouveau works on some power platforms too provided 4K pages are used
09:58 maquis196: well it's a toy more then anything but I couldn't find anything in the FAQ, or documentation that says explicitly what platforms are supported, so figured it would be worth a go!
09:58 RSpliet: you can always try of course
09:59 maquis196: im running Gentoo and a recent version at that, thought I'd give it a go.
09:59 maquis196: Apr 6 19:43:41 excelsior kernel: module nouveau: Relocation (type 4) overflow vs __kmalloc
09:59 maquis196: ^C
09:59 maquis196: excelsior log # modprobe nouveau
09:59 maquis196: modprobe: ERROR: could not insert 'nouveau': Exec format error
09:59 maquis196: :)
10:02 RSpliet: maquis196: tried this patch: https://lists.freedesktop.org/archives/nouveau/2016-March/024272.html ?
10:03 RSpliet: unsure just how related it is, but it's the first thing that sprung to mind when your log entry mentioned kmalloc
10:04 maquis196: ill certainly give it a go when I get the chance, im hitting other problems with the NV driver as well. It seems modern xorg doesn't like the alpha platform much
10:08 RSpliet: it's difficult to motivate investing into supporting a platform whose backing company went bankrupt 10 years ago :-P
10:09 maquis196: haha I know, I quite agree. I was generally curious more than anything. Hell, I figured there was probably platform specific code in nouveau that would stop it. The idea of playing opengl stuff on a dec alpha was cool enough to give it a go!
10:09 maquis196: its dead, but still 533Mhz 64bit horsepower. Should count for something :)
10:10 RSpliet: I don't think there's a fundamental reason why it shouldn't work, but it's untested, hence I'd expect there be dragons!
10:10 maquis196: funny thing is though, if for interest/fun whatever and someone wanted to poke around on this box, id be happy to provide access.
10:11 maquis196: but i get stuff like - [ 14734.079] (EE) Failed to load /usr/lib/xorg/modules/drivers/nv_drv.so: /usr/lib/xorg/modules/drivers/nv_drv.so: undefined symbol: xf86WriteMmio8
10:11 maquis196: when trying to load MGA/NV on here (just swapped out the millenium, yay for NT4 compatibility list)
10:17 airlied: maquis196: i suspect 16k page tables and maybe some module size limit
10:27 maquis196: ah okay. Well I was hoping it might work out the box, would have been interesting. At this point mind, any driver working would be good
11:17 mike_papa: Hello. I get "aux channel not found", and "failed to initialise sync subsystem, -38" errors when trying to boot Ubuntu 15.04 installation on kvm VM with GPU passthrough (nVidia GTX970). X is not starting. Also screen is corrupted at the top (line of green-blue strips). Windows 8 installation iso boots ok. Any ideas what could be a problem? Seems like nouveau related.
11:18 Tom^: mike_papa: what kernel does ubuntu 15.04 use?
11:19 mike_papa: 3.19 as it stated on their page
11:20 Tom^: im not entirerly sure when 9xx series "non accelerated" support landed but 3.19 is quite old.
11:24 mike_papa: Ok. I'll try 15.10 with 4.2
11:34 mike_papa: Now I get no video at all. Actually this corrupted line appears for a moment, then video output goes down for a second, then goes back again with just black screen. Esc, changing ttys doesn't seem to work. Hard to say if guest freezes, or just not giving video.
11:34 mike_papa: GRUB menu looks fine. All happens after that.
12:04 karolherbst: gnurou: ohh you also have the gr issue
12:05 karolherbst: gnurou: well you could write into scratch registers inside the fuc code of the gr and see where something odd is happening (that's how I did it with the pmu)
12:05 karolherbst: but this can be kind of tricky
12:14 martm: karolherbst: would not you want to give a shot at fixing multithreading?
12:14 karolherbst: if I would add it to my todo list, I would maybe look into this by the end of the year and then give up, because I don't know enough about OpenGL to fix it
12:16 martm: karolherbst: no, you are way over too scared about this, really it is easy, i am occupied for months probably, karolherbst don't be scared about it, fermi kepler are very elegant cards
12:17 martm: it's quite easy, but i am in troubles here, really bad, i can not get myself together, if i do deal with stuff on graphics again, i loose a grip in my life
12:19 martm: karolherbst: i can handle that about the same time as you suggested, but i think i would prevail, it's just users could bit frustrated about that issue
12:25 martm: karolherbst: it's clear for me how to handle the scheduler, i delt with it months, but i am thinking about another detail also a performance stuff, how to exactly ensure that pusbuf contents get executed in round robin fashion that without bringing new cache entries before the old one have executed
12:25 RSpliet: karolherbst: threading might be worth sticking on the Trello page if you happen to be logged in
12:26 martm: karolherbst: i mean fixing the multthreaded issue is easy, but to do it with best performance i am always idealist
12:26 martm: needs a bit polishing
12:26 karolherbst: RSpliet: yeah, good point
12:26 karolherbst: RSpliet: under OpenGL bugs?
12:26 RSpliet: I'd say so
12:27 karolherbst: I just open a blank card named "Threading issues" somebody else could fill it with the needed information about this
12:27 RSpliet: I think you may point to apps like VirtualBox
12:28 karolherbst: anything else known to have troubles here?
12:29 martm: i think when you do even couple of memory fetches when it should not, it hits the perf bad
12:29 martm: this is why i am still thinking
12:33 martm: belive me i land to a solution in my brain, very quickly today or tomorrow i am thinking about it at the moment how to delegate the pushbuf contents to cache, so that they get executed continuously
13:06 martm: There seems to be multiple ways..the easiest is to block in gallium when cache is full, that is determined with a counter
13:07 martm: and after all that has been executed, unblock and execute again when the cache is full
13:12 martm: but while the ringbuffer from playlist allready executes, it updates on of the pointers right, it can allready unlock the cache for the first entries based of that pointer, so pushbuffers could kick in their stuff coninuously at the top of the stack
13:14 martm: the thing is that cache structure is probably a fifo, but reordering mechanism is based of lifo, i dunno how to connect those most effeciently yet
13:25 imirkin: karolherbst: also Warsow 2.0, although they apparently auto-disable threading when they detect nouveau
13:26 karolherbst: ahh okay
13:27 imirkin: also i've seen feral-ported games do it, like GRID Autosport
13:27 imirkin: although they don't do it as aggressively, and might not run into actual issues
13:30 martm: ah there is only one way that is compatible now that i think about it, because imagine that later commands would want to jump back in ringbuffer, and i allow the top of the stack to be wiped off of that entry
13:31 martm: then it would need to fetch that instruction again, anyways yeah i kinda locked one and only solution
13:37 martm: but still thinking, wether this blocking should be done, with fences or how the hell
13:39 martm: all pushbufs get the fence signal for instance when the first no_HASH cahce error is received
13:39 martm: then a shader executes that reorders the cahe and signals the playlist to execute
13:40 karolherbst: ... whats going on? Yesterday I read that there are some who wants to ditch the intel ddx in favor of modesetting and now they also ask this for nouveau
13:41 martm: karolherbst: one guy like showd imo it seemed on maxwell it was the only ddx that worked
13:41 martm: i.e modesetting
13:42 karolherbst: yeah right, but all gpus before that not
13:42 karolherbst: and some don't even have proper gl accell
13:42 karolherbst: and you really want to use glamor on modesetting
13:42 karolherbst: otherwise you don't want the modesetting ddx at all
13:44 martm: karolherbst: yeah, i think too, i mean i was not sure, i have not looked modesetting ddx, i thought it used glamor, but sounds like it is also possible to use it without
13:44 imirkin: karolherbst: just look at the xkcd link i referenced in my reply.
13:44 karolherbst: yeah I know
13:45 karolherbst: It would be really disappointing to ditch all those 2d accell functions, because in the end it has to decrease 3d perf, because the 3d engines are more occupied
13:45 karolherbst: and then
13:45 imirkin: it's the same engine.
13:46 karolherbst: even on intel?
13:46 imirkin: i meant on nvidia
13:46 imirkin: i assume so on intel too
13:46 imirkin: i mean... it's not like there are 30 different rasterizers
13:47 karolherbst: mhh right
13:48 martm: i belive so too that it's the same engine
13:48 karolherbst: but I thought the point of the sna stuff is to use some 2d stuff from the chip. Maybe I should look it up
13:48 imirkin: heh
13:48 imirkin: but how do you think the 2d stuff works?
13:49 karolherbst: I always that that at least on older GPUs there were dedicated 2d acceleration stuff
13:49 karolherbst: *thought
13:50 imirkin: yes, fixed function logic
13:50 RSpliet: karolherbst: in the arm world there is apparently xf86-video-fbturbo to use (at least) the sunxi 2D engine
13:50 imirkin: however i suspect that deep down inside, it just drives the same physical engine
13:50 karolherbst: yeah I am not sure for intel anyway
13:51 RSpliet: which is physically separate from the 3D mali GPU ;-)
13:51 martm: maybe on a framebuffer console yeah, some of the very primitive fills can be used with some 2d seperate functionality
13:51 imirkin: yeah, so there, they're separate cores
13:51 martm: but really sna and all the ddx should use 3d engine indeed
13:51 karolherbst: but would it makes sense to use glamor in the end with nouveau after all those issues are fixed?
13:59 martm: as i took couple of beers 4to be exact and intend to grab some more, i was sleeping on my back and thinking about the code, i think i have it cleared up, but will need one more day to do a sober recap
14:33 martm: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nouveau_channel.c?v=2.6.33
18:09 orbea: imirkin: When you have a chance can you look at this pcsx2 apitrace (32 bit apitrace needed)? http://ks392457.kimsufi.com/orbea/stuff/apitrace/PCSX2_Valkyrie_Profile_2.trace.xz After the cutscene is skipped and it gets to the actual game engine its unplayable because of intense graphical blur. I cant really test it on other hardware though so I'm not sure if its pcsx2 or nouveau.
19:22 imirkin_: orbea: this is what your trace looks like for me on SKL: http://i.imgur.com/BBQQ0WY.png
19:23 orbea: same was what I see
19:23 orbea: *same as what I see
19:23 imirkin_: ok
19:23 imirkin_: dunno if it's a nouveau issue then
19:23 imirkin_: i guess could be as a result of how the trace was recorded?
19:24 orbea: nah, it appears when playing the game normally without apitrace
19:24 imirkin_: right, i just mean i saw that on replaying the trace
19:24 imirkin_: and perhaps the way the game works, due to a nouveau bug, the things in the trace are wrong to begin with
19:24 orbea: hence whey I traced it, I can submit it to the pcsx2 devs too, but I figured it would be nice to see if it was obviously nouveau or not first
19:25 imirkin_: not _obviously_, but maybe
19:25 orbea: ah
19:25 imirkin_: could be a mesa-wide issue too
19:26 karolherbst: I would say it looks okay
19:26 karolherbst: was it a ps1 game?
19:26 orbea: ps2
19:26 karolherbst: mhh
19:26 orbea: the opening cutscenes look fine, just the in game doesn't
19:26 karolherbst: did they have a higher resolution than PAL/NTSC already?
19:27 karolherbst: ohh
19:27 imirkin_: PS2 was in the beginning of the digital TV era
19:27 karolherbst: yeah that's why I am unsure
19:27 karolherbst: I would say PAL/NTSC is the maximum
19:27 karolherbst: but I think it might be able to do a bit more
19:28 karolherbst: 480p/i
19:28 imirkin_: The PlayStation 2 may natively output video resolutions on SDTV and HDTV from 480i to 480p while other games, such as Gran Turismo 4 and Tourist Trophy are known to support up-scaled 1080i resolution
19:28 karolherbst: yeah, saw it
19:28 orbea: this game specifically asks if you want 16:9 or 4:1
19:28 karolherbst: that really doesn't matter
19:28 imirkin_: hopefully 4:3 :)
19:29 orbea: typo
19:29 karolherbst: it could be that that upscaler does something shitty
19:29 karolherbst: because downsized to 25% the screenshot looks okay
19:29 karolherbst: orbea: could you try to play at 1x resolution?
19:30 karolherbst: uhhh
19:30 orbea:looks to see if he can
19:30 karolherbst: with my hasewll this trace looks really odd
19:30 karolherbst: red an grenish
19:30 karolherbst: *greenish
19:31 imirkin_: hm, looks fine on SKL
19:31 karolherbst: maybe I just need to update mesa again
19:31 imirkin_: this was 11.2.0
19:31 karolherbst: software also looks like stupid stuff
19:32 imirkin_: you have to use a recent apitrace btw - otherwise glCopyImageSubData fails to retrace properly
19:32 karolherbst: ohhhh
19:32 karolherbst: right
19:32 karolherbst: system apitrace still at 6.1
19:32 orbea: its already set to 1.0 zoom, I tried 4:3 resolution in pcsx2, no diff
19:34 karolherbst: well it looks like a pcsx2 issue
19:37 orbea: i'll make an issue on their github page then to see if they have any ideas
19:38 karolherbst: oh I could try out nvidia
19:39 karolherbst: same with nvidia
19:39 orbea: cool, they probably would of asked that...
19:41 orbea: seems my intel laptop can play it even though I thought it wouldn't, its amazing far more broken there...
19:42 imirkin_: note that it could still be a thing where they downloaded some rendered texture, and then manipulate it on cpu, then reupload
19:42 imirkin_: that would make it so that the problem gets "hardcoded" into the trace
19:43 imirkin_: dunno if that's what's happening of course
19:43 imirkin_: but just pointing it out
19:44 orbea: I will mention that in my issue
19:44 orbea: thanks :)
19:51 karolherbst: orbea: you could try out nvidia though
19:52 orbea: https://github.com/PCSX2/pcsx2/issues/1282
19:52 orbea: i really dont want to install nvidia drivers honestly
19:52 orbea: they're far more pain to remove again than I care for
19:53 orbea: modding a ps2 to play valkyrie profile 2 undubbed sounds more fun :P
19:57 karolherbst: \o/
19:58 karolherbst: mupuf: done updating voltage: https://gist.github.com/karolherbst/47edb41976b99e10f7d8d4dde1d9c57e
20:01 karolherbst: now there might be a locking issue left, but this should be the easiest part now
20:02 karolherbst: Tom^: do you have some time?
20:03 mupuf: karolherbst: yeah!!!
20:04 karolherbst: now I have to check if the cstate change also works
20:04 karolherbst: but it should
20:04 karolherbst: the therm daemon just calls nvkm_clk_update
20:04 karolherbst: and update is smart to change pstate only when a different sptate is set than expected
20:04 karolherbst: same with cstates
20:04 karolherbst: currently it always tries to set the volt, because we can't know if the voltage might change
20:05 karolherbst: we could make volt a bit smarter here if we want though
20:05 karolherbst: so that nvkm_set_volt is a noop if the requested volt == set volt
20:06 karolherbst: yep, maybe your 660 is good for testing
20:11 karolherbst: oh well
20:11 karolherbst: mupuf: your 660 has no temperature depending voltage map entries ...
20:11 karolherbst: ohh it has actually for lower clocks
20:12 karolherbst: :O
20:12 karolherbst: I passed -c1
20:12 karolherbst: awesome
20:12 mupuf: it makes a lot of noise now :D
20:12 karolherbst: mupuf: https://gist.github.com/karolherbst/3d84cac1afe312287a9904cecd702f77
20:12 karolherbst: see the changed clock?
20:12 karolherbst: :D
20:12 mupuf: yeah!
20:13 karolherbst: the magic is all in here: https://github.com/karolherbst/nouveau/commit/4101059357b810006d6963e2a7280134cc66d65a
20:13 karolherbst: and some clk subdev cleanups/improvements
20:14 karolherbst: and having no pstate set is a noop always
20:16 karolherbst: I will cleanup the patches tomorrow and most likely send an updated series before the weekend
20:16 karolherbst: 31 patches ....
20:41 orbea: btw, the software rendered doesn't have that issue with teh game
20:43 imirkin_: orbea: what about LIBGL_ALWAYS_SOFTWARE=1 ?
20:47 orbea: game doesn't start
20:56 imirkin_: hehe
21:25 martm: imirkin: i don't quite know again, what is the best way to pause all the pushbuf channels, feels like you did not like this one nouveau_fence_wait!
21:27 martm: there seems to be several ways, but really , i don't really know i never tried any of them, i have not practiced with the code at all
21:34 martm: if this minor detail is cleared up, then the multithreading issue can almost be attempted, one should know the pfifo cache vm client address to execute the playlist, but there seems to be two ways to reorder it again
21:35 martm: the ringbuffer method pfifo method way, and shader way on fermi/kepler
22:00 martm: i dunno imirkin: has talked about like himself 3three or more different ways to do that, there is some base.pause too even in addition, from the logs it seems pushbuf execution can be also controlled in hw with a semaphore
22:01 karolherbst: SaveTheRobots: by the way, I fixed like a stupid bug on my branch and maybe it will work better now for you on your nvf1
22:23 martm: https://android.googlesource.com/kernel/mediatek/+/android-4.4.4_r3/drivers/gpu/drm/nouveau/nv50_fb.c
22:24 martm: it says there that pfifo subclients are pushbuf and semaphore, and the mentioned ccache which is pfifo cache it has subclients tic and tsc
22:25 martm: so there should not be a problem, but needs still some work
22:27 martm: since cache is a fifo in structure, we test when the last slot was written, and try to pause pusbufs, and reorder the playlists
23:04 mupuf: karolherbst, hakzsam: Hey, going to Germany tomorrow until monday. Need any GPU in reator?
23:12 karolherbst: not really
23:12 karolherbst: mupuf: but where are you heading to?
23:13 mupuf: Essen, mostly
23:13 mupuf: and Rheine
23:13 karolherbst: ohh there
23:14 karolherbst: have fun then
23:15 karolherbst: I only need to mess up my system until tomorrow, so I am good
23:16 martm: dunno is that 32-64kb pfifo cache enough to execute the stuff effeciently, what backing storage of the cache, says pre nv40 did not have that?
23:21 martm: for example, if ccache would be mapped to vm address space..it's said to be vmclient, and if i push an address to the cache..than i can access like two addresses as cache?
23:29 martm: yeah i belive that so it is, it's pretty neat
23:32 martm: sounds like when there is vm/mmu, one can play anyway with the cache as needed
23:46 hakzsam: mupuf, kepler1 and kepler2 are fine by me
23:54 Jayhost: imirkin I believe this was the output you were looking for http://hastebin.com/johogareza.pl