01:09 gnurou: pmoreau: ok, I realized that my kernel branch had support for gm206, gm204... but not gm200 >_<
01:10 gnurou: pmoreau: just tried to run it on a gm200 myself
01:31 gnurou: pmoreau: ok, that should work now - please update the secboot branch from my nouveau *and* my linux-firmware (just pushed the final firmware!) repos, and things should work much better
01:31 gnurou: pmoreau: sorry for letting that go and wasting your time :(
01:47 pmoreau: gnurou: Nah, don't worry :-) I was still happy being able to modeset it.
01:48 gnurou: well now you should have GLamor working too
01:50 pmoreau: I'll be able to test hakzsam's stuff :-)
01:51 hakzsam: cool
02:37 Fakeboost: Hello, does anyone know a good xrandr tutorial?
03:18 RSpliet: gnurou: are there any registers that the fecs/gpccs falcon engines can't read?
03:20 mwk: RSpliet: MMIO registers? yes
03:20 gnurou: RSpliet: yes, some registers are reserved for pmu in secure mode
03:21 RSpliet: mwk: MMIO registers yes
03:21 RSpliet: gnurou: on Kepler as well?
03:21 mwk: RSpliet: PGRAPH is hooked into the register access are at a different level than PCI host
03:22 mwk: it can't access things that don't go through the ring, like PFIFO registers
03:22 gnurou: RSpliet: probably, yes
03:22 mwk: or PBUS
03:23 RSpliet: mwk: ptimer by any chance?
03:24 mwk: yep
03:24 mwk: that too
03:26 RSpliet: mwk: do you have documentation of what registers I can access from these falcons?
03:27 mwk: RSpliet: as a workaround, you can just aim at some falcon's timer registers, they mirror PTIMER time
03:27 mwk: RSpliet: I used to have it...
03:27 mwk: basically: avoid PFIFO, PMC, PBUS, PTIMER
03:28 RSpliet: mwk: wait, I can access the PMUs timer from FECS? well, that'll do for now I guess
03:29 mwk: ugh
03:29 mwk: I do...
03:29 mwk: see envytools/docs/hw/mmio.rst
03:29 mwk: the *rst*, the information is lost on compilation to html
03:29 mwk: I screwed something up
03:30 mwk: any line with ROOT == won't work, any other line (including missing) == will work
03:30 RSpliet: ah great, thanks!
03:30 karolherbst: gnurou: by any chance, are there any sort of power sensors on those tegras, which aren't already hooked up by the non nouveau code?
03:35 karolherbst: mupuf: any idea how I can check if the expected device is on the i2c bus at the expected address? Because there might be also something else...
03:57 mupuf: karolherbst: sure
03:57 mupuf: there is usually a device id at address 0xff
03:57 mupuf: or, in the case of TI, they have TI written from address 0xfe
03:57 mupuf: check the datasheets
03:57 karolherbst: address or reg?
03:58 mupuf: well, I see i2c as MMIO
03:58 mupuf: call it however you like
03:58 karolherbst: mhh I doubt that will work this way, it seems like i2c has another level of indirection
03:58 mupuf: ?
03:58 mupuf: bus, bus_addr, reg/addr
03:59 karolherbst: well you poke a reg at a specific address on a i2c bus
03:59 karolherbst: ahhh
03:59 karolherbst: so you mean reg/addr
03:59 mupuf: yes
03:59 karolherbst: k
03:59 karolherbst: okay, good to know
04:00 mupuf: it is a per-vendor thing, so you need to check all the datasheets
04:00 karolherbst: what happens when there is no device at the given bus_addr? the i2c read function returns -Esomething?
04:00 mupuf: EIO
04:00 karolherbst: k
04:00 karolherbst: also what I was wondering about, the nouveau i2c read functions might be a bit tricky to deal with :/
04:01 mupuf: how so?
04:01 karolherbst: it is okay though, but the devices can also return negative values
04:01 mupuf: oh
04:01 mupuf: love and joy :D
04:01 karolherbst: it's okay though because we only read up to 16 bit, but the return type is int
04:01 karolherbst: so it's okayish
04:01 karolherbst: but ugly
04:01 mupuf: want to make signed version of the read/writes?
04:01 mupuf: that would be the cleanest
04:01 karolherbst: you have to deal with the shifts anyway of the device
04:02 karolherbst: they are signed already
04:02 pmoreau: gnurou: Sorry, still no luck.
04:02 karolherbst: it's just that an error would be 0xffffffef or something and the returned negative value from the i2c device 0x0000ffef
04:03 karolherbst: the former is an error the latter none
04:03 karolherbst: and imagine somebody does this: s16 = nv_rd16i2cr(...)
04:04 pmoreau: gnurou: Plus, if I have both my 2560x1440 (over DP) screen + 1920x1200 (over DVI-I) plugged at the same time before loading Nouveau, I just get blackscreen after Nouveau loaded but the computer doesn't hang.
04:05 pmoreau: gnurou: Having just the 1920x1200 connected while loading Nouveau, and then, once Nouveau is loaded, plug the 2560x1440 one: that works fine.
04:11 vita_cell: karolherbst what do you think about MSI GT720 2GB GDDR5
04:11 karolherbst: slower than any recent intel hd gpu
04:11 karolherbst: wait
04:11 karolherbst: GT720 with gddr5?
04:12 karolherbst: what a waste of hardware
04:12 vita_cell: yees
04:12 karolherbst: there is no gt720 with gddr5
04:12 vita_cell: I want some gpu for reclock but with passive cooling
04:12 karolherbst: all gpus with passice cooling are crappy
04:13 vita_cell: thanks
04:13 karolherbst: there is a gddr5 variant of the gt 730 though
04:13 vita_cell: it is for core2duo E8500
04:13 karolherbst: mhh
04:14 vita_cell: I dont want a powerful GPU for bottleneck
04:15 karolherbst: no idea then, it's your choice in the end, but even with a slow cpu a mid eng gpu might be better than something really low end
04:15 karolherbst: depends on waht you what to do though
04:15 karolherbst: it should be kepler anyway if you want something recent
04:15 karolherbst: doesn't matter which kepler though, all should be good (with some patches)
04:16 vita_cell: 740 with ddr3?
04:17 karolherbst: try to get a gddr5 one if possible
04:17 karolherbst: the difference is really noticable in most workloads
04:18 karolherbst: and the bandwidth is usually three times higher
04:18 karolherbst: or more
04:18 vita_cell: MSI GT720 2GB GDDR5 would be better that 740 with ddr3
04:18 vita_cell: I think
04:18 karolherbst: depends on the application in this case
04:18 karolherbst: but where did you find a gddr5 720?
04:19 karolherbst: ohh even nvidia says there is one :O
04:19 vita_cell: yes, I tested gtx650 with only core reclocked and then with corepmemory reclocked
04:19 vita_cell: http://www.ebay.es/itm/272134050468?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT
04:19 karolherbst: that's way too expensive though :D
04:19 vita_cell: I think that it is the only with gddr5
04:20 vita_cell: I want it for very very quiet computer
04:20 vita_cell: I don't want furnance
04:21 karolherbst: 46€ for a gddr5 720 would be goot
04:21 vita_cell: this is why I added a very big CPU cooler on gtx770
04:22 karolherbst: mhh, I doubt that will work as good though
04:22 vita_cell: I am living in Spain, here is everything expensive, when I try to buy something cheaper I must to pay expensive shipping
04:23 karolherbst: k, then you are on your own :p
04:23 karolherbst: I can just say every kepler would be good, but gddr5 ones are prefered
04:23 vita_cell: karolherbst you said that maxweel 1g can be reclocked core
04:24 karolherbst: yeah, but that still gives you shitty performance
04:24 vita_cell: but, does it need signen non-free firmware?
04:24 vita_cell: signed non-free firmware
04:24 karolherbst: no, only gen2 maxwell needs that
04:25 vita_cell: ohhhh, 1g maxwell works like kepler, without non-free firmware
04:25 vita_cell: how I know what is 2g?
04:25 pmoreau: gnurou: Here are the dmesg: https://phabricator.pmoreau.org/P88 (with only one screen) and https://phabricator.pmoreau.org/P89 (with both screens plugged)
04:27 karolherbst: vita_cell: GM1xx is gen1, but there is no memory reclocking, so you get way worse performance than with a kepler one with nouveau
04:28 vita_cell: yes I know
04:29 vita_cell: I think that you can not know when memory reclock will be finiched
04:33 vita_cell: karolherbst 750ti palit passive, this is maxwell g1
04:34 vita_cell: if someday it will get reclocked would be a nice option
04:43 karolherbst: mupuf: seems like it is 0xfe (vendor id) and 0xff (device id)
04:44 mupuf: karolherbst: ah, right, it is 16bits reads
04:44 mupuf: 0xfe contains "TI"
04:44 karolherbst: ohhh that fits
04:44 mupuf: and 0xff contains 3221 or whatever other device id
04:44 karolherbst: 0x5449
04:44 karolherbst: and ff is 0x3220
04:44 mupuf: right, yeah
04:44 karolherbst: smart
04:45 gnurou: pmoreau: I don't know about the display issue, but for rendering I see no problem with you dmesg
04:45 mupuf: karolherbst: so, you can write your validaiton function now :)
04:45 karolherbst: mhhh
04:45 gnurou: pmoreau: assuming that you have switched to kmscon and that secure boot ran, this looks ok
04:45 karolherbst: thing is, for the 219 it isn't in the overview table stated :/
04:46 karolherbst: neither for the 209
04:46 karolherbst: maybe I find it somewhere else in the docs
04:46 mupuf: probably
04:46 gnurou: adding a printk into the secure boot code to make sure it runs might be helpful though... we already made that mistake once
04:48 gnurou: pmoreau: like in gm200_secboot_run_hs_blob
04:49 gnurou: if this function is called and the kernel does not complain, then secure boot is ok
04:50 gnurou: its call is delayed until you make use of GR, so you will have to run e.g. kmscube if you are not using kmscon
04:50 gnurou: (and even if you do, please try kmscube to make sure)
04:53 karolherbst: mupuf: can you plug in the nvc8 again?
05:01 pmoreau_: gnurou: Oh, I would need to run kmscube before loading X? Ok, I'll try that and put a printk.
05:04 mupuf: karolherbst: I will :)
05:07 karolherbst: thanks a lot
05:26 gnurou: pmoreau_: no, you don't need to, but kmscube is lighter and more to the point
05:27 pmoreau_: Ok, so just to test things
05:27 pmoreau_: But then, if KMS works, I "should" get accel with X?
05:27 pmoreau_: s/KMS/kmscube
05:30 gnurou: yup
05:41 upbeta: I got this error trying to install manjaro latest 64bit https://www.youtube.com/watch?v=ZWr1MdwoIcE
05:42 upbeta: someone from the channel advised me to ask from the community.. is this normal?
05:45 karolherbst: upbeta: I guess you have two gpus... can you check if there are any boot parameters set? and what kernel are you using there?
05:46 karolherbst: the resolution is unusually high, at least the font size is pretty big :/
05:47 upbeta: thanks for the quick response <karolherbst>
05:47 upbeta: where is should I see that gpus?
05:48 karolherbst: is this a laptop?
05:48 upbeta: yes.. the new dell xps15
05:48 upbeta: I am inside the bios.. and currently checking for "gpus"
05:48 karolherbst: k, so it most likely has an intel gpu and a nvidia one. Despite these errors, it should boot fine though
05:49 upbeta: its not booting up.. and as per the error.. it gets stuck (tried waiting for 30mins)
05:49 karolherbst: mhh okay
05:50 upbeta: under the bios system configuration the only thing I can relate the nvidia and intel is under Miscellaneous Devices (which has option for Enable Media Card)
05:51 karolherbst: upbeta: can you boot with nouveau.blacklist=yes ?
05:51 karolherbst: it is an grub option
05:51 karolherbst: or is it a linux option? :/ not quite sure
05:52 karolherbst: mhh
05:52 RSpliet: it's a kernel parameter
05:52 karolherbst: k
05:52 karolherbst: upbeta: well you don't need the nvidia card for isntalling anyway
05:52 RSpliet: well... blacklist=yes not sure, but nouveau.modeset=0 should do the trick
05:52 karolherbst: RSpliet: yeah, there is something blacklist related on the web, but I never saw it
05:52 karolherbst: maybe it is some global option for all modules
05:53 karolherbst: upbeta: anyway, you could disable the "Media Card" for now and install it
05:53 karolherbst: then update everything and enable it again
05:53 karolherbst: and then you can come back if you have other issues
05:54 upbeta: ok.. let me try that (hold on guys) :)
05:54 karolherbst: upbeta: did you fetched the newest installation image?
05:54 karolherbst: *fetch
05:55 upbeta: yes.. I am using a usb boot for this installation
05:55 karolherbst: k
05:56 pmoreau_: karolherbst: Isn't it more like `modprobe.blacklist=nouveau`?
05:56 karolherbst: pmoreau_: could be, but maybe that's only for modprobe
05:57 pmoreau_: Could well be, indeed. I remember using something like `rdblacklist=nouveau` (and IIRC it used to work), but it doesn't work any longer.
05:59 karolherbst: mupuf: "i2c i2c-11: sendbytes: NAK bailout." fun :D
06:00 upbeta: I tried disabling the option and its still booting with the same error
06:01 karolherbst: mupuf: I get those messages reading 0xff and 0xfe whenever I removed nouveau without turning the gpu off
06:01 karolherbst: upbeta: now that's unexpected
06:01 karolherbst: upbeta: try nouveau.modeset=0 then
06:02 upbeta: I cannot get to grub..
06:02 upbeta: it just stuck on the error..
06:03 karolherbst: well grub runs before the kernel
06:03 karolherbst: and the boot option you get is grub
06:03 karolherbst: or
06:03 karolherbst: maybe it isn't
06:03 karolherbst: maybe it is an uefi boot loader
06:03 karolherbst: no clue what manjaro uses
06:03 upbeta: ok.. so you mean I should be select the option for "shell 86_64 V1"
06:04 karolherbst: no idea
06:04 karolherbst: ohh you enabled legacy boot
06:04 karolherbst: then it may be indeed grub
06:04 karolherbst: though
06:05 karolherbst: you are most of the time better of with a disabled legacy boot
06:05 upbeta: yep.. legacy boot is disabled.. which gives me 4 option
06:06 upbeta: UEFI Shell 86_64 V1 is where I am at
06:06 karolherbst: I used to know how to execute the kernel in the uefi shell :/
06:08 karolherbst: upbeta: but I am sure you want to use v2
06:08 upbeta: ok.. one sec.. let me try V2
06:08 karolherbst: but
06:09 karolherbst: either way
06:09 karolherbst: you should not get the nouveau errors
06:09 karolherbst: when starting the efi shells
06:13 upbeta: here is what I see on UEFI shell V2 http://imgur.com/4jGc1ZQ
06:14 karolherbst: now you have to find the linux kernel file :D
06:14 karolherbst: ohh wait
06:14 karolherbst: maybe you can't execute it, because it has no efi stub support...
06:14 karolherbst: what a mess
06:16 upbeta: how should I resolved this? I got stuck with this issue.. and really need my laptop to work.. OT for more that 4 hours now :(
06:16 karolherbst: yeah no idea. You should search in the installation documentation where you could add some boot parameters to the kernel, because I have no idea what software is booting your kernel
06:19 upbeta: thanks for the details karolherbst :)
07:33 RSpliet: skeggsb: why does the hub/gpc cs firmware bother calculating what the stack pointer is supposed to be? monitoring 0x409fec reveals the stack pointer when idle is 0x00000000 and on the first push it's decremented to 0x00000ffc
07:33 RSpliet: it kind of seems like that highest bit is simply not stored
07:34 RSpliet: hence initialising to 0 would have the same effect
10:53 mwk: RSpliet: there are falcons with NPOT data size iirc
11:43 karolherbst: imirkin: any idea how much time it would take to implement shader caching for nouveau? I am sure this can improve performance for these shitty ported eon games quite a lot :D
11:44 imirkin_: karolherbst: doubtful.
11:44 karolherbst: I looked into bioshock for this and it does indeed compile a lot on the fly
11:44 imirkin_: karolherbst: doubtful that a cache would help too much.
11:44 karolherbst: why?
11:44 imirkin_: because you're starting from faulty assumptions
11:45 imirkin_: like "the shader cache is why radeonsi doesn't recompile as often now"
11:45 imirkin_: which is totally not the case
11:45 imirkin_: when in doubt, whatever's on phoronix, assume the opposite is true.
11:46 karolherbst: yeah well I thought a shader cache is the compiled binary for a given shder (+some parameters)
11:47 karolherbst: okay other question: why would it be bad to implement shader caching?
11:48 RSpliet: karolherbst: the key word you're looking for is "shader eviction"
11:50 RSpliet: iirc that was a problem until (including) GeForce 7xx0
11:50 karolherbst: well I get also shader eviction in bioshock
11:50 karolherbst: while ingame
11:50 karolherbst: not at starting time
11:50 imirkin_: karolherbst: because it'd slow down shader compilation ;)
11:51 karolherbst: yeah well, it has to be done only once in the end if we are smart enough
11:51 imirkin_: caching ain't free yo!
11:51 imirkin_: how do you think it works?
11:51 karolherbst: well for a given input we would just load a precompiled shader from a storage if there is such
11:52 imirkin_: karolherbst: -ENOPATCH
11:52 imirkin_: ultimately i think it'll be basically no benefit, but who knows
11:52 imirkin_: the real benefit would be to make sure those extra recompilations don't trigger in the first place
11:53 karolherbst: well, and I end up with games where mesa is compiling shaders while I play that game (and isn't inside a loading screen)
11:53 imirkin_: but that's a lot less headline-y sounding
11:53 imirkin_: karolherbst: so figure out why that's happening and fix it. i bet it's not coz the game is requesting compiles.
11:54 karolherbst: it does though
11:54 karolherbst: how do you want to add new shaders for the entire game world if you don't have loading screens in between
11:55 imirkin_: if they're totally fresh shaders, no amount of caching is going to fix having to compile them
11:55 karolherbst: but I am also sure I saw it in the apitrace
11:55 imirkin_: unless you do a disk cache
11:55 karolherbst: yeah
11:55 imirkin_: which is a whole separate thing
11:55 karolherbst: which would make sense
11:55 karolherbst: well I am talking about a disc cache anyway
11:55 imirkin_: and there's GL exts to make it happen
11:55 imirkin_: but they're not properly piped through in mesa
11:55 karolherbst: and what about applications which don't use that extension?
11:56 imirkin_: find me one.
11:57 imirkin_: but ultimately... i don't care. if you want to try to implement it, be my guest. but be prepared to back ti up with perf stats
11:58 karolherbst: well I think I would rather try to cut down compilation time, that's why I asked how long it would take to implement a disc cache
11:59 imirkin_: RSpliet: even when we evict shaders, we don't throw away compilation results
12:01 RSpliet: imirkin_: so basically... we cache shaders? :-P
12:04 imirkin_: RSpliet: we don't throw away shaders. but we also don't de-dup them
12:04 imirkin_: if you were to create an identical shader, it would trigger a full compilation
12:05 imirkin_: pmoreau: if it's not a lot of trouble, could use a glxinfo against mesa 11.2 against your G96.
12:31 airlied: imirkin_: well mareko pointed out with at least borderlands 2 we get a lot of duplicates
12:31 imirkin_: airlied: maybe. i'd be curious why.
12:31 karolherbst: mhh maybe it would make sense then to do that first
12:31 imirkin_: i don't think anyone's answered that question
12:32 imirkin_: without an answer to that question, i'm not interested in hearing solutions
12:32 airlied: imirkin_: different VS, same FS combos
12:32 airlied: or same VS, different FS combos
12:32 karolherbst: any fast way to check that?
12:32 imirkin_: airlied: ok, so the solution is to not trigger a recompile in the first place
12:32 airlied: but dupe detection is also overhead
12:33 imirkin_: exactly
12:33 imirkin_: it shouldn't even *want* to trigger a recompile in that case
12:34 karolherbst: but are these checks really that expensive that it would matter?
12:58 mupuf: karolherbst: a hash of the shader?
12:59 mupuf: and a look-up cost?
12:59 karolherbst: well I just md5 hashed my entire shader-db
12:59 mupuf: in memory, the cost should be pretty close to 0
12:59 karolherbst: took me 6 seconds (5 of this in kernel space)
12:59 mupuf: do it again
12:59 mupuf: it should be much faster :D
12:59 karolherbst: It was a second time
12:59 karolherbst: mhhh
12:59 karolherbst: you don't know how big my shader-db is
12:59 mupuf: ah ah
13:00 mupuf: well, I guess you can indeed ignore the lkernel space time
13:00 karolherbst: 10k shaders
13:00 mupuf: so, it is less than a second for your many k shaders :D
13:00 karolherbst: well that isn't as big as the intel one
13:00 karolherbst: but still
13:00 mupuf: hehe
13:00 karolherbst: the default one is just 500 shaders
13:01 imirkin_: or you could fix the underlying issue and not incur any of the extra costs
13:01 imirkin_: that sounds even better, let's do that.
13:01 karolherbst: yeah
13:01 karolherbst: I did a borderlands presequel trace
13:01 karolherbst: and want to trace the runtime a bit
13:01 mupuf: yep, the cache is the last thing you want to do
13:01 karolherbst: maybe we can optimize something in a pretty trivial way
13:01 karolherbst: like don't use dynamic list classes
13:01 karolherbst: if we know the max size
13:02 karolherbst: we could use std::array<type,size> or something
13:02 karolherbst: for the sources I think
13:02 mupuf: karolherbst: profile!
13:02 karolherbst: yeah
13:02 karolherbst: I already did this
13:02 karolherbst: and it spends most of the time in this stupid deque [] ops
13:03 karolherbst: 66 local CSE and like 50% of the CSE inside the dequeue iterator functions
13:03 mupuf: karolherbst: what is it used for?
13:03 karolherbst: hasDef and stuff
13:03 airlied: imirkin_: but yes lots of games do compiles when they really shouldn't
13:04 airlied: not mesa's fault, but the caching needs to happen at GLSL level really
13:04 airlied: because otherwise you run the glsl compiler
13:04 imirkin_: airlied: maybe. but the complaint here is that there's no compile going on, and yet st/mesa decides to rebuild.
13:04 airlied: I don't think there is any specific complaint
13:05 imirkin_: how about this -- *my* complaint is ... :)
13:05 airlied: okay I'd prefer we solve the problems users see :-P
13:05 imirkin_: seems secondary :p
13:22 karolherbst: airlied: I just noticed that for me borderlands spends more time in the do_common_optimization function inside _mesa_glsl_compile_shader
13:23 karolherbst: but overall, 12% of the entire cpu time is spend inside _mesa_glsl_compile_shader
13:39 mupuf: Yeah! GM206 support for nouveau!
13:39 mupuf: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/
13:39 karolherbst: nice :)
13:39 vedranm: mupuf: nice :)
13:40 mupuf: gnurou: yeepee! But curse you, I will have to test it in a bit!
13:40 karolherbst: mupuf: don't you mean gm20b :p
13:40 mupuf: don't really care about this one
13:40 karolherbst: well you point to the gm20b commit :p
13:40 mupuf: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c4f6a36d694bc4dbaeb6c9edae4889b4af2659ce
13:41 mupuf: sorry
14:17 airlied: http://www.linuxjournal.com/content/nvidia-releases-new-blobs-too-little-too-late
14:17 airlied: wow so much wrong
14:18 karolherbst: wow
14:19 karolherbst: the second paragraph already
14:19 karolherbst: ...
14:21 karolherbst: I don't know anything about this feature locking, but I highly doubt that's the case though
14:28 skeggsb: yeeep, very full of fail
14:28 RSpliet: fail? clearly that article is an objective representation of reality
14:30 mupuf: the second paragraph really is misleading
14:31 RSpliet: no more so than any of the other paragraphs really
14:31 mupuf: well, the rest is cute :D
14:32 mupuf: as in, NVIDIA does not care about us, it is because they got asked by real customers
14:32 mupuf: it is not like suddenly they felt like helping us
14:32 RSpliet: I don't know what multi-billion dollar revenue company you are referring to...
14:32 mupuf: but whatever, it has no real factual information anyway
14:32 mupuf: hehe
14:33 mupuf: but yeah, an article like that on linuxjournal ... this is bad...
14:33 mupuf: so, either we suck at communicating or the journalist did not spend enough time ... probably both :D
14:33 mupuf: although, gnurou's presentation at XDC should have been enough information
14:34 mupuf: sooo! Let's try this GM206!
14:45 karlmag:looks at the gtx 960 box
14:55 jerkey: i'm trying to decide whether to buy a computer with nvidia graphics or not. i run linux mint and i feel strongly about FOSS
15:07 xexaxo: airlied: that article is written by someone who's got absolutely no idea about the actual story or even graphics in general.
15:07 xexaxo: quite disturbing yet mildly funny reading though. thanks
16:06 mupuf: imirkin: the rendering issue in xonotic is also present on GM206
16:07 mupuf: just FYI
16:07 mupuf: so, it is likely not a chipset-specific bug
16:08 mupuf: but yeah, I can confirm that the GM206 indeed works with nouveau now! Yeepee!
16:08 mupuf: gnurou: thanks!
16:10 mupuf: 10510 frames 220.0106349 seconds 47.7704180 fps, one-second fps min/avg/max: 30 48 61 (336 seconds) <-- seems like it is in serious need of reclocking! That's fullHD + almost the ultra preset
16:11 imirkin_: mupuf: but it's only on maxwell right?
16:12 skeggsb: we need to wait for PMU ucode before we can even think about that on gm20x
16:13 skeggsb: (unless, somehow, our PMU ucode will run well enough to allow us to execute memory scripts)
16:13 skeggsb: if PMU is locked down as much as FECS/GPCCS are, then, won't be possible
16:18 mupuf: imirkin: as far as I know, yes
16:18 mupuf: skeggsb: yep
16:20 imirkin_: mupuf: yeah, so ... i dunno. i blame skeggsb.
16:20 skeggsb: imirkin_: hrm, i wonder if that goes away with that serialize hack of yours
16:21 skeggsb: i think i'd have tested that, but, i don't recall
16:21 skeggsb: i can also confirm gm20x has the same issues that gm10x does though
16:21 imirkin_: i bet it's an instruction emission error
16:21 imirkin_: but yeah, you could try to throw the serialize thing in and see what happens
16:22 skeggsb: we should probably shove that patch into mesa until we have a better solution i guess too.. (just for >=0xb097)
16:24 imirkin_: i dunno. i'd rather someone spend the 5 minutes to finish my EXA impl
16:25 skeggsb: well, regardless of what triggers it, it's a 3d driver bug..
16:25 imirkin_: i agree, but the sync isn't a solution
16:25 skeggsb: and fixing exa doesn't help people running on wayland+glamor
16:26 imirkin_: right, but those people will have issues on < 0xb097 as well
16:26 imirkin_: it happens on my GT215 as well (with the trace you made)
16:26 skeggsb: nope, the issues don't occur there
16:26 skeggsb: oh, really?
16:26 imirkin_: as well as GK208
16:26 imirkin_: but not GF108
16:26 skeggsb:thinks he's getting issues confused - ignore me
16:26 imirkin_: it might be specific to some flush pattern
16:27 skeggsb: GF108 is 0xc1 yeah?
16:27 imirkin_: yes
16:27 skeggsb: hrmm.....
16:27 imirkin_: and the number of commands for kepler is greator, or smaller, than for fermi
16:27 imirkin_: (due to diff texturing junx)
16:27 skeggsb: does it happen on any other fermi?
16:27 imirkin_: and the upload stuff is all different too
16:27 imirkin_: i just have the GF108
16:27 imirkin_:is not swimming in nvidia gpu's :p
16:28 skeggsb: i'll test that tomorrow.. if it's *only* 0xc1 that works, that could be a good hint
16:28 imirkin_: yes... but a hint of what...
16:28 imirkin_: i have no idea what that would hint at
16:28 imirkin_: beyond "something weird"
16:29 skeggsb: well.. on 0xc1 we had some other weird issue with exa, that, well, i kinda hacked around in a very awful way
16:29 skeggsb: https://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nouveau_drm.c#n420
16:30 imirkin_: hehe
16:30 imirkin_: that's... hilarious
16:30 imirkin_: i was definitely suspecting snooping
16:30 imirkin_: since one theory for the explanation was that it reads further than it's supposed to
16:30 imirkin_: and then caches those reads, before the data is there
16:31 imirkin_: (since the vertex data is written to GART)
16:50 imirkin_: skeggsb: it seems like only miptree bo's are ever set NOSNOOP though, i.e. textures, and those only ever go into vram anyways.
16:50 imirkin_: skeggsb: it could be that snoop isn't working somehow though when that bit is set? dunno.
16:51 skeggsb: yeah, it was a weird issue, and i don't know why that change even helped still..
16:51 skeggsb: but yes, that was my theory too
16:51 skeggsb: on gf108, it was vertex data from exa that was screwing up too
16:51 imirkin_: sounds familiar :)
17:33 mupuf: imirkin: wasn't the blue shadow fixed on heaven?
17:34 imirkin_: for 8x msaa? no
17:35 mupuf: ok, it is msaa-related then
17:35 imirkin_: if you have 8x msaa turned on, then yes.
17:35 mupuf: well, other than that, heaven seems to be runnign nicely
17:35 mupuf: and no tesselation, but this is expected
17:36 imirkin_: yep. waiting for someone to blink on that one :)
17:36 mupuf: plasma is also happy with it, although I get more font corruption than on the GM107
17:37 mupuf: in any case, it went better than expected
17:39 mupuf: I really need to check if the 2D issues are due to buffer age
17:39 mupuf: because they sure look like it
17:39 imirkin_: no
17:40 imirkin_: mupuf: https://bugs.freedesktop.org/show_bug.cgi?id=93373
17:40 mupuf: ah, right, this bug
17:41 mupuf: well, easy to test
17:46 mupuf: imirkin: it possibly helps, but it does not cure everything
17:46 mupuf: anyway, 4am, I should sleep
17:48 mupuf: I plugged the nvc8 and nve6 for karol and samuel
19:53 gnurou: skeggsb: btw, we noticed that gm200 had no gr instance set - using the gm204 one worked fine, although I suspect it needs to be fine-tuned?
19:55 skeggsb: gnurou: yeah, i have patches for that locally, secboot subdev was missing too
19:55 imirkin: skeggsb: perhaps you'll finally add GM108 as well?
19:55 imirkin: there are traces in bugzilla
19:55 skeggsb: i also played with making the gm200 use the gm20b paths (so, using the register lists from fw) and it made gr very unhappy
19:56 skeggsb: i need to spend some more time looking at that properly, it's going to be something simple and stupid no doubt.. but, it's pointless to have those tables if they're in fw already
19:57 skeggsb: imirkin: when i can convince myself that manually pulling the data from traces, comparing, and making new tables where necessary is a fun thing to do :P
19:57 skeggsb: but, i believe hans is looking at getting a gm108 laptop shortly, perhaps that'll be a fun task for him lol
19:58 gnurou: skeggsb: ok, just wanted to make sure gm200 will have a gr set for 4.6, since all the other Maxwells will be working
19:58 gnurou: I am taking care of setting secboot ;)
19:58 skeggsb: yeah, it should. mine works pretty good :)
19:59 gnurou: last review of the patches and they go your way, linux-firmware already merged my pull request
19:59 skeggsb: i'll fix that up now in my tree.. one moment
20:01 imirkin: skeggsb: yeah... it kinda sucks. the way those tables are organized doesn't lend itself to easy analysis either =/
20:05 skeggsb: gnurou: there you go
20:05 skeggsb: imirkin: there's not really a better way to organise them
20:06 skeggsb: well, there is: duplicate the majority of the info and make the minor changes
20:06 skeggsb: which, well, we get now on gm20x with the firmware-provided register lists
20:07 imirkin: skeggsb: duplication ain't so bad
20:07 skeggsb: there's a *lot* of data there :P
20:07 imirkin: anyways... it's organized however you want since you're the one diving around in the traces
20:07 skeggsb: but yes, i do somewhat regret not just doing that
20:07 imirkin: i did try to validate the GM108 stuff
20:08 imirkin: but i got too confused
20:08 imirkin: in the maze of the nouveau tables
20:08 imirkin: a bunch of stuff did match though, and i didn't find any differences to GM107
20:08 imirkin: but i also didn't follow the whole thing
20:08 skeggsb: we *could* just make it use gm107's.. but, that's a fine way to lead to very subtle bugs (we've had instances of that in the past alreadY)
20:09 imirkin: no _real_ urgency... GM108 is only ever used as an accelerator chip
20:09 imirkin: and nouveau will do nothing to accelerate the situation :)
20:10 imirkin: gnurou: on a scale of 1..10, what are the chances you'll complete tessellation support in nouveau for maxwell?
20:11 gnurou: imirkin: 0.1? there are many many more things on my list, tessellation does not come to mind
20:11 imirkin: gnurou: ok, good to know
20:12 gnurou: imirkin: the one non-work-related feature I'd maybe add if I find the time is support for Maxwell shader scheduling instructions
20:13 gnurou: ... but actually I wonder if that would not make a good GSoC topic?
20:13 imirkin: ... for the right candidate.
20:13 gnurou: since it's all publicly documented by Maxas
20:13 imirkin: who are few and far in between
20:13 gnurou: of course
20:14 imirkin: i dunno about that... i definitely did not get what the maxas docs were talking about at all
20:14 imirkin: i *did* recently see a .REUSE thing printed by nvdisasm though - that was new.
20:14 gnurou: I have read the Maxas wiki and found it very accurate
20:14 imirkin: not saying it's not accurate...
20:14 imirkin: just saying i didn't understand at all what it was trying to communicate.
20:15 gnurou: basically, every 4th instruction is not an instruction, but information about how scheduling for the 3 next instruction is to be performed
20:15 imirkin: yes, we know that much
20:15 imirkin: but there's weird stuff with barriers, reuse, etc
20:15 gnurou: e.g. whether you can dual-issue two instructions, how much cycles you must wait for the operands to be available, etc
20:15 imirkin: we do all that for kepler
20:16 gnurou: do you? I thought the hardware could still handle this on Kepler
20:16 imirkin: sched is optional on kepler
20:16 imirkin: but we do put it in
20:16 gnurou: and actually I learnt about all this stuff when you pointed Maxas to me ;)
20:16 imirkin: look for the SchedDataCalculator
20:16 imirkin: in nv50_ir_emit_nvc0.cpp
20:17 imirkin: (but it's also reused by the GK110 logic, which btw, i'm not 100% sure can handle not having sched)
20:18 gnurou: skeggsb: ah also, should we add MODULE_FIRMWARE entries for GM20X?
20:18 skeggsb: yes, we should
20:20 gnurou: skeggsb: does it make sense to do it in secboot?
20:21 skeggsb: hmm, probably i guess, since that's what's actually consuming them.. though, part of me goes "they belong to gr and should live there"
20:21 skeggsb: up to you :)
20:22 gnurou: secboot loads them, so makes sense to me that it also specifies them
20:23 skeggsb: yeah that's fair
20:59 imirkin: who is this guy going around closing all the ubuntu-related nouveau bugs? and is that a good idea?
20:59 imirkin: did canonical hire an ubuntu person?
20:59 imirkin: er
20:59 imirkin: did canonical hire a nouveau person
21:10 RAOF: Not to my knowledge? Not since mlankhorst?
21:11 imirkin: afaik he was doing X stuff, not nouveau specifically (at least in his canonical duties)