00:51 karolherbst: anybody interested in a fuc nanorc file for awesome coloring? By the way, we could collect such files (also for vim and such) inside envytools
00:52 Tom^: karolherbst: its slow on mesa 11.0.6 , drm 2.4.65 and your stable_clock_branch which i ran before.
00:52 Tom^: the blob runs at same speed, so it isnt the card dying from what i can tell :/
00:52 karolherbst: Tom^: yeah, I thought so much
00:52 karolherbst: something is odd
00:52 karolherbst: but no clue what
00:52 pmoreau: karolherbst: Good idea! I was planning on opening a PR to add demmio and demmt syntax coloring for Vim.
00:52 karolherbst: Tom^: does arch gives you a list of revently updated packages?
00:53 karolherbst: pmoreau: k
00:53 karolherbst: pmoreau: I was thinking to add cmake support too
00:53 Tom^: karolherbst: well yea but im not sure at which point it was working.
00:53 karolherbst: like for systemwide installing
00:53 karolherbst: Tom^: 1 month
00:53 pmoreau: Isn't envytools already using CMake? O.O
00:53 karolherbst: Tom^: I am sure on 15th of december it was all fine
00:53 karolherbst: pmoreau: yeah
00:53 karolherbst: pmoreau: but I meant we could install those files through cmake too
00:54 pmoreau: Ah!! :-)
00:54 karolherbst: pmoreau: but with options
00:54 karolherbst: or not
00:54 karolherbst: most distributions doesn't care anyway I guess
00:54 pmoreau: You could put them in /usr/share, and let the users link to them if they want to
00:54 pmoreau: Similar to what lldb does
00:55 karolherbst: I think the general way to do is to install inside /usr/share/bash-completion
00:55 karolherbst: and let the distribution handle everything else
00:56 pmoreau: Why in bash-completion?
00:56 karolherbst: for bash?
00:56 karolherbst: wher eelse?
00:57 pmoreau: I use zsh, not bash ;-)
00:57 karolherbst: yeah well, does zsh use the same syntax?
00:57 pmoreau: Bash scripts should work with zsh
00:57 karolherbst: k
00:57 karolherbst: ohhh
00:57 karolherbst: but I meant nano stuff :D
00:58 karolherbst: how did I come to bash?
00:58 pmoreau: Why not /usr/share/envytools? Seems more general
00:58 pmoreau: Absolutely no idea! :-D
00:58 karolherbst: well nanorc files belong inside /usr/share/nano
00:58 pmoreau: That's why I found it weird you were talking about bash out of the blue
00:58 karolherbst: and you enable them inside your nanorc file
00:58 Tom^: karolherbst: https://gist.github.com/anonymous/12cad9d747c8942a1732 :/
00:58 karolherbst: Tom^: wait a second
00:59 karolherbst: most of this can be ignored
00:59 pmoreau: Right, but we could just put every syntax files inside /usr/share/envytools/{vim,nano,emacs,whatever}, and let the user decide to link against them or not.
01:00 karolherbst: Tom^: try xf86driproto
01:00 karolherbst: pmoreau: I prefer the normal way here ;)
01:00 karolherbst: pmoreau: files inside /usr/share/nano aren't loaded automatically anyway
01:00 Tom^: karolherbst: havent changed since the 3rd july
01:00 karolherbst: you really have to enable those yourself usually
01:00 karolherbst: Tom^: "[2015-12-28 18:07] [ALPM] installed xf86driproto (2.1.1-3)"
01:01 Tom^: karolherbst: yea but its build date is from 3rd july
01:01 Tom^: karolherbst: so its just fetched in as some dependency for something
01:01 pmoreau: karolherbst: They are automatically enabled for Vim IIRC, as long as they are in the path
01:01 Tom^: wait hm when did the xorg server update
01:02 pmoreau: Build date: 18 Nov for 1.18.0-3
01:02 Tom^: [2015-12-28 18:07] [ALPM] installed xorg-server-devel (1.18.0-3)
01:03 karolherbst: Tom^: shouldn't be it
01:03 karolherbst: Tom^: I think it has to be between those phoronix benchmarks, because there was also a weird drop of performance
01:03 pmoreau: Tom^: You're not using pacman to check a package install date?
01:04 Tom^: pmoreau: sure, just skimming through the pacman.log
01:04 Tom^: karolherbst: the only thing changed really is me getting the blob :/
01:04 pmoreau: Ah! I meant, `pacman -Qi xorg-server` for example
01:04 Tom^: karolherbst: besides mesa and libdrm but those doesnt help to roll back so
01:09 Tom^: and it cant be that many other things either since i get identical score with blob
01:10 Tom^: but *shrug* idk
01:15 Tom^: pmoreau: url to your distro isos.
01:15 Tom^: pmoreau: and do you still keep around older ones?
01:15 pmoreau: Tom^: One sec, updating nginx and php :-)
01:15 Tom^: ah ok
01:16 Tom^: because if things are slow on your older isos with karols stable_reclock branch my card is borked. either HW wise or because of blob :p
01:16 pmoreau: I do keep some of them, when I was doing daily builds, I kept the last month or two, but now that it's daily, I don't know yet :-D
01:16 pmoreau: But I should still have some from Nov at least
01:16 Tom^: those will do fine
01:18 pmoreau: http://nouveau.pmoreau.org/
01:19 pmoreau: Since it took some time (and will) to fix the xf86-video-ati bug, I don't have any image from Dec.… --"
01:26 Tom^: thats fine because i need something from early december or november.
01:27 Tom^: you know what karolherbst it could just be my PSU :p
01:28 Tom^: since i was peaking like 280W with the sensors patch. and perhaps its just degraded and cant keep that up any more.
01:36 Tom^: oh right forgot you had no headers in the iso ;_;
01:41 pmoreau: At the time, yes… :-(
02:04 karolherbst: well I moved to git with my package manager database, so maybe I could just git bisect my system :/
02:04 karolherbst: sounds like a lot of fun though
02:06 Tom^: well are you sure it slow for you too?
02:07 karolherbst: yes
02:08 karolherbst: my fps dros below 9 fps in heaven in the first scene
02:08 karolherbst: it hardly reached 9 before
02:08 karolherbst: now it pretty much drops to 8
02:08 karolherbst: and everything feels slower
02:09 Tom^: mhm
02:13 karolherbst: yeah, it is just slow now
02:13 karolherbst: 10.2 fps
02:13 karolherbst: 256 points
02:13 karolherbst: in heaven
02:14 Tom^: the only thing i havent tested yet is the merge of skeggs changes.
02:14 Tom^: my score i think is from the time when your repo was sort of out of sync
02:14 vita_cell: hi karolherbst
02:15 karolherbst: I was above 300
02:15 karolherbst: ...
02:17 karolherbst: ohh was testing without my pcie stuff now
02:17 karolherbst: imirkin: there is a noticeable perf hit for sure
02:19 vita_cell: http://imgur.com/0V0cDA4
02:22 karolherbst: ohh 261 points with my pcie stuff, well...
02:27 karolherbst: blob has 529 points
02:27 karolherbst: ...
02:28 karolherbst: so nouveau is below 50% even full reclocked now
02:28 Tom^: yea same here i got 860 in heaven, blob 1960, before i was on 1096 :/
02:29 karolherbst: yeah
02:29 Tom^: the only thing i havent tested is revert your merge with skeggs repo from when you repos was out of sync
02:29 karolherbst: wait I have an old tree
02:29 Tom^: im not entirerly sure how to do that either since you rebased and stuff
02:30 karolherbst: right
02:32 karolherbst: hopefully my old branch has better perf
02:34 Tom^: the vbios gives me same md5sum as from before, so nothing changed there atleast :P
02:35 karolherbst: yeah
02:35 karolherbst: I am sure it will be somethig in the kernel
02:35 vita_cell: karolherbst, how to compile my "nouveau" folder for 4.3.3?
02:36 karolherbst: vita_cell: wait a bit, we try to find a serious performance regression
02:36 vita_cell: no prob!!
02:36 vita_cell: nice !!
02:47 Tom^: vita_cell: you need kernel headers installed and simply cd gitclone/drm , make
02:47 vita_cell: yes I have
02:47 vita_cell: and I have my NOUVEAU folder
02:47 vita_cell: I must to compile nouveau/drm right?
02:47 Tom^: cd NOUVEAU/drm then :p run make, that should place a .ko in NOUVEAU/drm/nouveau/nouveau.ko
02:48 vita_cell: yes, but I have something wrong
02:48 vita_cell: /home/vita/Escritorio/nouveau-fixed2/nouveau/drm/nouveau/nouveau_drm.h:187:44: warning:
02:48 vita_cell: ‘struct nvkm_device_tegra_func’ declared inside parameter list [enabled by default]
02:50 vita_cell: http://hastebin.com/sesudiwilo.avrasm
02:51 Tom^: yea no idea about those, karol might know when he has time.
03:11 karolherbst: Tom^: strike
03:12 Tom^: where is it?
03:12 karolherbst: Tom^: I have better perf with 11.1 + master_karol_no_thouchy_old brabnch
03:12 karolherbst: somewhere in between :D
03:12 karolherbst: but I still have to run the benchmark
03:12 karolherbst: I just noticed higher fps in the first scene in unigine
03:13 Tom^: mk
03:15 karolherbst: but the avarage fps is like 2.5 higher now :O
03:16 karolherbst: still not at the end
03:16 karolherbst: but...
03:16 karolherbst: this is 25% more
03:16 karolherbst: :D
03:16 karolherbst: 13.3 fps
03:16 karolherbst: 335 score
03:16 karolherbst: vs 10.2 fps and 256 score
03:16 karolherbst: this is some big regression
03:17 Tom^: mhm
03:18 karolherbst: now I have to test witht he faulty nouveau module and 11.1
03:19 karolherbst: strike
03:19 karolherbst: seems to be a mesa regression
03:19 karolherbst: imirkin: any ideas?
03:19 karolherbst: something between 11.1 and master
03:20 Tom^: well you still havent quite tested if its skeggs changes which you rebased to
03:21 Tom^: because its still slow on 11.0.6 here
03:21 karolherbst: Tom^: I am using current nouveau now
03:22 Tom^: uhm
03:22 Tom^: unpossibre.
03:23 karolherbst: let's wait until I bisect the thing :D
03:23 karolherbst: I bet it will all makes sense
03:29 karolherbst: why do I get those "0:174(1): error: #extension directive is not allowed in the middle of a shader" errors whenever I use my own build mesa with unigine?
03:33 lleo: who am i, dri :p
03:51 karolherbst: Tom^: It seems to be after ben changes
03:51 Tom^: mmh suspected as much.
03:51 karolherbst: well I artificially disabled the new nvif interface
03:51 karolherbst: so not quite sure though
03:53 lleo: is there a nvclock with direct i2c like lfsb?
04:04 karolherbst: Tom^: now I get the same perf with master :O
04:04 karolherbst: and the new interface
04:04 Tom^: how?
04:04 Tom^: =D
04:05 karolherbst: Tom^: checking
04:05 karolherbst: Tom^: maybe it is just caused my simply enabling debug stuff inside mesa :/
04:09 vita_cell: karolherbst
04:17 Tom^: karolherbst: still slow with --enable-debug here :P
04:17 karolherbst: yeah I meant --disable-debug
04:17 karolherbst: :p
04:17 karolherbst: it may be slower with debug enabled
04:17 karolherbst: but who knows
04:18 karolherbst: maybeI find the culprint
04:18 karolherbst: *culprit
04:18 Tom^: wasnt before tho :/
04:19 karolherbst: maybe I did something wrong bisect or something
04:19 karolherbst: ir it was already fixed :O
04:20 karolherbst: Tom^: do you want to test latest mesa master?
04:20 Tom^: just did, with --disable-debug , no go.
04:20 karolherbst: .... wtf
04:20 karolherbst: systemwide installed mesa slow
04:20 karolherbst: local compiled one faster?
04:21 Tom^: haha
04:21 karolherbst: well make clean helps maybe
04:23 Tom^: im just gonna compile mesa with clang, becaus gcc has updated recently it seems.
04:27 karolherbst: don't think this will make any difference
04:27 Tom^: it didnt. :P
04:27 karolherbst: mhhh
04:27 karolherbst: why is my system one installed slower?
04:28 vita_cell: karolherbst can you give me the newest nouveau folder? with latest fixes
04:57 karolherbst: Tom^: something is odd with the mesa libs
04:57 karolherbst: not the nouveau driver
04:58 karolherbst: Tom^: system mesa, but self compiled nouveau_dri.so gives good performance here
04:58 karolherbst: I mean bad
05:00 karolherbst: mhhh no, self compiled nouveau gives good perf :D
05:01 Tom^: not quite sure what you are getting at, nouveau_dri.so doesnt get compiled when i build mesa?
05:02 karolherbst: it is
05:03 karolherbst: weird
05:04 karolherbst: Tom^: do you use any strange compiler flags? :/
05:05 Tom^: was just about to compile it with these , https://gist.github.com/anonymous/8b2f429ae669d9377753#file-pkgbuild-L42
05:07 Tom^: oh you mean CFLAGS
05:07 Tom^: CFLAGS="-march=x86-64 -mtune=native -O3 -pipe -fstack-protector-strong"
05:08 karolherbst: mhh
05:22 karolherbst: Tom^: yeah no idea, as long as I use the local compiled one I get good perf
05:30 Tom^: and the non local compiled comes from where?
05:40 karolherbst: well it is the system wide compiled one
05:40 karolherbst: :D
05:42 karolherbst: I got it :O
05:42 karolherbst: orr wait
05:42 Tom^: so you are telling me the very same .so get slow because its placed elsewhere?
05:42 Tom^: =D
05:44 karolherbst: now I bisect the system wide install thing :/
06:31 Tom^: yea i give up, i simply cant find a working state.
06:43 vita_cell: from where I can download the latest nouveau for compile?
06:44 karolherbst: vita_cell: well just checkout a git repository and compile it
06:44 karolherbst: depends actually on what you need
06:44 karolherbst: didn't remember your problem anymore :/
06:44 karolherbst: Tom^: well for me 11.1 is working
06:44 Tom^: 11.0.6 doesnt here so :/
06:45 karolherbst: try either 11.1 or 11.0
06:45 vita_cell: karolherbst you fixed the voltahe issue for gtx650 and gtx770, later you fixed gtx770 the hightest pstate, and later you added PCIe 3.0 support
06:45 karolherbst: could be that .6 has also the issue
06:45 karolherbst: vita_cell: k
06:45 karolherbst: vita_cell: you mean like this patch? https://gist.githubusercontent.com/karolherbst/769c4918b3c49459d067/raw
06:45 Tom^: karolherbst: mesa 11.0.6 is older then my tests.
06:45 Tom^: so yea :p
06:46 vita_cell: some new fix?
06:46 karolherbst: 7 weeks
06:46 karolherbst: vita_cell: depends
06:46 karolherbst: vita_cell: you can always use the tom branch and this hack
06:46 karolherbst: this should work for most cases
06:46 karolherbst: Tom^: do you have serious sam 3?
06:47 vita_cell: I have no issues, but, if some fix new here, I want to compile the newest
06:47 Tom^: karolherbst: Serious Sam 3: BFE
06:47 Tom^: karolherbst: i have that
06:47 karolherbst: nice
06:47 vita_cell: me too
06:47 karolherbst: Tom^: do you want to check if the pcie stuff makes a difference there?
06:47 vita_cell: look at my GPU cooler
06:47 vita_cell: http://imgur.com/0V0cDA4
06:47 Tom^: karolherbst: mhm when you find my performance regression. =D
06:48 karolherbst: Tom^: yeah well, guess what I am doing
06:48 vita_cell: I can't usea pcie3 cuz I have i7 2600
06:48 Tom^: karolherbst: xD i know.
06:48 karolherbst: Tom^: nvapeek 0x8c040
06:48 Tom^: im on blob
06:48 karolherbst: doesn't matter
06:48 Tom^: 0008c040: 80089000
06:49 karolherbst: nvapoke 0x8c040 80089001 => 2.5 GT/s
06:49 karolherbst: nvapoke 0x8c040 80009001 => 8.0 GT/s
06:49 karolherbst: nvapoke 0x8c040 80049001 => 5.0 GT/s
06:49 karolherbst: though I don't know what the blob does if you change it :D
06:49 Tom^: probably vomit.
06:49 karolherbst: maybe it clocks it back up
06:49 karolherbst: no idea
06:50 karolherbst: nah
06:50 karolherbst: this change doesn't effect the driver at all
06:50 Tom^: yea i cant change it on the blob it seems.
06:50 Tom^: peek always return same value no matter the poke :p
06:51 karolherbst: :D
06:51 karolherbst: k
06:52 karolherbst: mhhh
06:52 karolherbst: maybe you have to poke the value first
06:52 vita_cell: guysm do you think that Nvidia sabotage their drivers? lowering performance in newer drivers for older card?
06:52 karolherbst: poke ... 800X9000; poke ... 800X9001
06:52 karolherbst: vita_cell: why should they?
06:52 karolherbst: also no, it would be too obvious
06:52 karolherbst: because then you would simply use the older driver
06:53 karolherbst: but I could be wrong, it just wouldn't make any sense
06:53 vita_cell: they always recommend updating
06:53 karolherbst: yeah
06:53 karolherbst: because of driver optimizations
06:53 karolherbst: or new features and stuff
06:53 karolherbst: and kernel compatibility
06:53 vita_cell: Nvidia drivers work very bad on my gtx770
06:53 karolherbst: what do you mean by "bad"?
06:54 karolherbst: as long as you can beat Tom^s gpu with nouveau with your blob your are fine :D
06:54 vita_cell: when I play some game and I quit, and I must to wait to cool it, or wait for automatic low pstate, before open firefox for example
06:54 vita_cell: wait about 1 minute
06:55 karolherbst: why do you have to wait to cool it?
06:55 Tom^: so its overheating and you showed a pic of some custom gpu cooler ?
06:55 vita_cell: if not, it gives me a black screen, frequency out of range
06:55 Tom^: 1 + 1 usually is 2 :P
06:55 vita_cell: Windows 7 with blob
06:55 vita_cell: and I must to reboot
06:55 karolherbst: vita_cell: is your cooling system liquid cooling?
06:55 vita_cell: not
06:55 karolherbst: or just pipes
06:55 karolherbst: ?
06:55 vita_cell: stock with 70º when gaming
06:56 karolherbst: because the cooling seems a bit too custom
06:56 vita_cell: now I with CPU cooler on my gtx770, 40-45º when playing, and still doing some thing
06:56 karolherbst: vita_cell: is this cooler shared between cpu and gpu?
06:56 vita_cell: yes, mine
06:56 vita_cell: not
06:57 vita_cell: I put CPU cooler with fan, to my gtx770
06:57 vita_cell: http://imgur.com/0V0cDA4
06:57 karolherbst: ahh k
06:57 vita_cell: 44º playing CS:GO in GNU/Linux
06:58 Tom^: i thought the gpu had more things to be cooled then the core chip
06:58 karolherbst: :D
06:58 karolherbst: yeah well
06:58 karolherbst: memory :p
06:58 vita_cell: but work much better that stock
06:58 karolherbst: but memory isn't getting so hot usually
06:58 vita_cell: not, I put heatpipes on memoryes
06:58 karolherbst: vita_cell: no idea, does older driver work better?
06:58 vita_cell: I didnt tryed it
06:58 Tom^: might aswell be HW issues
06:59 karolherbst: I think somthing else is odd
06:59 karolherbst: you might want to check your system log and x log
06:59 vita_cell: but Nvidia's blob works with that issue
06:59 vita_cell: this is in Windows 7
06:59 karolherbst: ohh so it is only with nouveau that issue?
06:59 vita_cell: with GNU and nouveu ir works fine
06:59 karolherbst: ahh k
06:59 vita_cell: only Windows7 + blob
07:00 vita_cell: Windows 7 64 + Nvidia blob = black screen, out of range
07:00 karolherbst: Tom^: check f22ab2e8b3dbd7dfdada0d353da1c6ef898f1494 out
07:00 karolherbst: clean build
07:00 vita_cell: after gaming I must to wait about 1 minute for open something
07:01 vita_cell: you doing very nice work with nouveau
07:01 karolherbst: mhhh no idea what this could be to be honest
07:01 vita_cell: no prob!!
07:01 karolherbst: usually I blame lenovo when there is heat issues, but this is a desktop so that doesn't work
07:01 karolherbst: :D
07:02 vita_cell: karolherbst, some new model supports nouveau reclock??
07:02 karolherbst: vita_cell: every kepler should work now, or at least we know how we get them to work
07:02 karolherbst: still needs some work to make that generally available
07:02 vita_cell: so, gtx970 works only with blobs
07:03 karolherbst: yes
07:03 karolherbst: signed firmware needed
07:03 vita_cell: hate Nvidia drivers
07:03 karolherbst: who knows when they arrive
07:03 vita_cell: yes, I know
07:03 karolherbst: and then it will take anover year until they will run stable enough I guess
07:04 karolherbst: maybe only half a year
07:04 karolherbst: depends on actually who will be able to work on maxwell gpus
07:04 vita_cell: ymy gtx770 runs stable, I think so
07:04 vita_cell: very stable
07:04 vita_cell: never crashed nothing with GNU+nouveau
07:05 vita_cell: I using Trisquel (fully deblobbed GNU/Linux-Libre distro)
07:11 karolherbst: Tom^: and does that commit work?
07:11 Tom^: compiling, i dont have xeons. yet.
07:14 karolherbst: yeah lol
07:14 karolherbst: in this time I compiled it twice
07:15 Tom^: i also sort of have to reboot everytime i jump between blob :P
07:16 Tom^: optimus has its uses
07:16 karolherbst: :D
07:18 Tom^: karolherbst: are you on that build now?
07:19 karolherbst: yeah
07:19 karolherbst: well now I am on a newer one
07:19 karolherbst: 5898cbae2479874a6206e27e6b73a3ba244a2094
07:19 karolherbst: but this is also a good one
07:19 Tom^: glxinfo | grep "OpenGL version" , OpenGL version string: 3.0 Mesa 11.2.0-devel (git-f22ab2e)
07:19 karolherbst: yeah
07:19 Tom^: first scene is slower then what i remember but i can run the entire test.
07:20 karolherbst: I hope this isn't something ugly :/
07:21 karolherbst: ohh I fear a buffer overflow or unchecked range loop or something that stupid
07:22 karlmag: vita_cell: wow.. that cooler thing looks a bit excessive :-P
07:23 vita_cell: 27º at idle, 44º at load
07:23 karolherbst: :D
07:23 karlmag: still :-P
07:23 karolherbst: ohh my cpu doesn't even reach 44°C
07:23 vita_cell: 70º at load with stock asus cooler
07:23 karlmag: takes up "half" the case
07:24 karlmag: good thing you didn't need to have two graphics cards in there ;-)
07:24 karolherbst: :D
07:24 vita_cell: yes, hahahahha and no sound card
07:24 karolherbst: I bet this card could be a bit OCed with that cooler
07:24 vita_cell: Realtek workds better in GNU OS
07:24 karlmag: karolherbst: my thought too
07:25 vita_cell: yes, OCed but I dont know how in GNU and nouveau
07:25 Tom^: karolherbst: score 884
07:25 karolherbst: Tom^: soo?
07:25 vita_cell: AC: core 1032 MHz memory 7009 MHz
07:25 Tom^: so this commit is still slow
07:25 vita_cell: the highest
07:25 karolherbst: mhhhh
07:26 karolherbst: weird
07:26 karolherbst: very weird
07:26 karolherbst: Tom^: ohhh idea
07:26 karolherbst: drm/nouveau/nouveau_drm.h
07:26 karolherbst: change the version to 1.2.2
07:26 karolherbst: install the driver and check again
07:26 vita_cell: what to do?
07:26 karolherbst: ohh wait
07:26 karolherbst: no
07:26 karolherbst: I don't have that anymore
07:27 karolherbst: Tom^: well then wait until I'm done
07:27 Tom^: :p
07:27 karolherbst: I bet the bad commit will tell us nothing
07:28 Tom^: yea as i said, the only thing i havent tried to revert is when you rebased your out of sync repos towards skeggs ones.
07:28 vita_cell: http://hastebin.com/cibipaxiba.hs
07:28 Tom^: the rest ive been back before i even started testing stuff here
07:29 karolherbst: vita_cell: ohh right, yeah well, that will be also fixed shortly
07:29 karolherbst: but it won't give you much higher perf anyway
07:29 vita_cell: nice!!
07:29 vita_cell: yes I know
07:29 Tom^: vita_cell: you can also just do echo 0f | sudo tee /sys/class/drm/card0/device/pstate
07:30 karolherbst: Tom^: it is between 5071c192ccbfac92c53d93aea049bf981ae9e442 and b022150d70a1cfdda2007fa16b04c601eef45d6f for me :/
07:30 Tom^: :/
07:30 karolherbst: I meant 5898cbae2479874a6206e27e6b73a3ba244a2094 and 5071c192ccbfac92c53d93aea049bf981ae9e442
07:30 vita_cell: 0f state is: AC: core 1032 MHz memory 7009 MHz
07:31 karolherbst: end of december and 6th jan
07:31 karolherbst: mhh would make sense somehow
07:45 karolherbst: Tom^: *cough* [4acf71c89b5ef5e2fe8c1a3d7ecf6031e191463c] drirc: Disable ARB_blend_func_extended for Heaven 4.0/Valley 1.0.
07:46 karolherbst: :D
07:46 karolherbst: I knew it was something stupid
07:47 Tom^: no wonder im not finding it downgrading.
07:47 Tom^: my .drirc doesnt change upon recompilation
07:47 Tom^: :P
07:47 karolherbst: yeah
07:47 karolherbst: ...
07:47 karolherbst: imirkin: 4acf71c89b5ef5e2fe8c1a3d7ecf6031e191463c
07:47 karolherbst: .........
07:48 Tom^: drivers shouldnt ever workaround broken software, or its gonna end up just like in windows.
07:48 Tom^: where even the NT kernel works around software bugs
07:49 karolherbst: yikes :D
07:49 karolherbst: well
07:49 karolherbst: linux does too
07:49 karolherbst: somewhat
07:49 Tom^: which is sad.
07:49 karolherbst: but because it is linux fault
07:49 karolherbst: :D
07:49 karolherbst: if linux shiped a broken interface and software relies on that
07:49 karolherbst: this interfaces has to stay broken forever
07:51 vita_cell: karolherbst is there some nouveau drivers for Windows?
07:51 Tom^: vita_cell: no
07:51 hakzsam: karolherbst, I guess you won't hit that regression with heaven 4.1
07:52 vita_cell: no open-source driver?
07:52 karolherbst: :D
07:52 Tom^: hakzsam: yea but still, this commit is really bad
07:53 hakzsam: heaven is probably bad :)
07:55 hakzsam: Tom^, you can revert that change locally with your own .drirc I guess
07:55 Tom^: yes i know
07:59 hakzsam: Tom^, which chipset do you have btw? I don't remember
07:59 Tom^: 780ti
07:59 Tom^: or gk110b iirc
08:01 hakzsam: Tom^, nice, if you have time, could you please try out this branch and tell me if this doesn't break the universe for you? http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_mp_counters
08:01 Tom^: sure
08:03 hakzsam: thanks
08:04 karolherbst: hakzsam: by the way, what is the best way to read out all perf counters at once?
08:05 hakzsam: which perf counters?
08:05 karolherbst: all of them :D
08:06 Tom^: ugh what did i break now https://gist.github.com/anonymous/fcc62910538546b5bd6e
08:07 hakzsam: it depends which ones you want to read out (mp perf counters, global perf counters, pdaemon counters, etc)
08:07 hakzsam: Tom^, this is with the nvf0_mp_couters branch?
08:07 Tom^: no master :P
08:08 hakzsam: try make distclean :)
08:08 hakzsam: karolherbst, for what, do you want to read all perf counters at once btw?
08:09 karolherbst: hakzsam: well usually I want to have those OpenGL related ones, like when I run a game and I see it runs real bad compared to blob, I want to know why ;)
08:09 hakzsam: karolherbst, they are still not upstream
08:09 hakzsam: only compute-related ones are there
08:09 hakzsam: and you have to use GALLIUM_HUD to read out them
08:10 hakzsam: or gl_amd_performance_monitor if you write your own GL app
08:10 hakzsam: or if you use apitrace
08:11 karolherbst: ahhh okay
08:11 hakzsam: karolherbst, did you ever try NGD on the blob?
08:12 karolherbst: ngd?
08:12 hakzsam: nvidia graphics debugger
08:12 karolherbst: mhh no
08:12 hakzsam: this can show you how to use perf counters (but blob only)
08:13 karolherbst: yeah well, I want to see why games run bad on nouveau, and with games I mean stuff where I can't simply check the code and stuff ,)
08:13 hakzsam: I already REd all GL perf counters
08:13 karolherbst: ohh nic
08:13 karolherbst: e
08:13 hakzsam: but my branch still needs some work
08:13 Tom^: i want to be able to see vram usage :p
08:13 hakzsam: karolherbst, sure, if you want to monitor perf counters per frames or per draw calls, you can try apitrace with a special branch
08:14 hakzsam: give me a sec
08:14 hakzsam: https://github.com/trtt/apitrace/commits/metric_abstraction
08:14 hakzsam: here is the branch
08:14 karolherbst: hakzsam: and which branch do I need on the mesa side?
08:14 hakzsam: nothing
08:15 hakzsam: as I said, only compute-related ones are currently exposed
08:15 hakzsam: karolherbst, try GALLIUM_HUD="help" to see the list of availabel counters
08:16 karolherbst: ohhh k
08:16 karolherbst: I thought there is some work in progress thing for the gl related ones somewhere
08:16 hakzsam: I hope to merge my work in few weeks
08:16 hakzsam: yeah
08:16 hakzsam: I'm working on it when I have time ;)
08:16 karolherbst: :D
08:16 karolherbst: k
08:16 karolherbst: so there is nothing I could try out yet?
08:16 hakzsam: and this week I worked on arb_compute_shader, so...
08:17 hakzsam: karolherbst, once it's stable enough you might try :)
08:17 hakzsam: I'll tell you, don't worry
08:17 karolherbst: :D
08:17 karolherbst: k
08:17 karolherbst: thanks
08:17 karolherbst: Tom^: well you have to keep your compiler in check
08:17 hakzsam: karolherbst, you are probably the only guy (except me of cource) which wants to use those perf counters :)
08:18 karolherbst: :D
08:18 karolherbst: I really don't understand why
08:18 Tom^: the gallium_hud counters?
08:18 Tom^: count me in on wanting them if so.
08:18 karolherbst: I thought they are awesome to see why games run so slow
08:18 hakzsam: they are
08:19 hakzsam: but there is lack of good end-user applications to use them
08:19 Tom^: hakzsam: so anything specific you want me testing with your branch?
08:19 hakzsam: Tom^, just run glxgears and have a look at dmesg
08:20 hakzsam: Tom^, and well, try : GALLIUM_HUD="inst_executed" glxgears
08:20 hakzsam: and report me what value you see
08:20 Tom^: a cute graph :p
08:21 Tom^: it barfs in the terminal tho about nvc0_hw_sm_get_query_result() on like each frame i think.
08:21 Tom^: so it really spams it heh
08:21 pmoreau: hakzsam: I want to use them as well! Just need OpenCL/CUDA support to make use of them… :-(
08:21 hakzsam: Tom^, do you see any errors?
08:22 hakzsam: pmoreau, or arb_compute_shader+gl_amd_perf_monitor :)
08:22 Tom^: hakzsam: http://i.imgur.com/5nm23hk.png not really no
08:22 hakzsam: Tom^, ah yeah, it's just a debug msg :)
08:23 hakzsam: Tom^, GALLIUM_HUD="inst_executed" glxspheres64 ?
08:23 pmoreau: hakzsam: Nah, it would be to run my CUDA kernels on Nouveau rather than the blob, and try to maximise performance.
08:23 karolherbst: hakzsam: are these instructions per frame?
08:23 karolherbst: ohr per time
08:23 karolherbst: or whatever?
08:23 karolherbst: ohh wait
08:23 Yoshimo: Tom^: btw imgur supports TLS as well
08:23 karolherbst: frame would make a lot more sense
08:24 hakzsam: karolherbst, depends on GALLIUM_HUD_PERIOD
08:24 hakzsam: karolherbst, but more or less per frames, yeah
08:24 Tom^: hakzsam: how old is this branch?
08:25 hakzsam: Tom^, a month or so, why?
08:25 Tom^: hakzsam: https://gist.github.com/anonymous/6ad39e14171597de55b5 unigine-heaven died
08:25 karolherbst: this instruction thing is awesome :O
08:26 karolherbst: I like totally need this for no reasons :D
08:26 hakzsam: Tom^, outch
08:26 hakzsam: Tom^, I assume it works with master?
08:26 hakzsam: Tom^, I just rebased my work today btw
08:26 Tom^: well im gonna have to see so it does with this drirc commit reverted.
08:26 karolherbst: hakzsam: ahh do you have a counter which gives me information about how long the core waits for some memory operation to complete=
08:26 karolherbst: ?
08:26 Tom^: so hold on
08:27 hakzsam: karolherbst, no
08:28 karolherbst: k, but this instruction thing could be used to cut some instructions through optimizations and check through apitrace how big the gain is
08:29 Tom^: hakzsam: yea it runs on master
08:29 hakzsam: karolherbst, sure
08:29 hakzsam: Tom^, okay
08:29 Tom^: hakzsam: and it crashes without any GALLIUM_HUD set at all
08:29 hakzsam: sure
08:29 karolherbst: nice
08:30 Tom^: karolherbst: hooray i gained 10fps at first scene
08:31 karolherbst: :D
08:31 hakzsam: Tom^, revert 8379d07ce7c95265c9bd6c98364a880a461e71e3 on my branch and try heaven again
08:31 hakzsam: maybe my fix is just wrong
08:31 karolherbst: I hardly get 12 fps in total
08:31 Tom^: this commit makes me a bit sad, i was hoping that stuff like this didnt happend on linux.
08:31 karolherbst: well if the ungine does stupid things
08:31 Tom^: then unigine stays stupid until it fixes it shit.
08:31 Tom^: hakzsam: oki
08:32 karolherbst: it is fixed
08:32 karolherbst: :D
08:32 karolherbst: do you even read the commit message?
08:32 Tom^: yea i did
08:32 Tom^: still doesnt make me less sad that it went upstream in mesa, sure put some comment in the bugzilla or forum that it can be worked around with the drirc like this, dont set it as default.
08:34 karolherbst: or set it default for cards where it doesn't work ;)
08:35 Tom^: i wouldnt want that either, because at some point some sort of workaround like this will be forgotten about and simply just stay there even if the software fixes its bugs.
08:36 Tom^: but thats me
08:37 Tom^: hakzsam: that broke X :P
08:37 karolherbst: it is just added for the benchmarks anyway :D
08:37 hakzsam: Tom^, dmesg?
08:37 Tom^: hakzsam: shall see if i can get access to it. its sort of frozen.
08:38 hakzsam: Tom^, so, my patch definitely fix compute state initialization but there is still an other issue
08:38 hakzsam: mupuf, any chance you could plug in your gk208?
08:39 hakzsam: and unplug the gm20x which is... useless :)
08:42 Tom^: hakzsam: https://gist.github.com/anonymous/1e712689e6b01200a427 just a tiny bit of it.
08:43 Tom^: it sort of buffer overruns my kmsg
08:43 Tom^: =D
08:43 hakzsam: Tom^, yeah, I already saw those bits
08:45 hakzsam: Tom^, if would be very useful if you could find a piglit test which reproduces the same heaven's issue, and make a MMT trace
08:46 Tom^: gonna see if i have enough beer for that
08:46 Tom^: piglit runs takes like an hour :P
08:46 hakzsam: yeah...
08:46 hakzsam: Tom^, don't forget to revert the revert
08:47 hakzsam: otherwise, you card will hang with the first piglit test :D
08:47 Tom^: thats unforgettable because X doesnt even start!
08:48 hakzsam: fun!
08:53 Tom^: hakzsam: think ive found one already, nr 53 whichever that is has made the run uh hang. https://gist.github.com/anonymous/784ade6dba9ac157f6aa
08:53 hakzsam: Tom^, nice, which test?
08:53 hakzsam: you can stop your run piglit
08:53 Tom^: how do i find that out =D
08:54 hakzsam: in the results.json file
08:54 Tom^: doesnt stop on ctrl + c :P
08:54 hakzsam: kill it :)
08:55 hakzsam: or look at 53.json
08:55 hakzsam: maybe there is the name of the test, I don't remember
08:56 Tom^: {"spec@arb_texture_buffer_object@formats (vs, 3.1 core)": {"returncode": null, "result": "incomplete", "subtests": {"__type__": "Subtests"}, "out": "", "dmesg": "", "exception": null, "err": "", "__type__": "TestResult", "environment": "", "command": "", "time": {"start": 0.0, "end": 0.0, "__type__": "TimeAttribute"}}}
08:57 Tom^: now my X froze again :P
08:58 Tom^: https://gist.github.com/anonymous/50f1ff72119624913569 dmesg from when X is dead. or rather everything is
08:58 hakzsam: Tom^, so, bin/arb_texture_buffer_object-formats vs core -auto should fail, right?
08:59 Tom^: hakzsam: yep
09:00 hakzsam: do you see that read fault again?
09:00 Tom^: yep
09:01 hakzsam: Tom^, okay, could you switch on the blob and make a mmt, please?
09:01 Tom^: sure
09:02 Tom^: so how do i generate a mmt then
09:02 hakzsam: http://nouveau.freedesktop.org/wiki/Valgrind-mmt/
09:04 Tom^: it fails on the blob tho , https://gist.github.com/anonymous/bf7b8cab04f1632b8afc
09:04 hakzsam: sadness
09:04 hakzsam: we need to find another one
09:05 Tom^: cant i mmt it on master mesa?
09:05 Tom^: =D
09:06 hakzsam: only blob is useful here :)
09:10 Tom^: wee found another, 347. borked.
09:10 Tom^: atleast it isnt at the end its breaking =D
09:11 hakzsam: does it work on the blob?
09:12 Tom^: {"spec@glsl-1.30@execution@tex-miplevel-selection texturelodoffset 2dshadow": {"returncode": null, "result": "incomplete", "subtests": {"__type__": "Subtests"}, "out": "", "dmesg": "
09:12 Tom^: ", "exception": null, "err": "", "__type__": "TestResult", "environment": "", "command": "", "time": {"start": 0.0, "end": 0.0, "__type__": "TimeAttribute"}}}
09:12 Tom^: yea hold your horses, i dont have optimus so i have to reboot each time i swap driver :P
09:13 hakzsam: yep...
09:15 Tom^: uhm says unknown parameter texturelodoffset but without it , it runs.
09:16 hakzsam: okay, please make a mmt of that test
09:18 Tom^: hakzsam: heh it got enormous , 359 mb
09:18 hakzsam: uhu
09:19 hakzsam: that's unexpected
09:22 Tom^: hakzsam: here https://www.dropbox.com/s/yne1ifk9j0f987g/nvidiammt.log?dl=0 i splitted it with the bas split command, into 20mb files. thats the first one.
09:22 Tom^: *bash
09:23 hakzsam: thanks
09:24 Tom^: if it holds anything of parseable value.
09:24 Tom^: i could try find another piglit test too
09:25 hakzsam: Tom^, yeah, that trace is weird :/
09:26 hakzsam: Tom^, are you still on the blob?
09:26 Tom^: yea
09:27 hakzsam: Tom^, what about this one bin/arb_compute_shader-local-id ?
09:27 hakzsam: (it's unrelated to the other issue)
09:27 hakzsam: but I just want to know if arb_compute_shader is correctly implemented :)
09:27 Tom^: doesnt seem to finish or run, just hogs the terminal waits.
09:28 Tom^: oh wait it was just slow
09:28 Tom^: PASS! :P
09:28 Tom^: il mmt it
09:28 imirkin: Tom^: make sure to run with -fbo -auto
09:28 hakzsam: Tom^, bin/arb_compute_shader-render-and-compute?
09:29 imirkin: Tom^: otherwise it just sits there waiting for you to hit escape
09:29 Tom^: imirkin: ah
09:29 hakzsam: imirkin, doesn't seem to be needed for this compute shader test btw
09:29 imirkin: these tests should take on the order of 0.1s to execute
09:30 imirkin: the tex-miplevel-selection tests are slow, but should still run within like 10s
09:30 hakzsam: local-id is actually a pretty long test
09:30 hakzsam: it does iterate a lot
09:30 imirkin: oh yeah?
09:30 hakzsam: yep
09:30 imirkin: sad
09:30 Tom^: hakzsam: https://www.dropbox.com/s/mmqpcl4vgmhqpnp/nvidiammt2.log?dl=0
09:30 hakzsam: Tom^, is that local-id?
09:30 Tom^: hakzsam: that is -local-id
09:30 hakzsam: thanks
09:30 hakzsam: Tom^, I bet render-and-compute won't work
09:31 Tom^: PASS
09:31 hakzsam: oh!
09:31 hakzsam: because it fail on fermi
09:31 hakzsam: Tom^, mmt of that one please?
09:31 hakzsam: this is going to be very useful
09:31 hakzsam: *fails
09:31 RSpliet: hakzsam: technically we fail in Fermi :-(
09:31 RSpliet: *on
09:32 hakzsam: RSpliet, it fails with the blob on fermi ;)
09:32 Tom^: hakzsam: https://www.dropbox.com/s/t3kb8hksiidhgnr/nvidiammt3.log?dl=0
09:33 Tom^: you underestimate the power of this kepler!
09:33 RSpliet: hakzsam: more like fermi support in nouveau tends to be worse than kepler in pretty much every way :-P
09:33 hakzsam: Tom^, yeah, thanks
09:33 hakzsam: RSpliet, that's right!
09:34 hakzsam: Tom^, the last one: arb_compute_shader-indirect-compute?
09:36 Tom^: pass! https://www.dropbox.com/s/afcf6c30r9mdk7i/nvidiammt4.log?dl=0
09:37 imirkin: RSpliet: really?
09:37 hakzsam: Tom^, thanks
09:38 imirkin: RSpliet: i'm aware of exactly one piglit test that fails on fermi but passes on kepler...
09:38 Yoshimo3743: RSpliet: fermi is something you could do something about ;)
09:39 hakzsam: imirkin, only one?
09:40 imirkin: RSpliet: afaik yesa
09:40 imirkin: er, hakzsam --^
09:40 imirkin: that stupid arb_transform_feedback3 draw-auto test
09:40 imirkin: or is it arb_transform_feedback_instanced... i forget
09:40 hakzsam: Tom^, bin/arb_pipeline_statistics_query-comp -auto -fbo ?
09:41 hakzsam: does it pass?
09:41 Tom^: nope arb_pipeline_statistics_query-comp: /home/tom/dev/piglit/tests/spec/arb_pipeline_statistics_query/pipeline_stats_comp.c:109: dispatch_size: Assertion `ok' failed. , core dumped.
09:41 hakzsam: okay, same as fermi
09:42 hakzsam: imirkin, I don't remember but I tought there was more fails on fermi
09:43 hakzsam: Tom^, okay, we still need to find a test which reproduces that read fault
09:43 Tom^: sure
09:43 imirkin: hakzsam: there was one other one i fixed in recent memory... something to do with a weird blit shader issue
09:43 imirkin: which only turned up on z32s8 blits... or something
09:44 imirkin: [or rather shader I/O misunderstanding...]
09:44 hakzsam: okay
09:44 imirkin: they changed the logic between fermi and kepler as to which registers to read MRT outputs from
09:45 imirkin: in a very subtle way
09:48 pmoreau: imirkin: ping :-) http://lists.freedesktop.org/archives/mesa-dev/2016-January/104014.html Did I missed some rules for submitting patches to Mesa? (This is my first one, so I definitely could have)
09:49 Tom^: which test is {"spec@glsl-1.50@execution@texelfetchoffset@gs-texelfetch-isampler1d" exactly?
09:49 Tom^: texelfetchoffset doesnt exist
09:49 imirkin: pmoreau: yeah, you missed a big one -- keep reminding me about things like that :)
09:50 imirkin: otherwise i forget
09:50 pmoreau: :-D
09:50 imirkin: pmoreau: patchwork link?
09:50 pmoreau: Should I CC you when submitting patches about Nouveau to Mesa, like I CC Ben for the kernel?
09:51 pmoreau: Hum… How do I get that link? :-D
09:51 imirkin: pmoreau: mmm... you can but you don't have to. i read mesa-dev.
09:51 imirkin: pmoreau: nevermind, i'll get it myself
09:51 Tom^: hakzsam: {"spec@glsl-1.50@execution@texelfetchoffset@gs-texelfetch-isampler1d": , but texelfetchoffset doesnt exist in bin :o
09:52 imirkin: pmoreau: here's your own personal link: http://patchwork.freedesktop.org/project/mesa/list/?submitter=15445
09:52 pmoreau: Thanks!
09:53 pmoreau: I guess it doesn't create account automatically, does it?
09:53 pmoreau: s/account/accounts
09:54 hakzsam: pmoreau, nope
09:54 pmoreau: K
09:54 hakzsam: Tom^, well, I'll have a look at this later, thanks anyway
09:55 Tom^: oki
09:59 imirkin: pmoreau: pushed
09:59 pmoreau: Thanks!
10:00 pmoreau: I'll have a look at the mysterious r0 with no instruction attached
10:02 imirkin: hakzsam: looks like you'll have to use a macro for indirect compute
10:03 imirkin: hakzsam: should be really simple, let me know if you have trouble with it and i can write it for you
10:04 imirkin: .... aaaand you won't be able to use the same one on fermi as on kepler+
10:05 imirkin: since one has to write methods, the other has to get data uploaded into the launch descriptor
10:16 hakzsam: imirkin, okay :)
10:16 hakzsam: imirkin, you looked at the indirect-compute mmt?
10:16 imirkin: no
10:17 imirkin: i just have a lot of clarity on all this macro business after futzing with it for all the indirect draw things i did
10:17 hakzsam: ah yeah okay
10:17 imirkin: which, ftr, were *not* done by copying the blob macros...
10:18 hakzsam: you did rewrite them?
10:18 imirkin: more like write, but yeah
10:18 imirkin: i modified the existing stuff
10:19 hakzsam: yeah, I saw that when looking at your series
10:19 hakzsam: but I didn't feel comfortable enough in that area to give a Rb :)
10:19 imirkin: yeah no worries
10:20 imirkin: that stuff is a little nuts
10:20 imirkin: it makes sense as you're writing it, but it can be hard to read
10:20 hakzsam: it is
10:24 hakzsam: imirkin, btw, you forgot to explain that compute.c is now broken with your "ureg support for image decls" thing
10:25 imirkin: heh
10:25 imirkin: the only 2 people who know about compute.c's existence know :p
10:26 hakzsam: hans will probably get troubles with that :)
10:26 imirkin: that's what he gets for not being on irc
10:28 imirkin: hakzsam: btw, all the deqp es 3.1 piglits use compute shaders :(
10:28 imirkin: hakzsam: can i request that you work on solving the uniform thing first so that i can create a merge-branch with all the various stuff and test ssbo using deqp?
10:29 hakzsam: imirkin, sure, but do you need this today?
10:29 imirkin: no, of course not
10:30 imirkin: but i'll need it to have confidence in my impl
10:30 imirkin: which i'll need before sending the rest of the series
10:31 imirkin: aaaand i probably need to write some double ssbo tests
10:31 hakzsam: okay, I'll do it tomorrow
10:31 imirkin: i'm sure that's all kinds of broken
10:44 pmoreau: (Using NV50_PROG_DEBUG=255) In the last program printed before the RA pass, only r10, r15, r16 are there and have each one def. All other LValues have no defs, except for r8, which has one, and is the one failing as it has no instruction attached
10:45 imirkin: how can it have a def without instructions?
10:47 pmoreau: No idea
10:47 pmoreau: It had one that got removed, and the def wasn't?
10:48 imirkin: i dunno, but it's the thing to figure out
10:48 pmoreau: None of the program version printed has an r8 in it. (there are some other "missing" as well).
10:49 pmoreau: Are there steps which do not print the program after running?
11:07 pmoreau: So it appears during the convert to SSA pass
11:35 pmoreau: imirkin: It's the SSA var of the input
11:35 pmoreau: (Which is r0 here, since it's a kernel)
11:36 pmoreau: Or rather, I didn't defined any input to the function, but one of the passes "reserved" r0 and put it as an input to avoid its content being lost
11:36 pmoreau: Now, where did it got its definition…
11:38 pmoreau: The pre-SSA input already had a def. I guess being a function parameter gives you one def?
11:41 pmoreau: One fix could be, after the pass removing system values, to check if r0 is used, and if not, remove it from the function inputs?
11:48 pmoreau: Hum… Could it be `tid = bld.mkMov(bld.getScratch(), arg, TYPE_U32)->getDef(0);` in `NV50LoweringPreSSA::visit()` which generates the def? But then, why is there no insn attached?!
11:54 pmoreau: Nop, it's `f->ins.push_back(arg)`: as `f->ins` is a vector of `ValueDef`, it will auto-construct a `ValueDef` from `arg`, and `ValueDef::ValueDef(Value *v)` calls `set(v)`, thus setting a def without any instruction
12:58 karolherbst: hakzsam: is there some documentation on those gallium_hud thingies somewhere?
14:32 phomes: do we have a big collection of nvbios that can be used to test new code in envytools/nvbios with?
14:34 karlmag: I've asked about getting nvbioses before. Then noone came up with any good reasons to keep loads of them around.
14:34 karlmag: so I think the answer is "no"
14:38 karolherbst: phomes: usually yes
14:39 phomes: karolherbst: something that I can get somewhere? Or are they just each own collection?
14:40 karolherbst: phomes: well depends on what you want to do, but usually you can also just open a PR
14:40 karolherbst: if something works for one vbios is most likely also work for all of them as long as you don't do strange stuff
14:42 phomes: karolherbst: I want to check if there are other record sizes used except for 3 and 5 in the IUNK21 table. And if the pattern I see in the contents for my cards also goes for other cards. Ultimatly with the hope to understand what is in the table
14:42 karolherbst: phomes: if you have an idea, use nvafakevbios and load the blob and see what have changed
14:46 phomes: karolherbst: I don't really. There are just some parts which seem to follow a pattern. Like the fifth byte being 0xc0 or 0x80 for otherwise blank entires etc. With more data I was hoping to find some clues.
14:47 phomes: I mostly just wanted to fix the warning I get when using nvbios and now that I am looking at it anyway I was curious about what might be in the table
14:49 karolherbst: there can be anything in it
14:51 phomes: karolherbst: ok - I guess looking at is pointless then. I just though it was something we did not know/care about yet.
14:52 karolherbst: mhh
14:52 karolherbst: usually if something is unknown it means nobody looked at it deeper or just didn't find what the table does
14:53 karolherbst: I mean this table is somehow important for _something_
14:56 phomes: That was my guess too. The table seems to be short. At least on my cards. 1 to 8 entries of 5 bytes each. That gave me some hope to be able to figure it out by looking at a large number of bioses.
15:43 john_cephalopoda: Hey.
15:44 john_cephalopoda: Will this commit go upstream eventually or will it be replaced with something that is less hacky? https://github.com/imirkin/mesa/commit/9fc207b9394c7b62c80b01994d97d3cfe9ce0971
15:44 john_cephalopoda: Seems to be still unmerged as of mesa 11.0.8
15:58 imirkin: john_cephalopoda: a real fix should already be upstream
15:58 imirkin: the fool-proofing of texbar
16:00 salamanderrake: anyone with a gtx 960 card get nouveau working with it?
16:01 john_cephalopoda: I got an NVIDIA Corporation GK106 [GeForce GTX 645 OEM]. 11.0.8 is showing that flightgear bug, with the added hack-fix it works.
16:01 karolherbst: salamanderrake: what do you mean by "working"?
16:04 salamanderrake: for a while, if I used the nouveau driver, it never worked, the screen was black, because the card wasn't supported.
16:04 karolherbst: well basic output should still work though
16:07 salamanderrake: there was nothing, the driver crashed I believe, but that was some time ago.
16:14 salamanderrake: I guess still only modesetting for the gm200+ cards
18:56 imirkin: salamanderrake: odd, modesetting should work. just no accel.