02:54ouned__: so DRI_PRIME suddenly works on wayland but not on X anymore for me :o
03:01ouned__: ooh i just ran sudo xrandr --setprovideroffloadsink nouveau Intel and it suddenly works
03:01ouned__: even though it basically changed nothing
03:41ouned__: karolherbst: i fixed it
03:41ouned__: it was extremely easy
03:41karolherbst: ouned__: what was the problem?
03:41ouned__: randr --setprovideroffloadsink nouveau Intel
03:42ouned__: for some reason it isnt set by default
03:42ouned__: power monitor shows me ~40W @ pstate 0x0e
03:43ouned__: if thats of interest
03:43karolherbst: ouned__: yeah, I already assumed it was this
03:43karolherbst: that's why I send you the optimus link ;)
03:44karolherbst: ouned__: but if all your display connectors are wired to intel, you might want to setup yor X server for dri3, because then you don't need to do that anymore
03:44ouned__: i concentrated too long on it yesterday. fixed it in like 10 minutes this morning :D
03:45ouned__: they are.
03:46SaveTheRobots: not sure if this is the correct place to ask, but does anyone know the status of Mesa/nouveau's GLVND implementation?
03:47SaveTheRobots: co-existing nouveau/NVIDIA on the same system would be awesome :o
03:47karolherbst: I have nouveau/NVIDIA co-existing on my system
03:48karolherbst: I have no idea why distributions are messing this up, but there is no reason why this shouldn't work
03:48karolherbst: you don't need GLVND for that
03:50SaveTheRobots: which distro do you use?
03:51karolherbst: but it shouldn't matter
03:51karolherbst: some distributions are just plain stupid and overwrite your system libgl whenever nvidia gets installed
03:51karolherbst: even if mesa and nvidia are installed
03:51SaveTheRobots: what about your libGL/libEGL/etc?
03:51SaveTheRobots: doesn't each implementation share the same lib names?
03:51karolherbst: it's all mesa
03:52karolherbst: the files can be wherever they want anyway
03:52karolherbst: if you want to start an X server with nvidia, you just set the paths differently
03:52SaveTheRobots: so, app > mesa (libGL) > nouveau/nvidia(libGL.so.362.14 or whatever) ?
03:52SaveTheRobots: ahh, ok
03:53SaveTheRobots: do you know the status of GLVND anyway? because i know GLVND supports more than just co-existence of implementations
03:54SaveTheRobots: i.e. multiple X screens running different implementations
03:54karolherbst: I think there were patches, maybe they are already merged
03:55SaveTheRobots: ah ok, thanks :)
04:09mupuf: so, the piglit run yesterday was sort of a small disaster on the tk1
04:09mupuf: piglit got killed 4 times due to the OOM killer
04:09mupuf: I found the culprits and blacklisted the tests for now
04:10mupuf: but then nouveau also crashed
04:10mupuf: so, I upgraded the kernel to karol's reclocking branch which is pretty up to date
04:11mupuf: and the kernel booted just fine :) Trying again
04:11mupuf: and I will update mesa right after
04:11mupuf: in any case, piglit takes a shitton of time on the tk1
04:12mupuf: maybe I should upclock the gpu, that could help
04:12karolherbst: why my branch?
04:12karolherbst: it should have no affect on tegras
04:13mupuf: karolherbst: your reclocking one
04:13mupuf: and yes, no impact, but it is up to date
04:13mupuf: and it has both the new nouveau and matching linux tree
04:13karolherbst: well so has my master_4.5 branch
04:14mupuf: so, boot clocks are ... 72 MHz
04:14mupuf: oh well, your patches do not hurt
04:14karolherbst: they will in the future
04:14karolherbst: currently I mess around with therm
04:15karolherbst: making the alarm not cancelable and just trigger it every second even with manual fan mode and stuff
04:18mupuf: have fun!
04:18mupuf: now, I am stuck waiting for piglit to finish ... again :D
04:18mupuf: it takes hours
04:23karolherbst: does running them in parallel works?
04:27mupuf: I am not trying
04:27mupuf: it is not stable on normal platforms
04:27mupuf: so, I am avoiding this
04:31karolherbst: mupuf: I have a weird issue. after the first time the alarm is triggered in therm, it takes like 5 seconds for the second one
04:31karolherbst: but then it triggeres every second
04:32mupuf: well, it is 4.3s actually
04:32mupuf: for the counter to overflow
04:32mupuf: and then it works
04:32mupuf: so, you have an issue in the scheduling code
04:33karolherbst: uhh now it was the second and third time
04:33karolherbst: yeah, 4.3 seconds
04:33karolherbst: ohh, this happens quite often actually
04:34karolherbst: mupuf: where is this overflow?
04:34mupuf: it is PTIMER's time
04:35mupuf: the ALARM counter is 32 bits
04:35karolherbst: I see
04:35mupuf: have a look at how it works
04:36karolherbst: nvkm_timer_alarm(tmr, 1000000000ULL, &therm->alarm);
04:36karolherbst: isn't ULL like 64bit?
04:37karolherbst: well, the number is 32, but the literal should be still wrong
04:43karolherbst: nice, very nice, now that I want to debug this, it doesn't trigger anymore
04:46mupuf: what is also nice is that I am half-way through the piglit run and it is still running
04:46mupuf: hurray for upstream kernels
04:49karolherbst: yay :)
05:28mupuf: real 80m55.092s --> piglit run on the tk1
05:29karolherbst: that's pretty fast though
05:30mupuf: all in one go, no crash
05:30mupuf:is setting up the system to upload the results on piglit.mupuf.org and show the difference
05:31karolherbst: is there any difference in the rendering pipeline by any chance? Or should the results be just like any kepler2 card?
05:31mupuf: we'll see :p
05:31karolherbst: mupuf: I don't know which gpus hakzsam currently need in reator, but I would need a kepler2 or newer
05:32karolherbst: I want to look into the clock changes
05:32mupuf: kepler 2?
05:32mupuf: I can get rid of the tesla card
05:32karolherbst: SaveTheRobots got a stability issue with my patches
05:33karolherbst: and for the same clock, nvidia uses two different PLL configurations depending on the temperature
05:33mupuf: i plugged a GK208
05:33karolherbst: and changes the new bit the same time
05:33mupuf: MOAR PHUN!
05:34karolherbst: I think it is a pre PLL think though, because it seemed that way
05:34mupuf: I wonder if I should create a git repo with gitolite so as all of you can push stuff there
05:35mupuf: and get rid of the useless results
05:35karolherbst: noooo those pastes are purged...
05:35karolherbst: well at least I know what changed
05:35mupuf: and make your own comparaisons
05:36karolherbst: it has an affact on the N parameter somewhat
05:36karolherbst: N+1, new bit -1
05:36karolherbst: or something like that happened
05:38karolherbst: mupuf: would be nice
05:43mupuf: karolherbst: right, this freaking bit
05:43mupuf: you can use reator right now if you want
05:43karolherbst: mupuf: by the way, did you find some time to look into the new Fan table? It would be interessting to see if the blob really does behave like I guessed it would
05:43mupuf: nope, I have not checked
05:44mupuf: but I need to check there if there is a bit telling me to not use the PWM controller in the same way
05:44karolherbst: mupuf: I think the table should be used in the case where you fixed Tom^s fan stuff?
05:44mupuf: not sure what you are talking about
05:44karolherbst: well unknown mode bit for the fan
05:44karolherbst: could mean use this table
05:46karolherbst: I think there was a correlation between the unknown mode and the table being there, but I checked like three months ago
05:47karolherbst: mupuf: are there still network problems with reator by the way?
05:47karolherbst: sometimes I get small lags
05:47mupuf: karolherbst: yeah, still terrible modem...
05:48mupuf: I really need to contact my provider and complain loudly about this
05:48mupuf: this is the internal network that sucks
05:48karolherbst: ohh okay
05:48mupuf: I would need to try to use my main pc as a gateway
05:48hakzsam_: oh Alien isolation requires compute shaders, that's cool
05:48karolherbst: like in requires?
05:48karolherbst: or requires for good perf
05:49hakzsam_: "Additional Notes: NOTE: AMD and Intel graphics cards are not currently supported by Alien: Isolation. Game requires at least OpenGL 4.3 "
05:50karolherbst: nice, the new regs are there on gk200 as well :)
05:50karolherbst: hakzsam_: well, I wouldn't expect too much from this
05:51karolherbst: 4.3 has a lot of new stuff, maybe they just use something else
05:51hakzsam_: they use compute shaders
05:51karolherbst: ohh okay
05:55hakzsam_: and probably something else yeah
05:55hakzsam_: but this game will be a good test :)
05:57karolherbst: doesn't clk show up in nvatiming?
06:02karolherbst: mupuf: could you plug in a maxwell1? somewhat the reg doesn't do much on the nv108
06:03mupuf: it boots
06:03karolherbst: looks good
06:16karolherbst: does nvatiming work on maxwell?
06:25RSpliet: karolhebst: doesn't it?
06:25karolherbst: not really
06:27RSpliet: karolherbst: I take it the clocks aren't all supposed to be 625MHz?
06:27RSpliet: PVDEC/PPPP are reported 0 on Kepler as well iirc
06:28karolherbst: look closely
06:28karolherbst: these are more like 3.135GHz
06:28RSpliet: oh yes
06:28karolherbst: 0xbadf1100 in hex
06:28mupuf: karolherbst: hehe
06:29RSpliet: you might want to triple-check the conditions in the code? I was also expecting PARTs and GPCs
06:29RSpliet: (or is that Fermi-only?)
06:29mupuf: RSpliet: yeah, very likely that the code is doing the wrong thing on maxwell
06:29mupuf: this code has been written for tesla first
06:29mupuf: then fixed for fermi
06:30karolherbst: it is really annoying that glxspheres64 is getting slower over time...
06:31mupuf: what do you mean?
06:34karolherbst: SaveTheRobots: are you there?
06:43karolherbst: silly issue
06:44karolherbst: spot the mistake: https://github.com/karolherbst/envytools/blob/master/nva/nvatiming.c#L544
06:45karolherbst: this looks better right? https://gist.github.com/karolherbst/1831e77903fdf4f8b152cb2b918f98bf
06:46mupuf: much much better
06:46karolherbst: well I will replace that == 0xc0 with >= 0xc0 if that's okay for you :D
06:53karolherbst: what the heck
06:53karolherbst: that's odd
06:53karolherbst: mupuf: perf counters stayed the same, but 750 => 970 fps
06:54karolherbst: the hell...
06:55karolherbst: ohh wait
06:56karolherbst: which one is clk0?
07:00karolherbst: only clk0 has this new reg
07:00karolherbst: all the others not
07:01karolherbst: which is gpc
07:03karolherbst: gpcs is badf5000
07:04karolherbst: what a coincidence
07:04hakzsam_: karolherbst, can I use reator? I would like to work on images
07:04karolherbst: yeah in a sec, just want to verify something
07:05karolherbst: now that I got the gpc clock
07:05hakzsam_: fine by me
07:05karolherbst: mupuf: k, it works now
07:06karolherbst: mupuf: we have to fix the GPC stuff for nvatiming though
07:06SaveTheRobots: hi karolherbst, here now
07:06mupuf: karolherbst: not too surprising
07:06karolherbst: SaveTheRobots: yeah too late :p
07:07SaveTheRobots: hehe ok :P
07:10karolherbst: hakzsam_: I will be done in like 5 minutes if that's okay for you
07:10hakzsam_: perfect, thanks
07:10karolherbst: that bytes are signed
07:11karolherbst: and weird
07:11karolherbst: k, whatever
07:13karolherbst: mupuf: any ideas? https://gist.github.com/karolherbst/7f6828cd93ef90c39d89fafc5c5bafa2
07:13karolherbst: up to 5 it makes sense
07:13karolherbst: then it becomes a little strange
07:13mupuf: what is the normal variance on the result?
07:14karolherbst: a-f and 0-5 are solid
07:14karolherbst: mupuf: a fewkhz
07:14karolherbst: *few khz
07:14karolherbst: like -+ 50 hkz
07:15karolherbst: yeah, all values for a-f and 0-5 make sense
07:15mupuf: I would suggest you truncate to 100 kHz then
07:15mupuf: why do they make sense?
07:15karolherbst: 12.5 khZ steps
07:15karolherbst: ohh wait
07:17mupuf: karolherbst: looks like a signed 4 bit value?
07:17karolherbst: more fun
07:17mupuf: I mean, a -> f then 0 -> 6 is strictly increasing
07:17karolherbst: there are another 4 btis just like that
07:18karolherbst: ohh no, false alarm, the other byte doesn't seem to do that much
07:19karolherbst: hakzsam_: it's yours now
07:19karolherbst: mupuf: yeah
07:20karolherbst: the other values are a bit odd though
07:21karolherbst: SaveTheRobots: there is one thing you could do though. on blob at full load: nvaforcetemp 20; sleep 5; nvapeek 137004; nvapeek 13700c; nvaforcetemp 70; sleep 5; nvapeek 137004; nvapeek 13700c
07:25karolherbst: okay, where do I get the gpcs count...
07:29karolherbst: nice how that doesn't work on my gpu
07:30karolherbst: ohh wait
07:32karolherbst: one moment
07:32karolherbst: this is... odd?
07:33karolherbst: nouveau: GPC set 0: 107797780 Hz
07:33karolherbst: nvidia: GPC set 0: 196982635 Hz
07:33karolherbst: that's a pretty huge difference if you ask me
07:34karolherbst: the hubs have the same clocks though
07:38karolherbst: oh maybe this thing doesn't work as intented here
07:41karolherbst: okay, the right data is inside PART now
07:50karolherbst: hakzsam_: as it looks like I would need reator later again :)
07:50hakzsam_: karolherbst, we can schedule :)
07:51karolherbst: just tell me when you want to do a break or something, I think I will need it for around 15 minutes
07:54mupuf: hmm, adding hooks to gitolite is a bit annoying
07:54karolherbst: I thought there is a per repository thing for this
07:57mupuf: actually, it did work
08:02mupuf: for some reason, it really does not want me to do anything from this hook :o
08:11karolherbst: mupuf: do you think it makes sense to optimize the therm timer to only continue when the new temperature differes from the old one?
08:20mupuf: no, make it check every second
08:20mupuf: hakzsam_: ok, pushing the the piglit_results repo automatically updates http://piglit.mupuf.org/results
08:21hakzsam_: where is the html summary?
08:21mupuf: now, I need to add code to automatically generate the summary
08:21mupuf: but it will be a script inside the piglit repo
08:21mupuf: so people can fix it
08:21mupuf: because it will never work for all situations, so let's keep it simple and not push logic on the server
08:22hakzsam_: right, cool
08:23mupuf: and for now, that will actually be it since I have an enormous backlog of finnish exercises!
08:23hakzsam_: it's a good start :)
08:24hakzsam_: we can now keep trace of piglit results
08:24hakzsam_: so it's pretty nice
08:24mupuf: but anyone is free to create the script that will create the summaries
08:24mupuf: I just want one script at the root that will generate all the summaries
08:25mupuf: hopefully, the repo size won't get enormous because the html files can definitely become super large
08:25mupuf: if it happens, we can always delete the history
08:25mupuf: it is not like we care that much
08:26hakzsam_: what? you want to add the html files in the repo?
08:26mupuf: so as everyone can add any summary they want
08:26hakzsam_: I think we only want the result files
08:26mupuf: you just need to change the script at the root and everyone will run this script
08:26mupuf: do we? or do we want the comparaisons too?
08:26mupuf: I say we also need the comparaisons
08:27mupuf: like what ilia has
08:27hakzsam_: sure, but this can be auto generated with a hook to avoid storing the html files in the repo
08:28mupuf: yes, but do we already know what we want?
08:29hakzsam_: not sure about that :)
08:29mupuf: right, so let's start like that :p
08:29hakzsam_: up to you
08:33mupuf: maybe we can also trim and keep only the most interesting files
09:03mupuf: hakzsam_: can you please upload some piglit results?
09:03martm_: kinda thought about backup ideas of hw methods, documentation and code seems to refer that there two cache regions mostly
09:04hakzsam_: mupuf, will do
09:05martm_: <array offset="0x1000" length="1" stride="0x200" name="CACHE0"> it has methods like put and pull, so surely such functionality should work
09:06martm_: i did look gallium side of things how to add scratch regs too, but dunno when i get back to it at the moment
09:11hakzsam_: mupuf, pushed
09:11martm_: so there is a minor idea needed how to get the pfifo channel into, recursion, i.e how to get that method executed from the shader, so if the bit of some sort arrives to scratch reg, it has to execute pul methods
09:11mupuf: hakzsam_: cool , multiple versions of the same card too?
09:11mupuf: that would help
09:12hakzsam_: mupuf, I'll push an other report for g94 but with mesa 11.1.2 this time
09:12hakzsam_: mupuf, err, I don't have, sorry
09:12imirkin: hakzsam_: btw, with the patch i pushed out, that should fix a bunch of issues on nv50
09:12mupuf: hakzsam_: ok, no worries
09:12imirkin: hakzsam_: https://cgit.freedesktop.org/mesa/mesa/commit/?id=3610b1466d573983d80e3019e8e01ebb97d67d9c
09:12mupuf: doing a second run on my hsw
09:12hakzsam_: imirkin, I saw it already
09:13martm_: then write the scheduler properly
09:14martm_: not much of an expert on ringbuffers, still have one loose end there, if the shader executes, ringbuffer still queus the commands of other state probably
09:14martm_: and also, need to look some radeon ringbuffer reg polling methods
09:15martm_: they probably allow to continuously poll, and execute something arbitrary on reg change
09:17mupuf: hakzsam_: actually, you are right, no need to store the html files in the repo! I can jus keep the script in the repo and let the server re-generate all the html files
09:18imirkin: so unfortunately the existing html summary thing isn't really good at dealing with large quantities of stuff
09:18imirkin: someone needs to write a html5-friendly viewer for that stuff
09:19hakzsam_: yeah, and it's pretty slow when you want to see all results
09:19mupuf: we have an internal thing at intel, the managers are ok with releasing it, but the engineer who wrote it has to clean it first
09:19mupuf: it is quite nice
09:19imirkin: mupuf: btw, i saw in Yoshimo's results that some MS-related stuff was extra-busted on maxwell. and also ARB_shader_draw_parameters is (mostly?) broken...
09:20mupuf: imirkin: there is a maxwell in reator, if you want to have a look
09:20imirkin: hm ok. i might later. which maxwell?
09:20mupuf: 750 GTX
09:24imirkin: i noticed i broke DSQRT on there, but that's all fixed now :)
10:31mupuf: ok guys, I created a new repo called piglit_results. Please push your piglit results there, following the current architecture. Please however give good names to reports (arch-gpu-version)
10:31mupuf: then, you may visualize the reports by running gen_reports.sh
10:31imirkin: errr... you want a git repo with all the results files??
10:31imirkin: imho it shouldn't be in git
10:31imirkin: [or put another way, i don't plan on looking at such a repo...]
10:32mupuf: I will have my server generate that soon. The results are pushed here: http://piglit.mupuf.org/results/
10:32mupuf: imirkin: what else? Want me to give everyone ssh access to my server?
10:32imirkin: mupuf: well, you already do, via the git repo :p
10:33imirkin: mupuf: could set it up so that we sftp stuff up
10:33mupuf: not exactly, you do not get bash ;p
10:33imirkin: the account can be restricted to sftp-only
10:33mupuf: what is the problem with git? Make a shallow clone and you will not have overhead :s
10:33imirkin: not the right tool for the job
10:34imirkin: anyways, obviously feel free to do whatever
10:34mupuf: well, how do you want to trigger a re-gen of the html
10:34imirkin: dunno. cron job?
10:34imirkin: [that checks for new files]
10:35mupuf: seems like a lot of work for almost no benefit :s
10:35mupuf: and I would have to have this sftp account
10:35mupuf: do account management
10:35imirkin: you have that with git now
10:35mupuf: (who has the password?)
10:35imirkin: sftp = "ftp" over ssh
10:36mupuf: yes, but I do it in one place, with ssh keys
10:36mupuf: oh, right
10:36imirkin: (not really ftp, but ... sorta.)
10:36mupuf: not ftps
10:36imirkin: no, not ftps.
10:36imirkin: same letters, different order :)
10:36imirkin: order matters! :)
10:36mupuf: so have I been told
10:36mupuf: but life is hard, for dislexics
10:37imirkin: dyslexics, untie!
10:37mupuf: ah ah
10:37mupuf: anyway, this is v1 of the idea, let's try and see if it works
10:37imirkin: i'm always reminded of that passage in le bourgeois gentilhomme
10:37imirkin: [that i had to memorize at one point or another, maybe that's why i'm reminded of it]
10:37mupuf: what was it?
10:37imirkin: where he rotates the words in a sentence
10:37mupuf: oh, hmm
10:38imirkin: hold on, let me find it
10:38mupuf: I only remember the part where he says that the noble knew everything and only needed to be reminded of them
10:41mupuf: oh wow, I had forgotten this part
10:42mupuf: anyway, we at least have a way to generate piglit results!
10:42mupuf: on the tk1
10:43mupuf: since it is under-utilized, we can use it for at least this
10:43imirkin: have you generated them anywhere yet?
10:43imirkin: also, does your thing update piglit as well as mesa?
10:43mupuf: yes, the one for 11.1.2 is in the repo
10:43mupuf: no automation yet
10:43imirkin: and is your vision to do it for released versions only
10:44imirkin: or daily on top-of-tree?
10:44mupuf: nope, every day
10:44imirkin: k, cool
10:44mupuf: this week end, I just figured out out to run piglit without crashing the board
10:44mupuf: I had to update the kernel to be able to do that
10:44mupuf: and blacklisted 4 tests
10:45imirkin: what kernel are you on, and which tests?
10:45imirkin: my board dies within about 5-10 minutes of use
10:45mupuf: 4.5 something
10:45imirkin: don't even have to load nouveau, it just hangs
10:45mupuf: mine is fine
10:45mupuf: and you have access to it, port 2223
10:45imirkin: ah nice
10:45imirkin: wait, is it on now?
10:46imirkin: hm, i might get etc2/astc going on it then
10:46imirkin: ben redid all the texture stuff
10:46imirkin: so i need to redo those patches
10:46mupuf: piglit-run.sh in /root is how I run piglit
10:46mupuf: I will let you poweroff the tk1 when you are done
10:46imirkin: nah, power it off now
10:46imirkin: not sure when i'll get to it
10:46imirkin: how do i power it on?
10:47mupuf: wtrpm, as usual
10:47imirkin: ah nice
10:47mupuf: i'm off to do my finnish exercises, ttyl
10:47imirkin: see ya
11:19hakzsam_: imirkin, did you see my ping for the edgeflag on nv50? :)
11:21imirkin: i did.
13:19imirkin: skeggsb: thoughts on adding libdrm functions to expose ->vram_used/->gart_used?
13:21imirkin: skeggsb: and also keeping track of num_bytes_moved in the kernel just like radeon/amdgpu does?
14:07imirkin: hakzsam_: how are images going? done yet? :)
14:08hakzsam_: not yet, still have to fix 1d array/cube array, some format conversions, but it's like 90% for both deqp/piglit :)
14:09imirkin: what's the fermi/kepler situation?
14:09hakzsam_: this was for kepler
14:09imirkin: ah ok
14:10hakzsam_: for fermi, this should be 70% or something
14:10imirkin: well, fwiw i think the majority of usage is for buffer and 2d images
14:11hakzsam_: most likely
14:11hakzsam_: I'll first add images support for gk104 and go back on fermi later
14:11imirkin: [buffer because images came out before ssbo did]
14:15hakzsam_: oh and I have to implement OP_SUQ, but this one is easy
14:16imirkin: should just be able to lower it into constbuf loads
14:16imirkin: probably have to do it on fermi as well
14:23hakzsam_: right, just need to load the dimensions from the driver cb
14:29imirkin: and unfortunately there are no real tests for this, but eventually we should support MS images
15:35mupuf: imirkin, hakzsam_: OK, just had a minute and I added support for auto-generating the reports when pushing
15:35mupuf: the only problem is that it takes ~5 minutes even with only a few reports :o
15:35imirkin: yeah that script is pretty horrid
15:36mupuf: and if someone commits something in the mean time, it will erase stuff in the process, so I need locking here
15:36mupuf: or cancelling the previous run
15:36mupuf: imirkin: you mean gen_report.sh? It is bad yes, but if you have suggestions, I am all ears
15:38mupuf: in any case, it should already do most of what we want, which is comparing different versions of mesa for the same gpu
15:38imirkin: not gen_script.sh. i mean piglit-summary-html.py
15:38imirkin: which is what i assume you're running
15:38mupuf: then comparing different gpus of the same family (picking the latest results of each gpu)
15:39mupuf: and then, the soon-to-be-added, comparing gens/architectures
15:39mupuf: yes, this is what I run
15:39mupuf: on an anemic processor
15:40imirkin: it's slow on my i7-920
15:40mupuf: I wonder where it is slow
15:41mupuf: there are great tools for improving the performance of python scripts
15:41imirkin: it's slow because it generates a BAJILLION files
15:41mupuf: but I am not going to check it out now, now is time to sleep :p
15:41imirkin: run it with -e pass -e skip
15:41imirkin: that should speed it up by a factor of 10
15:41imirkin: making it only extremely slow
15:41imirkin: not incredibly extremely slow :)
15:45mupuf: it does not seem to be doing anything
15:46imirkin: it should avoid generating results for pass/skip's
15:46imirkin: you probably have to list those args towards the front
15:46imirkin: not sure how well its argument parser works
15:47mupuf: yes, I had to
15:47mupuf: and actually, it did work and cut the generation time by a factor of two
15:47mupuf: so, let's use it
15:47imirkin: hehe :)
15:47imirkin: i guess the factor of 10 was off then
15:47mupuf: still good :p
15:48mupuf: 3.6 times less storage too
15:49karolherbst1: mupuf: soo f seems to be the base value somewhat
15:50karolherbst: but I have no big idea how the reg actually modifies the clocks
15:50imirkin: mupuf: i also usaully delete all.html and a few of the others
15:50imirkin: coz they're big and useless
15:50imirkin: er, index.html
15:51karolherbst: mupuf: could you plug the nv118 again? then I could check what nvidia does actually
15:51mupuf: imirkin: yes, I do not really care about bw though
15:52imirkin: mupuf: it loads very slowly in the browser
15:52imirkin: defaulting to problems.html would be my preference
15:52mupuf: yes, agreed
15:53mupuf: ln -s problems.html index.html would do it
15:53mupuf: so, let's see how slow it is going to be to generate now with the new options
15:53mupuf: it was averaging at 2 minutes / report
15:54mupuf: it is ridiculously slow :D
15:54mupuf: and IOs are not the issue here
15:54imirkin: this is very bad
15:54imirkin: i can't repro on nvc0
15:54imirkin: [well, nvc1]
15:55mupuf: karolherbst: I plugged the GK208
15:55karolherbst: thanks a lot
15:55mupuf: imirkin: reator has a GK208 and GK106 now
15:55mupuf: if you have to have a look
15:56imirkin: doh ok
15:56imirkin: i was going to see stuff on the maxwell later. oh well
15:56mupuf: imirkin: I can plug it back again tomorrow morning
15:56karolherbst: it passes for me on nve7
15:57imirkin: i'll just check on GK20A and hope for the best
15:57imirkin: i won't really have time during the week
15:57imirkin: i don't even really have time now
16:02mupuf: imirkin: maybe it is fixed
16:02mupuf: this was on the distro-provided mesa
16:02mupuf: I did not even recompile it
16:03mupuf: and this is using gbm also
16:03imirkin: hmmm... gbm is more likely the cause of the problem. let's see
16:03mupuf: which is not only faster, but also works without any x server or wayland compositor
16:03imirkin: hm, nope
16:03imirkin: funny that you were having trouble with getteximage-depth
16:04imirkin: iirc skeggsb also had it crash some stuff for him
16:04imirkin: i thought we fixed it
16:04mupuf: yeah, it was blocking
16:04imirkin: or maybe it magically fixed itself? i forget
16:04mupuf: but maybe it was an artefact of running an old kernel
16:04mupuf: because many issues disapeared when running a newer kernel
16:05imirkin: ah yeah, could be
16:05karolherbst: mupuf: I think we have to move the therm alarm into an own kworker, otherwise can't update the clock state without risking to deadlock :/
16:05imirkin: he fixed a bunch of stuff in the kernel
16:05karolherbst: any reasons why this is a bad idea?
16:05imirkin: at least re recovery
16:05mupuf: karolherbst: OOT nouveau does not have kworkers
16:05karolherbst: well I meant those worker thingies
16:05mupuf: but yeah, we should be using workers and or threads
16:06mupuf: out of the tree nouveau won't support them
16:06karolherbst: then I also clean this thing up
16:06mupuf: so, you need to reimplement the API
16:06karolherbst: yeah well
16:07karolherbst: I meant the work_struct thingies
16:07karolherbst: they are already used
16:07mupuf: not for low level stuff, right?
16:07mupuf: nv_init never calls it, right?
16:07karolherbst: it is inside the struct
16:07karolherbst: but no idea if it works indeed
16:08karolherbst: now that I think of it
16:08mupuf: anyway, time for me to sleep
16:08karolherbst: this is so messy...
16:08mupuf: have fun with reator
16:08karolherbst: therm calling into clk to update clocks and volt
16:08mupuf: please try to have a look ASAP
16:08karolherbst: yeah, I planned to do it tomorrow
16:09mupuf: no idea if I can change the cards tomorrow
16:09mupuf: will either be at my place or ... someone else's :D
16:10mupuf: well, nothing new. Usually, I would drop by my place when you need a change before heading out
16:10mupuf: so, let me know and I'll see
16:10mupuf: take care!
16:10karolherbst: I am fine with the gk208
16:12mupuf: otherwise, I can plug the GK208 and maxwell
16:12mupuf: samuel should be OK with this
16:12mupuf: yeah, ;let's do this
16:13imirkin: well, hakzsam_ has been doing images stuff on kepler
16:13mupuf: imirkin: reator has the GTX 750 back, along with the GK208
16:13imirkin: GK208 has a differnet isa
16:13imirkin: so his stuff won't work with that
16:13imirkin: although it'll be a good opportunity for him to find the instructions :)
16:13mupuf: so, kepler 1 only
16:14mupuf: well, it does not seem like a bad idea, he'll complain to me if it is annoying and I will switch it back
16:14mupuf: as you said, 3d and cube images are not the most important types anyway
16:14mupuf: see ya!
16:32karolherbst: there is actually a worker implementation
21:11imirkin: gnurou: on a scale of 1 to 10, how confident are you that ASTC should work on GM107?
21:11imirkin: er, that ETC2 should work there
21:13gnurou: imirkin: I'd say 9, to keep an error margin
21:13imirkin: meaning... confident?
21:13imirkin: well, it's not working :)
21:14imirkin: nouveau 0000:01:00.0: gr: GPC0/TPC0/TEX: 80000009
21:14imirkin: which iirc means "this is not the format you're looking for"
21:14gnurou: does it work with gk20a?
21:14imirkin: well, not THAT specific test, but other ones appear to
21:15imirkin: i tried both header types on GM107
21:15gnurou: when you use the new header type, have you added the method to specify you are using the new format to the pushbuffer?
21:15gnurou: (can't remember its name)
21:16imirkin: we default to using the new header type on GM107 now
21:16imirkin: [the blob does too, it seems]
21:17imirkin: maybe it's GM20x only?
21:17imirkin: both astc and etc2 seem to give me errors on GM107
21:18imirkin: in case you're curious [and/or have hw handy], this is the patch: https://github.com/imirkin/mesa/commit/9e485e38490b7e90151f4a673f1ff4900fd41d4e
21:19imirkin: and this is a piglit: bin/oes_compressed_etc2_texture-miptree rgb8 compat -fbo -auto
21:19gnurou: this is kind of outside my (narrow) area of expertise, but what I have seen indicates that it should work
21:19gnurou: have you been able to try with a GM2?
21:19imirkin: the most recent gpu in my arsenal is GK208
21:19imirkin: maybe mupuf can plug one in
21:20gnurou: GM1 should be close to Kepler, so maybe the new texture formats are not handled until GM2?
21:20imirkin: distinct possibility :)
21:20gnurou: just like in Kepler, only gk20a can handle ETC2, amirite?
21:21gnurou: that's one possibility, for I cannot picture why this wouldn't work otherwise
21:22gnurou: testing on GM2 sounds like a good way to challenge this theory
21:22gnurou: if it works, then the odds are high that GM1 does not support new formats compared to Kepler
21:22gnurou: (again, not my cup of tea - what I say may be complete nonsense)
21:23imirkin: what you're saying makes complete sense
21:23imirkin: i was just hoping you'd have the info available to you in an easy-to-consume way, but i guess not
21:23imirkin: (or that info is wrong)
21:23gnurou: that must be by accident
21:23imirkin: (or i'm messing something up)
21:28gnurou: mmm, found more evidence that suggests ETC2 is not supported on GM1... and maybe even GM2, excepted GM20B
21:31imirkin: and i assume ASTC falls into the same bucket?
21:32gnurou: looks like for K and M, only Tegra can use these
21:32gnurou: you will want to verify on GM2 though, as my information might not be the latest and freshest
21:33imirkin: "for K and M"?
21:33imirkin: oh, kepler and maxwell
21:33imirkin: i'll push something out that should make it easier for people to test
21:36gnurou: sorry also about the Github questions, I will push this forward, it's just that it takes time and I have to keep up with my regular tasks as well... >_<
21:37gnurou: still trying to understand clocks after weeks working on them 0_o;
21:37gnurou: being stupid doesn't help when you need to develop GPU drivers T_T
21:38imirkin: somehow i doubt that's your issue :p
21:38imirkin: and yeah, no worries on the github questions... just would be nice to know what step of the process they're in
21:40imirkin: ok... pushed... if someone with a GM20x wants to uncomment the obvious chunk in nvc0_screen.c:is_format_supported to see if ETC2/ASTC are supported by the hw, that'd be nice