01:29 mupuf: gnurou: yep...
01:30 mupuf: have fun getting the PMU loaded!
01:39 AndrewR: cool ...apparently new virglrendere broke nouveau more completely ..I think this commit caused this: https://cgit.freedesktop.org/virglrenderer/commit/?id=c59eddf16e8398dbadd336cbfdb8b9bf81d092d1 - because I saw few "unhandled texture:" messages unseen before, and rendering become even more unreadable (rainbow squares and rectangles instead of windows and text). Currently recompiling qemu, but then I'll try virglrenderer with this commit reverted .....
02:16 gnurou: mupuf: well, that's brilliant indeed
02:17 mupuf: gnurou: how much work do you think it will be?
02:18 mupuf: Technical work first, internal fights to get the fw outs second
02:18 mupuf: you already did it for the gk20a, right?
02:19 gnurou: well that's some work for sure... maybe we can have a special PMU that only does basic PM stuff
02:20 mupuf: well, we need SEQ for memory reclocking, power gating, fan management, over-power consumption monitoring
02:20 gnurou: the alternative being to support the exact same firmware as RM, but that will take more time
02:20 gnurou: urrk I'm not done fighting it seems...
02:20 mupuf: yeah, but better going this way than any other
02:21 mupuf: nvidia needs to come up with an ABI for everything
02:21 mupuf: One would assume that it would not be the end of the world
02:22 mupuf: but ... won't happen without some managerial pressure ... and this takes time
02:22 mupuf: gnurou: please at least make sure the init scripts are run on the PMU
02:22 mupuf: to set up the over-temperature tests
02:23 mupuf: FSRM in my own invented vocabulary
02:23 gnurou: mupuf: yeah, that is properly done already
02:23 mupuf: no idea how nvidia calls it
02:23 mupuf: then the situation is not too bad then
02:23 mupuf: bad situation for the hw, but not the end of the world
02:23 gnurou: well it gets hot...
02:24 mupuf: how hot?
02:24 gnurou: not burning, but hot enough that I am not comfortable leaving my hand on it
02:24 gnurou: that depends on the card I guess
02:25 mupuf: I used to run heaven with the fan stopped and a hair drier on top of the gpu to make it reach 100°C and I could not get it higher than this because the FSRM was so good at doing its job
02:25 mupuf: and it was running at full speed
02:25 karolherbst: gnurou: under full load my kepler reaches 80°C pretty fast ;)
02:25 mupuf: it does
02:25 gnurou: one gm204 kept its fans on all the time, while the gm206 I am working with shuts them down very quickly
02:26 mupuf: gnurou: that means you got the gm206 working?
02:26 mupuf: can we get the fw by friday ? :D
02:26 karolherbst: mupuf: on the gm206 the ina3221 isn't detected :/
02:27 mupuf: karolherbst: any other one detected?
02:27 karolherbst: there is none
02:27 gnurou: gm206 is a debug board
02:27 karolherbst: just the ina3221
02:27 mupuf: hmm, I would suggest using the i2c-tools to check what is there
02:27 gnurou: I hope gm206 fw will be released in the next few days though
02:27 mupuf: karolherbst: but maybe ... it is because we cannot use the i2c ports
02:27 mupuf: remember the email from gnurou
02:27 karolherbst: uhhh
02:28 karolherbst: i2c is also locked until we have the firmware?
02:28 mupuf: s/until we have the firmware//
02:28 karolherbst: :D
02:28 karolherbst: k
02:28 karolherbst: but then we shouldn't fail loading the driver if we can't detect them
02:28 gnurou: this firmware will not help with therm btw, it just unlocks GR
02:28 mupuf: definitely
02:29 mupuf: gnurou: that is understood :)
02:29 gnurou: using the same therm device as gm107 I could read the temperature and other parameters, but controlling the fans was apparently not permitted
02:29 mupuf: 3D first, PM later
02:29 karolherbst: mupuf: if you don't mind I would then send all the power sensor stuff to the ML once I am done (+hwmon integration)
02:29 mupuf: I do not mind
02:29 mupuf: on the contrary
02:30 mupuf: thanks a lot for taking my old patches and revamping them :)
02:30 karolherbst: :D
02:30 karolherbst: no problem
02:30 mupuf: I guess I will have some review to do :D
02:31 karolherbst: mupuf: I think I will enable it for 0x20 sense tables first though, because I don't know how to parse the 0x10 the right way
02:31 mupuf: please try to build in some validation
02:31 mupuf: so we can print a warning in dmesg if there is something funky
02:31 mupuf: well, 0x10 may very well be easier
02:31 mupuf: but why not
02:31 mupuf: I have GPUs I can plug for you though
02:32 karolherbst: do you still have the 770 by the way? Because I would really like to test the patch on this one
02:32 mupuf: hakzsam: I guess we'll be able to unplug the gm206 soon ... since we cannot do anything with it until we manage to upload fake bioses
02:33 mupuf: well, send me the patch and I will test it before leaving the office tonight
02:33 karolherbst: mupuf: k, have to reorder my commits a bit for this
02:34 mupuf: now, have to go back to work, have fun guys!
02:34 hakzsam: mupuf, sounds good
02:35 mupuf: karolherbst: not cool though that we won't be able to access this i2c ports....
02:35 karolherbst: yeah
02:41 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commits/power_sensors
02:41 karolherbst: two newest commits
02:44 karolherbst: ohh some access rights changed there as well...
02:54 karolherbst: mupuf: ohh I remember, that was the git commit of yours where you forgot the header files :D
02:56 mupuf: oopsie? :D
02:57 karolherbst: struct pwr_rail_t rail[32]; do you remember how big you set this array?
02:57 karolherbst: in struct nvbios_iccsense
02:57 mupuf: nope, I must have been lazy
02:58 karolherbst: I think I set it to 16, 9 is the highest I saw
02:58 karolherbst: though I could make it dynamically allocated
02:59 mupuf: yeah, please do for the kernel
02:59 karolherbst: but then I remove the if (iccsense->rail[iccsense->nr_entry].resistor_mohm > 0) iccsense->nr_entry++; thing you did, because otherwise somebody say, we should allocate less when there are such entries :D
04:44 mupuf: marcheu: hey, can you add patchwork@annarchy.freedesktop.org to the nouveau ML? Apparently you can do that from the admin interface.
04:45 mupuf: I already registered it, but patchwork does not automatically answer the registration validation email
07:04 karolherbst: mupuf: the ina219 has only one rail?
07:07 karolherbst: okay, looked it up, ina219 has one channel, ina3221 has three :)
07:08 mupuf: yep
07:08 karolherbst: ohhh "Alert Function" for the ina3221
07:08 mupuf: yes, it is quite nice
07:08 mupuf: but not hooked up
07:08 karolherbst: ahh oaky
07:08 mupuf: you can still read the reg
07:08 karolherbst: I think I found the rail number for the 0x10 version
07:08 karolherbst: could be 0x4 because it seems to be 0x0 for the ina219 things
07:09 karolherbst: and 0x1 has to be not 0x0 or something :/
07:10 karolherbst: there is a vbios with a ADS1112
07:10 karolherbst: and then the sense table is pretty different
07:11 karolherbst: we should ask about 0xa0 type
07:11 karolherbst: there is a vbios with such an entry
07:11 karolherbst: but it's not in the nvidia docs
07:11 AndrewR: https://cloud.mail.ru/public/FUZX/1BsK8Kdgh - attempt at piglit run on nv92 ....It finished after I manually ctrl-c it due to "max-texture-size': corrupted double-linked list: 0x09ca6be8 ***" crash/stop. I used gpu.py profile. Strangely enough some glx tests failed, may be my Xserver build still not completely OK?
07:16 karolherbst: mupuf: your nvce looks funny by the way
07:16 karolherbst: two ina219 in the extdev table, but all power_rails have 0mOhm
07:21 mupuf: karolherbst: do not trust everything in the extdev table
07:21 mupuf: it is often bogus
07:23 karolherbst: this sense table is a mess
07:24 mupuf: it is
07:25 RSpliet: BIOS tables are hardly ever designed for aesthetics
07:25 RSpliet: nor human consumption
07:25 karolherbst: but you should keep it sane for the sake of your clean code :p
07:33 karolherbst: mwk: I does this look "okay" to you? PGRAPH.GPC[0x1].TPBUS.TOTAL => { ROP_COUNT = 0 | GPC_COUNT = 0x5 }
07:33 karolherbst: with nvidia I get ROP_COUNT=1
07:33 karolherbst: and if I opke 0x501 in with nouveau, the rendering crashes
07:33 mwk: ROP_COUNT=0 sounds bad
07:33 karolherbst: I thought so much
07:34 karolherbst: but
07:34 mwk: but tbh I don't know what that register is for
07:34 karolherbst: maybe this isn't the ROP count, but the rastarizer or maybe even the Zcull/EarlyZ engines
07:34 karolherbst: no idea either
07:35 mwk: there is no such thing as a rasterizer count
07:35 mwk: if anything, it'd be equal to GPC count, there's one rasterizer per GPC
07:35 karolherbst: but I have the feeling that EarlyZ doesn't work at all with nouveau anyway
07:35 mwk: whatever count it is, I'd guess 0 is bad anyhow
07:35 imirkin_: karolherbst: earlyz is automatically enabled whenever a frag shader doesn't do anything "bad"
07:35 karolherbst: do we know for sure?
07:35 imirkin_: karolherbst: no way to ever know for sure what the hw does.
07:36 karolherbst: I think there is a counter for discarded pixels
07:36 mwk: imirkin_: well, there are electron microscopes... :p
07:36 karolherbst: I am sure there is one for zcull
07:36 imirkin_: karolherbst: zcull is something else.
07:36 karolherbst: I know
07:36 karolherbst: but if there is one for zcull there could be also one for earlyz
07:36 karolherbst: just a though
07:36 karolherbst: t
07:37 mwk: hmm, how about pixel shader invocation counter?
07:37 karolherbst: yeah, but we have to compare it somewhat
07:37 karolherbst: how can we know how much gets discarded when we look at the pixel shader invocation count?
07:37 mwk: compare it to zpass perhaps?
07:38 karolherbst: and zpass is the amount of checked pixels?
07:38 mwk: the amount of rendered pixels
07:39 mwk: the thing that occlusion queries use
07:41 karolherbst: uhhh
07:42 karolherbst: I can poke the reg on nvidia without crashing the gpu
07:42 karolherbst: looks nice
07:43 karolherbst: https://i.imgur.com/mVyLSAO.png
07:43 karolherbst: it still renders by the way
07:43 karolherbst: just some of the squares aren't updated anymore
07:48 karolherbst: ohhh
07:48 karolherbst: when the reg is 0x100 I get the same performance as with nouveau
07:50 karolherbst: mhh not always though
08:45 hakzsam: mwk, any objections about this ATOM thing on gm107?
08:49 mwk: hakzsam: I don't see anything obviously wrong with it
08:49 hakzsam: mwk, cool
08:49 mwk: but then I have no idea about gm107 ISA
08:49 mwk: so... go ahead, I guess
08:50 hakzsam: I'll push then
09:46 karolherbst: mupuf: did you found some time to test it on the nve4 gpu?
09:46 mupuf: karolherbst: you assume that I left work already :p
09:46 karolherbst: ohh I thought the gpu is at your work
09:46 mupuf:is too busy making git commits in python
09:46 mupuf: it is at work, and I said I will check it out when I leave :p
09:47 karolherbst: :D
09:47 karolherbst: ahh
09:47 karolherbst: now I understand
09:47 mupuf: yeah, actually, that was ambiguous
09:47 mupuf: my bad
09:48 karolherbst: sadly I don't have a gpu with a ina219 here :/
09:48 mupuf: what should I test again?
09:48 karolherbst: if sensors prints a sane value
09:49 mupuf: ah right, will need to compile nouveau OOT
09:49 mupuf: and I guess it does not build on 4.4, right?
09:49 karolherbst: it does
09:49 karolherbst: all my branches do
09:49 mupuf: oh, wonderful
09:49 karolherbst: yeah I usually use the latest kernel release at it is
09:52 karolherbst: imirkin_: thanks for merging the mesa stuff :)
09:52 imirkin_: np
09:52 imirkin_: feel free to bug me sooner if i forget about your stuff
09:52 karolherbst: k
10:10 karolherbst: imirkin_: I want to upstream these three commits next: https://github.com/karolherbst/mesa/commits/to_upstream
10:10 karolherbst: will run piglit and shader-db again and stuff like that
10:10 karolherbst: and send it to the ML once I am done
10:11 imirkin_: karolherbst: ok
10:18 hakzsam: mupuf, could you please unplug the gm206?
10:18 mupuf: hakzsam: I will, when I come back home
10:18 PaulePanter: Hi. $ file /sys/devices/pci0000:00/0000:00:01.0/0000:04:00.0/drm/card0/card0-DVI-I-1/edid
10:18 PaulePanter: /sys/devices/pci0000:00/0000:00:01.0/0000:04:00.0/drm/card0/card0-DVI-I-1/edid: empty
10:18 PaulePanter: $ uname -a
10:18 PaulePanter: Linux gm-debian 4.4.0-trunk-686 #1 SMP Debian 4.4.1-1~exp1 (2016-02-10) i686 GNU/Linux
10:19 PaulePanter: 04:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
10:19 PaulePanter: Any idea why the edid file is empty and has just blank lines?
10:19 PaulePanter: $ xrandr --verbose
10:19 PaulePanter: … prints edid information.
10:19 PaulePanter: Should I report a bug? If yes, where?
10:20 mupuf: PaulePanter: did you make sure you tried to get the EDID from the right connector?
10:21 PaulePanter: mupuf: Yes, it’s DVI.
10:21 PaulePanter: $ find /sys -name edid
10:21 PaulePanter: /sys/devices/pci0000:00/0000:00:01.0/0000:04:00.0/drm/card0/card0-VGA-1/edid
10:21 PaulePanter: /sys/devices/pci0000:00/0000:00:01.0/0000:04:00.0/drm/card0/card0-DVI-I-1/edid
10:21 PaulePanter: The VGA one does not print any lines. The DVI one has empty lines in it.
10:21 mupuf: funny
10:22 PaulePanter: Is that DRM’s job or the drivers job to fill that out?
10:22 mupuf: I would say DRM
10:22 mupuf: but not sure
10:22 mupuf: tried a hexdump of it?
10:23 mupuf: /sys/devices/pci0000:00/0000:00:01.0/0000:04:00.0/drm/card0/card0-VGA-1/edid > /tmp/toto; hexdump /tmp/toto
10:23 PaulePanter: $ hexdump /sys/devices/pci0000:00/0000:00:01.0/0000:04:00.0/drm/card0/card0-DVI-I-1/edid
10:24 PaulePanter: … worked.
10:24 PaulePanter: mupuf: Thank you!
10:24 mupuf: oh, right, why the fuck did I want to make another file out of it
10:24 mupuf: whatever, brain fart
10:24 mupuf: you are welcomed
10:24 mupuf: the "empty lines" sounded weird
10:25 PaulePanter: mupuf: Indeed. Strange that `file` trips on it.
10:28 mwk: PaulePanter: it's not a real file, sysfs doesn't properly implement many POSIX interfaces
10:28 mwk: for one, if you stat it, it has a size of 0
10:29 mwk: so file decides it's empty, and doesn't notice that it can actually read something from it
10:30 mwk: that is, unfortunately, a common problem for most files in /proc and /sys
10:30 karolherbst: they usually only implement open and read :/
10:31 karolherbst: but at least for edid it would somehow makes sense to add more to it I guess
10:31 mwk: yeah, why would they implement more
10:32 mupuf: to cater to our whims, of course!
10:32 mwk: using text streams to dump kernel information is like screwing in a round peg with a square chicken
10:32 mwk: no wonder nobody bothers to do anything than bare necessities for cat to work
10:37 karolherbst: yeah, but for edid it really makes sense to implement more ;)
10:37 karolherbst: maybe not
10:37 karolherbst: is edid fixed in size?
10:37 mupuf: yes
10:37 karolherbst: yeah, then it doesn't matter
10:37 karolherbst: :D
10:37 mupuf: it never matters
10:37 mupuf: read until the EOF
10:37 karolherbst: yeah but sometimes you don't want to read the file in total
10:38 karolherbst: though for sysfs files it doesn't matter that much anyway :/
10:38 mupuf: and if your buffer is too small, keep on reading to get the size
10:38 karolherbst: the content is in RAM one way or the other usually
10:40 mwk: there's a little problem here
10:40 mwk: to do that properly, you'd have to read edid on stat()
10:40 mwk: which slows down ls
10:40 mwk: edid *is* variable size
10:43 RSpliet: I personally get the feeling neither performance nor usability is a serious issue as far as nouveau sysfs entries are concerned
10:44 mwk: well
10:44 karolherbst: imagine stat would get the size from read and you would do ls /proc
10:44 karolherbst: ...
10:44 mwk: doing stuff on stat() is, in general, not a good plan
10:45 mupuf: definitely
10:45 mwk: imagine there's a hang bug in the edid read code... you've just hung ls in /sys
10:45 karolherbst: yeah
10:45 karolherbst: and then you also have access rights problem
10:45 mwk: yep, there's no access protection for stat
10:46 mwk: well, there is, but not at the level you'd want it
10:46 RSpliet: oh I'm imagining an i2c-ish bug for which EDID readout triggers a panel disconnect or similarly vague - that'd suck if ls triggers it :-D
10:46 mwk: yep
11:12 karolherbst: imirkin_: mhh sadle the other two instruction just help 1 and 4 shaders :/ still they are pretty simple opts
11:12 imirkin_: ?
11:13 karolherbst: max(abs(a), 0) to a only helps pixmark_piano and optimize sub(a, 0) to a helps 1 in 0ad and 3 in borderlands
11:13 imirkin_: k
11:13 imirkin_: i wonder if max(abs(a), 0) is ok for integers...
11:13 karolherbst: but the PostRADCE pass is great :)
11:13 karolherbst: mhh
11:13 karolherbst: why shouldn't it?
11:14 imirkin_: abs(MIN_INT) = MIN_INT
11:14 karolherbst: ...
11:14 karolherbst: well it makes sense for this one :/
11:14 imirkin_: i guess i dunno what the cvt op returns
11:14 imirkin_: but there is no positive version of MIN_INT
11:15 imirkin_: (stupid 2's complement... s-mag is so much better. heh.)
11:15 imirkin_: (j/k. 2's complement is way better. but this is an annoying wart.)
11:16 karolherbst: actually I never thought of that abs(MIN_INT) problem
11:16 karolherbst: like in never
11:16 imirkin_: always a first time for everything
11:18 RSpliet: the SUB one is so trivial it deserves to be in mesa regardless :-P
11:18 karolherbst: :D
11:18 imirkin_: i doubt max is used too often with integers either
11:18 karolherbst: RSpliet: I also handle sub(0, a) to -a ;)
11:19 karolherbst: actually I doubt it will be a problem though
11:19 karolherbst: but in some rare super corner case it will be an issue somebody debugs like a week and bisects to this commit
11:19 karolherbst: ... :D
11:20 imirkin_: karolherbst: just restrict it to float-only...
11:20 karolherbst: k
11:20 karolherbst: pixmark only uses floats anyway
11:20 karolherbst: and cutting 20 instructions there is already huge
11:21 imirkin_: btw, max(abs(a), 0) -> abs(a), right? for a second i thought you said -> a
11:22 karolherbst: I should fix the commit message...
11:22 imirkin_: remember that max can probably take an abs modifier
11:22 imirkin_: and that modifierfolding runs first
11:23 imirkin_: so make sure to chekc the modifier as well as the source op being a OP_MAX
11:23 imirkin_: er
11:23 imirkin_: OP_ABS
11:23 karolherbst: yeah
11:23 karolherbst: I do all that
11:23 imirkin_: ok cool
11:23 karolherbst: mhh why does source OP_MAX matters?
11:23 imirkin_: typo
11:23 karolherbst: ahh
11:23 karolherbst: I see
11:23 karolherbst: but the code got too complicated now :/ https://github.com/karolherbst/mesa/commit/b8294c42e64fb83ed02042b76a0eb67b8149b3e0
11:24 karolherbst: maybe i->def(0).replace would be the better thing to deal with that?
11:24 mupuf: karolherbst: don't forget the commit message too :p
11:24 imirkin_: s ^ 0x1
11:24 karolherbst: ... I know :p "[20:22] <karolherbst> I should fix the commit message..."
11:24 imirkin_: i think you want 't'
11:24 karolherbst: ohh
11:25 karolherbst: there is a t which is s ^ 0x1 already?
11:25 karolherbst: ...
11:25 karolherbst: well I suppose t is a bit smarter than this
11:25 thany: hi guys, i'm new to this group.
11:26 imirkin_: karolherbst: t = !s :)
11:26 karolherbst: and if s is 2?
11:26 karolherbst: ohh wait
11:26 karolherbst: ...
11:26 imirkin_: karolherbst: can't happen :)
11:27 imirkin_: karolherbst: that's why i had you add a opnd3
11:27 karolherbst: yeah I know, but !0 is actually defined as 1?
11:27 imirkin_: sure
11:27 karolherbst: k, I somehow put that into undefined behaviour like !0 != 0
11:27 imirkin_: how is that undefined?
11:28 karolherbst: because the result isn't specified
11:28 imirkin_: yeah it is
11:28 karolherbst: it could be 8
11:28 karolherbst: or 4
11:28 imirkin_: nope
11:28 imirkin_: it can't
11:28 karolherbst: if it's defined as !0 != 0
11:28 imirkin_: !x = boolean. boolean -> int conversion can only be 0 or 1.
11:28 imirkin_: since 0 is false, boolean is true, which means it's a 1 as int.
11:29 karolherbst: right because sane people defined true as 1 and not as !false :D
11:29 karolherbst: and missed all the fun
11:30 karolherbst: imirkin_: def.replace can only be done as long as the source is no immediate, right?
11:30 karolherbst: otherwise it would be painful
11:31 imirkin_: you don't want to do def.replace here.
11:31 imirkin_: you want to copy the source in directly
11:31 imirkin_: i.e.
11:31 imirkin_: i->op = src->op
11:31 imirkin_: i->src(0).mod = src->src(0).mod
11:32 imirkin_: or maybe
11:32 Thany_: Hi, i like to participate in development of vulkan spec on this driver, (for resume: I have background in game, i have written a small game engine my self, and my current job is software developing for 3d-printer), i want a quick guide to place me in the point of development, can any body help me?
11:32 imirkin_: i->src(0).mod |= src->src(0).mod
11:32 karolherbst: Thany_: figure out what a vulcan driver has to implement ;)
11:32 mupuf: Thany_: you know where the GL driver is located?
11:32 Thany_: :D
11:32 imirkin_: Thany_: some small amount of work has been done to start converting SPIR-V to nv50 ir (for the compiler)
11:32 mupuf: as in, mesa
11:33 Thany_: ok, where can i join?
11:33 imirkin_: Thany_: however i suspect it'll be many many months of effort before a workable vulkan driver
11:33 imirkin_: i glanced over the spec... it's extensive.
11:34 imirkin_: one has to (a) fully grasp all the concepts in vulkan and (b) figure out how to map them nicely onto nvidia hw
11:34 imirkin_: this requires some familiarity with both things, so it may be difficult to just jump into
11:35 Thany_: ok, is there any nice guide for them?
11:35 mupuf: Thany_: the first one would be the vulkan spec
11:35 mupuf: and the latter is ... our GL driver?
11:35 imirkin_: any time one might spend writing a nice guide would more likely go into actually developing the driver :)
11:36 imirkin_: there's a bit of a learning curve involved
11:36 mupuf: but seriously, vulkan is not supposed to be extremelly different but there are suddle differences in the shader intrinsics for insteance
11:36 imirkin_: if you're serious about contributing i would recommend starting with a simpler item
11:36 imirkin_: and familiarizing yourself with the hw, api's, etc.
11:36 karolherbst: I looked for the "how to implement a vulkan driver" part in the vulkan docs... seems that isn't a common issue so they didn't bother having such a nice summary for this :D
11:36 Thany_: ok, i'm like to guide
11:36 imirkin_: mupuf: have you looked at the api? it's like 6 pages of *just api calls*
11:37 mupuf: imirkin_: which is still better than GL :D
11:37 imirkin_: mupuf: so basically the same as GL. enormous api. lots of various concepts.
11:37 mupuf: GL is much much longer
11:37 Thany_: is there any simple item i could do for getting familiar?
11:37 imirkin_: mupuf: maybe.
11:37 imirkin_: Thany_: what hardware do you have available to you?
11:37 Thany_: 760m
11:37 mupuf: I am disapointed with the the display part though
11:37 imirkin_: Thany_: what chip?
11:37 mupuf: no abstraction at all
11:38 imirkin_: Thany_: lpsci -nn -d 10de:
11:38 imirkin_: anyways... i suspect that the simplest way forward on vulkan is to create a separate lib that implements the api. i don't think keeping it in mesa will be particularly beneficial.
11:39 imirkin_: and moving codegen out to a separate lib
11:39 RSpliet: libdrm? :-P
11:39 imirkin_: RSpliet: ?
11:39 mupuf: RSpliet: maybe not :D
11:39 imirkin_: but i looked over the vk api... it's ENORMOUS... so many entrypoints... so many structures...
11:40 Thany_: imirkin_ 01:00.0 3D controller [0302]: NVIDIA Corporation GK106M [GeForce GTX 760M] [10de:11e3] (rev a1)
11:40 imirkin_: it'll take me a month to just type all that in, forget actually making anything work
11:40 RSpliet: mupuf: I was semi-joking, but the more I think of it... it would allow to clean up the ddx by not requiring hard-coded shaders in there
11:40 RSpliet: if the codegen was part of libdrm
11:40 imirkin_: RSpliet: libdrm has no shaders...
11:40 mupuf: RSpliet: the fix to that is to not have a ddx
11:40 Thany_: imirkin_: 01:00.0 3D controller [0302]: NVIDIA Corporation GK106M [GeForce GTX 760M] [10de:11e3] (rev a1)
11:40 imirkin_: RSpliet: it just has a few convenient wrappers
11:40 imirkin_: Thany_: yeah, i got it the first time
11:41 imirkin_: Thany_: so you have a kepler chip.
11:41 Thany_: yes
11:42 imirkin_: Thany_: a fairly substantial effort that would be very useful for GL and also to a large extent for vulkan, would be adding shader image support for kepler
11:43 Thany_: but there is something i must say, i have optimus hardware, and nouveau by default it recognize my intel graphic
11:43 imirkin_: i have a branch that started doing it for fermi, you could build on that.
11:44 RSpliet: imirkin_: I'm aware of that; ddx does though. could be quite nice-and-tidy having ddx feed it's shaders to codegen rather than containing hard-coded binaries
11:45 imirkin_: RSpliet: why wouldn't you want hard-coded binaries?
11:45 imirkin_: that seems way better...
11:45 Thany_: imirkin__: on which repository?
11:46 imirkin_: Thany_: my images branch is here: https://github.com/imirkin/mesa/commits/images
12:00 karolherbst: I have a kworker with a "[<ffffffffffffffff>] 0xffffffffffffffff" stack, should I be worried? :/
12:27 Thany: imirkin_: I started to reading it. Will you make a branch for me on the repository or i must do it on my own?
12:28 imirkin_: Thany: git is a distributed vcs...
12:28 imirkin_: you do whatever you want to do on your tree
12:28 Thany: oh it isn't restricted, ok
12:29 urjaman: lol
12:35 mupuf: urjaman: you should pity him for not working in a nice environment, not laughing at him ;)
12:35 mupuf: Thany: I hope you don't work with SVN or CVS...
12:35 urjaman: sorry
12:36 Thany: :D i completely new to git, must of the project i work, i work by my self, alone.
12:37 karolherbst: even then I would use git
12:37 mupuf: yep, same here
12:37 Thany: yes i used, but oly pushing,
12:37 mupuf: learning it can be a little daunting, but it is really worth it!
12:38 karolherbst: yeah learning takes a year or more :D
12:39 karolherbst: imirkin_: are there any modifier abs can't take, but max can take?
12:40 imirkin_: karolherbst: abs should never have modifiers actually
12:40 imirkin_: karolherbst: cvt might
12:40 karolherbst: okay
12:41 karolherbst: so if I do max r0 mods abs ... wait a second...
12:41 karolherbst: there can be max r0 neg abs r0 0x0
13:22 karolherbst: imirkin_: I send it to the ML without the abs patch, it needs a bit more thinking and I am not up to it currently :) maybe later this week
13:23 imirkin_: ok
13:24 karolherbst: strange that the post-ra DCE pass doesn't change any shader in the shader-db repository
13:24 karolherbst: maybe these are too simple
13:25 imirkin_: under what circumstances is there crap post-ra that neesd to be cleane dup?
13:25 karolherbst: you know, the one saints row IV shader I showed you once
13:25 karolherbst: the one with 400 instructions and even more BBs basically ;)
13:27 karolherbst: but I didn't dig into that deeper to check what is causing it, especially because the shader code is really bad
13:28 Thany: imirkin_: sorry for my stupid questions, as far as i get it i must work on gallium/drivers/nouveau/nve6
13:28 hakzsam: imirkin_, v3 is there
13:29 imirkin_: Thany: images is going to require a substantial amount of work, but you sounded ambitious so that's why i mentioned it
13:29 imirkin_: hakzsam: got it
13:31 karolherbst: sadly I didn't got any response up until now from larian :/ so if it comes the worst and divinity will keep using that include shader extensions, mesa needs it, right? :/
13:34 karolherbst: though lex/yacc should already support #include by themselfs, though the file tree has to be build somewhat
13:35 imirkin_: of course it's way too late for that
13:35 imirkin_: lex/yacc run at build time
13:38 karolherbst: ohh right :/
13:38 karolherbst: I haven't dig into the glsl code yet
13:38 karolherbst: I thought that there is a library used at runtime to parse the code
13:39 karolherbst: but I think mesa has it's own parser entirely
13:42 hakzsam: imirkin_, the gk110 fix: http://hastebin.com/telokovizo
13:42 vita_cell: karolherbst can I reclock memory or core on gtx460oc or 520gt? with 4.4
13:42 karolherbst: if it is fermi then no
13:43 vita_cell: no reclock for memory or core for Fermi
13:43 imirkin_: hakzsam: ... and i->cc -> i->setCond?
13:43 vita_cell: and pre-Fermi GPUs?
13:43 karolherbst: many gpus can be reclocked, but sometimes there are issues as well
13:43 hakzsam: imirkin_, right
13:43 vita_cell: what GPUs have better support before Fermi?
13:44 imirkin_: vita_cell: late-model tesla's tend to be decent (the DX10.1 ones)
13:44 vita_cell: Ok thanks karolherbst
13:45 imirkin_: vita_cell: note that GT 240 with GDDR5 vram doesn't support reclocking
13:45 hakzsam: imirkin_, done this time: http://hastebin.com/jolabamevi
13:45 vita_cell: you mean that pre-Fermi GPUs with gddr3 or gddr4 supports memory reclock, but not gddr5?
13:46 karolherbst: there is gddr4?
13:46 imirkin_: hakzsam:
13:46 imirkin_: hakzsam: if (s == 2 && i->op == OP_SELP)
13:46 imirkin_: er actually, nevermind
13:46 imirkin_: that's unnecessary
13:46 imirkin_: hakzsam: stick an assert(s==2) in there for good measure
13:47 hakzsam: imirkin_, assert(s == 2) along with the actual assert(FILE_PRED)?
13:47 imirkin_: yea
13:47 imirkin_: i.e. assert(s == 2 && ...)
13:47 imirkin_: or as a separate assert, i don't care
13:48 hakzsam: ok
13:54 hakzsam: imirkin_, https://cgit.freedesktop.org/~hakzsam/mesa/commit/?h=arb_compute_shader_v3&id=33edda1d1a79bb6a6e3f0d5a31b8bfea24f07b94
14:00 karolherbst: imirkin_: ohhh I think I found somebody who implemented ARB_shading_language_include :O
14:27 karolherbst: when I get something like "warning: extension `GL_ARB_shading_language_include' unsupported in vertex shader" where do I add support for this? the patches seem to implement the important stuff, but this warning is a bit odd
14:36 skeggsb: re:vulkan, i made a start on it quite a while back - but it's currently not even possible to implement until some kernel apis are improved
14:37 skeggsb: i shall get back to that and push a WIP repo once i've fixed those problems :P
14:37 karolherbst: skeggsb: nice :)
14:38 skeggsb: imirkin_: i like the idea of splitting codegen out to an external lib, i didn't think the mesa tree was a good fit either, but seemed like the only option to keep the compiler :P
14:43 airlied: I'd advise against doing anything outside mesa tree initially :)
14:43 skeggsb: airlied: oh?
14:44 airlied: you'll probably want to refactor some code out of the nouveau driver
14:44 karolherbst: airlied: will the intel vulkan branch be updated and shareable code moved out? :D
14:44 airlied: karolherbst: there is no shareable code
14:44 skeggsb: there's going to be *very* little sharable, if any
14:44 karolherbst: okay
14:44 skeggsb: perhaps some wsi stuff?
14:45 karolherbst: airlied: so everything shareable is in the khronos stuff already?
14:45 airlied: skeggsb: I'm more thinking shaterable with nouveau
14:45 airlied: not shareable with other drivers
14:45 skeggsb: yeah, i got that, i was responding to karolherbst
14:45 karolherbst: okay
14:45 karolherbst: anyway
14:45 airlied: yeah some of the WSI might be shareable
14:45 karolherbst: it would make sense to move the codegen part out of mesa anway
14:45 airlied: karolherbst: why?
14:45 airlied: really moving things out means making ABIs
14:45 karolherbst: dev tools
14:46 airlied: making ABIs is a pain in the ass
14:46 airlied: just make dev tools depends on mesa
14:46 karolherbst: okay
14:46 karolherbst: but making codegen indepentent of gallium would make sense
14:47 skeggsb: karolherbst: it can already be built into a standalone executable
14:47 karolherbst: and move the gallium -> nv50_ir glue code out of codegen
14:47 karolherbst: skeggsb: yeah I know, but it still depends on gallium
14:47 airlied: but you really want to refactor inside mesa tree, and later if you decide to pull it out then do so
14:47 karolherbst: yeah okay
14:47 karolherbst: the compiler needs to be moved outside gallium
14:47 airlied: but you won't know the result of the refactor until you implement spirv->whatever
14:47 karolherbst: then
14:48 karolherbst: ohh pmoreau already does currently :)
14:48 pmoreau: Yeah well, getting back to it after leaving it alone for two weeks…
14:49 karolherbst: :)
14:49 airlied: you also get used to having src/util/ in mesa :-P
14:49 karolherbst: how can I add a new extension to _mesa_glsl_supported_extensions?
14:50 karolherbst: the code I am trying out already has "EXT(ARB_shading_language_include , dummy_true , GLL, GLC, x , x , 2010)"
14:50 karolherbst: but it seems not to be enough
14:50 airlied: you add a line to _mesa_glsl_supported_extensions
14:50 airlied: in glsl_parser_extras.cpp
14:51 karolherbst: ohhh
14:51 karolherbst: now I see it
14:51 karolherbst: thanks
14:54 karolherbst: okay, but the code seems to be broken anyway :/ sad
15:07 karolherbst: is there a glsl builtin texture() function?
15:07 karolherbst: ohh wait
15:08 karolherbst: let me guess, it is either non-core or compatibility?
15:16 karolherbst: ohhhh
15:16 karolherbst: weird
15:19 karolherbst: odd
15:19 karolherbst: in a shader_test file it works
15:20 karolherbst: ohh okay, and now it works with glreatrace...
15:21 hakzsam: imirkin_, btw, let me know if the compute series for fermi needs improvements, it would be good to merge it before friday :)
15:22 pmoreau: Like, before tomorrow? :-p
15:24 hakzsam: pmoreau, yep!
15:24 karolherbst: uhhh, the shading_language_include code doesn't parse the included source for #include tokens...
15:35 karolherbst: airlied: how can I apply a lexer rule on the replaced string again?
15:36 karolherbst: like if there is #include "something" this gets replaced by some glsl code, which has to be fully parsed, too
15:36 airlied: should you be doing it in the cpp phase maybe, Im not sure
15:37 airlied: I'm not really sure how much work pulling file contents int would be
15:37 karolherbst: well currently this change is made: https://github.com/farmboy0/Mesa-3D/commit/f2d3b03c7367f529468c4b57973a58ea0fc98789
15:37 karolherbst: airlied: the main part seems to be done already
15:37 karolherbst: I just found some code
15:37 karolherbst: but id doesn't apply the include rule on the included source
15:40 karolherbst: maybe the error means something else? "0:6(1): error: syntax error, unexpected $undefined"
15:59 karolherbst: airlied: do you know if it's possible to output the text the glsl parser has produced?
16:00 karolherbst: mhh maybe I should take another look at MESA_GLSL=dump
16:01 airlied: that's the only var I used, I've hacked some other stuff to dump ast before
16:02 karolherbst: will MESA_GLSL=dump just dump the shader source or will it also dump the version with the replaced defines and everything?
16:02 airlied:isn't sure
16:03 airlied: more glsl people in #dri-devel might be better
16:03 karolherbst: k
17:57 karolherbst: imirkin_: I just got an shader code evict midgame
17:57 imirkin_: yeah that happens
17:57 imirkin_: causes a short stalle
17:57 karolherbst: well
17:57 karolherbst: bioshock is crazy compiling stuff all the time :/
17:58 imirkin_: what would you like me to do about it?
17:58 karolherbst: no idea :/
17:58 karolherbst: I could valgrind it, but it's 32bit...
17:58 karolherbst: ohh wait, there is soemthig better
18:25 karolherbst: imirkin_: LocalCSE is the most expensive pass :/
18:25 imirkin_: ya i know
18:25 imirkin_: it desperately needs hashing
18:25 karolherbst: 62% of all SSA passes
18:28 karolherbst: imirkin_: it spends most if its time in nv50_ir::Instruction::defExists
18:33 karolherbst: mhh maybe std::deque isn't such a good idea
18:34 karolherbst: I think I will check what happens if the code uses different container classes