00:05 mlankhorst: indeed!
00:15 gnurou: mlankhorst: are you or mupuf_ able to perform a release?
00:16 gnurou: or who should I bother for that?
00:27 mupuf_: gnurou: I never made a libdrm release
00:28 mupuf_: mlankhorst: did you?
00:28 mupuf_: if not, maybe we could convince xexaxo to make one :D
00:30 mlankhorst: mupuf_: sure, but test first, if you're on debian check out its git tree, add upstream as a remote, merge it and build-test for the symbols
00:30 mlankhorst: although I think the symbol checks are merged now
00:31 RSpliet: allegedly xexaxo can be bribed with biscuits
00:31 mupuf_: ah ah, me? Booting a debian? It never seems to work :D
00:31 mupuf_: more seriously, it is not really convinient for me, I use arch
00:31 mlankhorst: haha
00:31 mlankhorst: chroot's fine too
00:34 mupuf_: what do you want to test?
00:34 mlankhorst: make dist is a good start, make sure the other stuff builds too by testing on arm, or just adding --enable flags
00:35 mupuf_: why would I need debian for that?
00:35 mlankhorst: you don't, but I used it because it warned on extra or missing symbols
00:35 mlankhorst: which was helpful
00:36 RSpliet: I'm sure that's just a compiler flag
00:37 mlankhorst: no because it builds fine, but if something like nouveau_bo_new is missing or somethng
00:40 mupuf_: RSpliet: biscuits? I want some!!
00:45 gnurou: well or maybe I will just wait until someone makes a release for any reason :P
00:45 gnurou: xexaxo:
00:46 gnurou: but if you don't mind doing one just for this, it would be great
00:47 xexaxo: gnurou: been waiting for an ack from the amd guys a bit to revert a broken feature. I guess I'll give them a final ping and revert it.
00:48 xexaxo: doing something else atm, so it will be in an hour or so.
00:49 gnurou: xexaxo: there is no hurry - thanks a lot!
00:49 mupuf_: xexaxo: thanks, I will give you a cookie at XDC!
00:49 gnurou: oh, I will probably be at XDC too
00:49 mupuf_: oh, speaking about this, I need to plan my trip!
00:50 gnurou: cookies for everyone!
00:50 mupuf_: wonderful!
00:50 mupuf_: not sure if I will give a talk yet
00:50 mupuf_: maybe on cpu usage on mesa?
00:51 xexaxo: mupuf_: one about dsa and all the fun it was :P
00:52 mupuf_: gnurou: wanna talk about nouveau on tegra? :)
00:52 mupuf_: xexaxo: I did all the easy parts
00:52 mupuf_: seriously, it was no hassle for me at all
00:52 airlied: xexaxo: I'd just revert it
00:53 mupuf_: program interface query was funier
00:53 mupuf_: especially writing the tests for it
00:54 airlied: xexaxo: bringing a udev dep on libdrm is probably something to discuss further on a list somewhere
00:54 mupuf_: oh, this patch
00:55 airlied: a talkin on how much typing ARB_internalformat_query2 would be good, *hint* *hint* :-P
00:55 mupuf_: airlied: come and make it yourself! In the 5 years I have been working on the graphics stack, I never met the DRM maintainer :D
00:56 airlied: I don't get out much :-P
00:56 gnurou: mupuf_: by XDC I might have something interesting to talk about
00:57 mupuf_: airlied: and when you do, you go to the linux conf au :)
00:57 mupuf_:is waiting on the next virgil update
00:57 airlied: mupuf_: oh I also go to Kernel Summit :-)
00:57 airlied: I'd rather go to XDC than KS
00:58 airlied: but someone has to take the bullet!
00:58 mupuf_: hehe
00:58 airlied: there was a time many years ago where I'd fly around the world for two days, but I can't handle it anymore :-P
00:59 airlied: I do hope to get virgl shipped in fedora 23
00:59 airlied: but the upstream merging is out of my hands
01:03 xexaxo: RSpliet: I occasionally enjoy an gummy bear or two. it's not just cookies :P
01:04 mupuf_: airlied: the 2d side is coming along nicely
01:04 airlied: mupuf_: yeah its no fun though :-P
01:05 airlied: like the 3d version we merge is probably at least half as slow as it could be
01:05 airlied: just to keep it simple to get upstream
01:05 mupuf_: good that you got some minions to work on it!
01:05 mupuf_: half as slow, sounds better than half as fast :p
01:05 airlied: moving all the ui/GL processing into a thread makes things a lot better
01:05 airlied: but is some serious qemu work
01:06 xexaxo: airlied: speaking of further discussion, how about we "depreciate" some of the functions, so that people know it's a bad idea to use ?
01:07 xexaxo: ... them
01:07 airlied: xexaxo: are any of them used in mesa or anywhere else that gets built regularly?
01:07 airlied: because it's a pain in the ass to get put warnings on people they can't fix
01:08 xexaxo: airlied: that's the discussion part of it. not 100% on which ones we should tag as such.
01:09 airlied: xexaxo: all the skiplist ones at least
01:09 airlied: I know the X server dri1 code still uses stuff though
01:10 airlied: probably better just having the kernel complain
01:10 airlied: people don't generally write code for libdrm on its own
01:12 xexaxo: I was thinking of 1) depreciate & fix (non ancient) users 2) libdrm3 with cleaned up API 3) 'depreciate' things kernel-wise
01:12 airlied: is it really that bad though?
01:12 airlied: libdrm3 would be a lot of churn for not much gain
01:12 xexaxo: if done nicely it will minimise the kernel regressions (reported)
01:13 airlied: people won't upgrade libdrm, the kernel regressions will always be there
01:14 xexaxo: afaict most of the churn will be getting devs' attention for input about the API.
01:15 xexaxo: unless libdrm3 changes the function/symbol names... which will nicely help on the kernel side.
01:16 xexaxo: and on that 'lovely' note I'll leave you gents for a bit.
06:00 mogorva: i have some games running in Wine that crash on start with nouveau (always the same backtrace, the problem is not present with the binary drivers), could it be a bug in Wine or in nouveau? Wine log+backtrace: http://pastebin.com/TDsv0ZTh
06:16 imirkin: mogorva: nouveau's a fairly safe bet. looks like the generic part of mesa though, shared by all gallium drivers... if you can get an apitrace of the failure, that'd be very helpful
06:18 mogorva: imirkin: should i use the win version of apitrace when tracing apps under Wine or the linux version will do?
06:19 mogorva: i mean the windows version of apitrace running in Wine...
06:20 imirkin: mogorva: linux version is fine... but you need the 32-bit one if you're on 64-bit userspace
06:21 imirkin: otherwise it won't work
06:21 imirkin: iirc there are some guides on how to apitrace wine
06:21 mogorva: on the other hand, the games don't crash when Wine is patched with the CSMT patchset
06:22 imirkin: the crash is a bug in mesa... would be good to fix it up
06:36 imirkin: mogorva: actually i have an idea of how to fix it... are you able to build patched mesa?
06:38 mogorva: imirkin: yes, that should work :) i can't figure out how to use the linux apitrace with a game running in Wine+Steam
06:38 imirkin: oh yeah, that took me a while too
06:38 imirkin: the trick is run steam
06:38 imirkin: and then MANUALLY execute the game's binary off of disk
06:39 mogorva: so start Steam in a terminal and when it's running I should run apitrace+the game in another terminal?
06:40 imirkin: this is the patch: http://hastebin.com/mowajoruha.coffee
06:53 mogorva: imirkin: the patch didn't resolve the crash, but now I'm getting a different backtrace: http://pastebin.com/rHzTMxUc
07:04 imirkin: heh, well it resolved *that* crash
07:04 imirkin: apparently there's some assumption that fprog is set
07:04 imirkin: and there is no fragment program
07:07 imirkin: hmmmmmmm by the looks of it, there should always be a fragment program
07:08 imirkin: mogorva: a trace would be really great
07:18 mogorva: imirkin: only a 290 kB file is generated, i think it's useless: https://drive.google.com/open?id=0B-tTbLKBl-tOcDMzX3B2cWdiNmM
07:21 mogorva: what am i missing? i started steam client in a terminal then in a separate terminal started the game executable like this: ~/sources/test/apitrace/build/apitrace trace ~/sources/wine-git/wine SkyDrift.exe
07:22 mogorva: the game starts then crashes, but the generated trace file is too small to contain any useful info
07:40 imirkin: does replaying the trace also crash?
07:41 imirkin: ermmmm... that's a d3d trace, not a GL trace
09:01 imirkin: calim: any opinion on which fix to go with for https://bugs.freedesktop.org/show_bug.cgi?id=90887 ?
09:02 imirkin: calim: i've had lots of trouble reproducing this on nvc0 using a "regular" program too, so dunno if i'm just doing it wrong or if it's just some condition unattainable through glsl
13:50 hakzsam_: imirkin, this series is for you this time :)
13:52 imirkin_: hakzsam_: yeah, looking...
13:59 imirkin_: hakzsam_: nouveau_perfmon_query_domains is confusing
13:59 hakzsam_: why?
14:01 imirkin_: hakzsam_: why does it query the thing twice?
14:01 imirkin_: hakzsam_: and it has that weird loop... some comments could def clear up wtf it's doing
14:01 imirkin_: esp for someone who's not really familiar with what the ioctl does in the first place
14:09 hakzsam_: well, the first time an iterator is initialized and this allows to query domain 0. Then, we query until the iterator is 0xff which means that no other domains are available
14:09 hakzsam_: the same behaviour is used for signals and sources
14:09 hakzsam_: and yes, maybe it would be better to add a comment there...
14:10 imirkin_: why the double querying though
14:10 imirkin_: and the prev_iter thing
14:10 imirkin_: it's all a bit confusing, esp when you don't know what kind of data it's getting back
14:10 hakzsam_: if you want, you can take a look at http://cgit.freedesktop.org/~hakzsam/nouveau/tree/drm/nouveau/nvkm/engine/pm/base.c?h=nouveau_perfmon#n428
14:11 hakzsam_: iter is input/ouput, name, signal and signal_nr are output only
14:13 imirkin_: why do you double-query?
14:14 imirkin_: wouldn't it be simpler to have the first query outside of the loop
14:15 imirkin_: and then have a while (iter != 0xff) { process; query again; } thing?
14:16 imirkin_: i won't bother asking what's with the random -1/+1's all over the nvkm code...
14:27 hakzsam_: well, the double-query thing is here because the nvkm code adds -1 to the iterator in order to be able to query the domain 0. The first time iter is initialized at 0, then we query (the first query in the loop), then iter is 1. The second time, we send the previous iter which is 1, the nvkm code adds -1 and it fills the nvif_domain struct with some information related to the domain 0. Yes, this is kinda strange actually...
14:28 hakzsam_: the code was there since a long time, I didn't change it
14:29 hakzsam_: I never tried to make it simpler :)
14:33 imirkin_: pretty sure my approach would work in one form or another
14:33 imirkin_: why not init iter to 1?
14:34 imirkin_: if you didn't write the code, i suspect skeggsb_ had some reasonable way to use it which was not this
14:35 hakzsam_: inits iter to 1 seems to work, yes
14:35 hakzsam_: maybe, but this is the same way used in nv_perfmon...
14:39 hakzsam_: well, if we init iter to 1 we should be able to move the first query outside of the loop
14:42 imirkin_: and get rid of the prev_iter nonsense...
14:44 hakzsam: imirkin, your approach will work but I'm not sure that makes sense to return -EINVAL if no domains are exposed by a device
14:45 imirkin_: you can handle it though right?
14:45 hakzsam: depends on what you want to do with that interface
14:45 hakzsam: yes, it's possible
14:46 imirkin_: and it'd exclusively happen on the first call
14:46 hakzsam: exact
14:46 hakzsam: and only if no domains are exposed
14:46 imirkin_: right
14:47 imirkin_: note that nouveau_screen is used by nv30 as well
14:48 hakzsam: I didn't know, but I trust you :)
14:48 imirkin_: you don't have to trust me, just look at nv30_screen.c ;)
14:48 hakzsam: looking
14:50 hakzsam: I don't find any stuff like that in nv30_screen.c
14:54 imirkin_: hakzsam: should be a nouveau_screen_init() in there
14:54 hakzsam: imirkin_, I'll make this change for signals and sources as well
14:55 imirkin_: sgtm
14:59 hakzsam: thanks for this first feedback!
18:36 Squidy: Hello.. Is there support for GM108 (840M)?
18:42 imirkin: Squidy: not really. you could add local patches to make it use the same stuff as GM107, and then it might work
18:43 skeggsb_: do we have any traces from gm108? it shouldn't be too hard to pull the gr init data out of it and add support
18:44 imirkin: skeggsb_: iirc there was one bug where i asked for one... iirc one was provided
18:44 skeggsb_: ok, well i'll add that to my list
18:44 imirkin: skeggsb_: https://bugs.freedesktop.org/show_bug.cgi?id=89558
18:44 imirkin: mmiotrace of running nvidia-smi, which i believe should have everything
18:45 buhman: https://bugs.freedesktop.org/show_bug.cgi?id=70354 :3
18:45 imirkin: Squidy: but if your goal is to use it for faster acceleration than your intel chip, nouveau's not the thing you want -- we can't reclock the chip so it'll stay in the lowest power level
18:48 Squidy: Then I need to try the proprietary driver... :-(
18:49 Squidy: bumblebee didn't work for me either
18:50 imirkin: bumblebee is not a graphics driver
18:50 Squidy: I know..
18:51 imirkin: i guess no one's benchmarked the lowest perf level of GM107/GM108 vs intel haswell or broadwell. would be interesting...
18:52 imirkin: pretty sure that for fermis it tends to be in intel's favor on speed
18:52 imirkin: and kepler has reclocking
18:54 buhman: pick me
18:54 buhman: imirkin: does doing that on nvidia count?
18:54 imirkin: buhman: doing what?
18:55 buhman: err, benchmarking
18:55 imirkin: oh... well no, the point is to compare to nouveau
19:44 yusukesuzuki: imirkin: hi! are you around?
19:44 imirkin: always
19:45 yusukesuzuki: imirkin: after discussion, finally, i get trap handler :D
19:45 imirkin: NICE!
19:46 yusukesuzuki: imirkin: the important part was (1): use NVIDIA's GR firmware and (2): use FIRMWARE[1] & SCRATCH[1] through subchannel :D
19:46 imirkin: yusukesuzuki: should be easy enough to teach the nouveau gr firmware about it
19:47 yusukesuzuki: (1) was necessary because FIRMWARE[1] & SCRATCH[1] are supported by NVIDIA's firmware.
19:47 yusukesuzuki: MP register setting timing is very critical, and basically, FIRMWARE[1] & SCRATCH[1] seem only the solution for that.
19:48 imirkin: yeah, because they're context-switched
19:49 yusukesuzuki: imirkin: to introduce trap handler functionality into gdev, i need to set CODE_ADDR globally before executing each kernel.
19:50 yusukesuzuki: imirkin: seeing the valgrind-mmt results onto official CUDA code, they set CODE_ADDR globally and use CP_START for each kernel execution.
19:50 imirkin: well, ideally the trap handler should be part of the code page that you generate
19:51 yusukesuzuki: imirkin: but, CP_START is limited in 32bit while NVIDIA accepts 40bit addr,
19:51 imirkin: yeah, CODE_START should point to the page(s) where all the code gets stored
19:51 imirkin: and the trap handler should be stored in those same pages
19:51 imirkin: you're not going to allocate more than 4GB for code text, so it's probably fine :)
19:53 imirkin: yusukesuzuki: it'd be awesome if you could contribute the kernel support back to nouveau/drm... if you're not sure how to make the fw modifications, no worries, we can do that separately
19:55 imirkin: skeggsb_: perhaps you can provide pointers on how to do that
19:55 yusukesuzuki: imirkin: that sounds very nice!
19:55 imirkin: skeggsb_: i guess it'd be easy to do with the SW object...
19:56 imirkin: skeggsb_: but nvidia does it via GR ctxsw fw somehow... they have special FIRMWARE endpoints which read from SCRATCH data (also in gr)
20:44 skeggsb_: imirkin: this gk106 is making me want to throw stuff
20:44 imirkin: skeggsb_: just don't throw the gk106 -- you'll never get another one
20:44 skeggsb_: i think lenovo would be upset, they do want it back :P
20:44 imirkin: skeggsb_: past indications suggest there's some funny timing situation
20:45 imirkin: perhaps s/mdelay/udelay somewhere?
20:45 skeggsb_: nvidia generally (but not always) use PTIMER, so delays are (usually) obvious
20:45 skeggsb_: but, it's possible
20:45 imirkin: skeggsb_: don't we have some msleep's in the pgob thing?
20:46 skeggsb_: yes, i'm about to fiddle there again
20:46 skeggsb_: i've just matched our devinit *exactly* to nvidia's and it didn't help
20:46 imirkin: except theirs worked
20:46 imirkin: so *something* different :p
20:46 airlied: add * 2 to all the sleeps :-P
20:46 skeggsb_: i'm just talking about the bios script execution atm
20:46 airlied: then / 2 :-P
20:47 imirkin: skeggsb_: gk104_pmu_pgob does use msleep
20:47 skeggsb_: yep, i know
20:47 imirkin: worth trying s/msleep/usleep
20:47 imirkin: (and *1000)
20:48 imirkin: [is ptimer working at that point in time? perhaps some sort of fail along those lines...]
20:48 imirkin: the pgob appears to happen pretty late in the game
20:48 skeggsb_: i'm currently suspecting some timing issue in there
20:49 skeggsb_: a bit of test code with nvidia's devinit hardcoded from a mmiotrace + test code uploading code to gpccs still shows intermittent failures with nvidia
20:49 skeggsb_: but, once it's worked once, if you remove the pgob crap it'll keep working even while still running devinit each test
23:14 yusukesuzuki: imirkin: ah, ok, after investigating nouveau, i've got it. maybe, (1) adding software method (modifying MP registers) into sw and (2) invoke it from pushbuf (like mesa's 0x06ac for power management), right?