00:58 nyef: Acquired USB traces (of unknown utility) for the IR emitter for every refresh rate supported by the eDP panel. The 3D effect worked well in the test application.
00:59 nyef: Thus far, using an external display has been spectacularly disappointing in terms of 3D effect. /-:
01:03 imirkin: nyef: you can mess with the width between the eyes... i played around with it a lot back when red/blue glasses were all the rage
01:03 imirkin: ah... the year 2000 :)
01:05 nyef: It's not a depth thing, it's a timing thing.
01:05 nyef: It turns out that the driver prefers the external emitter over the built-in if one is available, and the external emitter works fine against the internal display.
01:06 nyef: The hardware is basically set up via a bunch of timer parameters: When to turn the left lens transparent, when to turn it opaque, when to turn the right eye transparent, when to turn it opaque.
01:06 nyef: All by dead reckoning.
01:06 imirkin: ah.
01:06 nyef: And it needs to end up synchronized to the display.
01:07 nyef: So there's the USB transaction latency to account for, the display latency to account for, and probably the speed of light in a couple of places.
01:08 imirkin: light tends to travel pretty quickly
01:09 imirkin: and if the emitter is positioned with the display, then the images from the display shoudl reach the viewer with the same latency...
01:09 nyef: 1.79 x 10^12 furlongs per fortnight, I know. But if you're dealing with a small enough scale, it turns out to take a while. (-:
01:09 nyef: There's the latency from the video card to the display to consider.
01:10 imirkin: and electricity moves a lot slower
01:34 FrankD: Hi everybody!
01:38 FrankD: Is there any way to get involved with helping nouveau progress without writing any/much code?
01:40 nyef: Wha...? It's using both emitters at once?
01:42 imirkin: FrankD: what did you have in mind?
01:44 FrankD: imirkin, anything? :D I've got Fermi/Kepler/Maxwell/Pascal cards if there are tests to run or dumps to be gotten.. got rid of anything Tesla or earlier
01:45 imirkin: FrankD: well, occasionally someone might request that tests be done on a particular chipset, but other than that, i can't think of much that needs doing outside of things that require technical work.
01:53 FrankD: imirkin, technical as in how?
01:53 imirkin: working with code
02:10 nyef: So, 3D IR USB traces obtained for all eDP panel refresh rates for both internal and external emitters. External emitter trace also obtained for messing about with the input controls. The external panel does more refresh rates, but the sync is out, so the 3D effect doesn't work, so I didn't obtain traces.
02:10 nyef: Is there anything more that I can/should do before swapping my Linux disks back in?
02:18 nyef: Yes: I should obtain traces for the external display for refresh rates down to 60Hz. Just because the sync is out doesn't meant that some of the timing parameters won't be useful. And then I should install the utilities that came with the monitor and see if something there clears up the sync issue.
02:52 nyef: ... So much for that idea. Decided to start with the driver updates, which included a new nvidia driver, which killed support for the more interesting refresh rates in the stereo controller. /-:
03:03 snkcld: sss between optimus and hardware-mux... they both look the same as far as the layout goes PCI wise... right? that is, to the kernel, there look to be 2 gpus?
03:03 snkcld: with a hardware mux'd GPU, the data has to be copied over the PCI bus to the the gpu thats drivign the output... and i imagine in optimus it is also true that the data has to be copied to the integrated graphics GPU, too, but they are closer together?
03:06 imirkin: i dunno how hw muxed laptops work in such a context
03:06 snkcld: as far as optimus goes then
03:06 imirkin: if you're using prime, that's not a hw mux
03:06 snkcld: oh
03:06 snkcld: lol, i thougth it was
03:07 imirkin: i'm guessing the hw mux is in reference to the display connection
03:07 snkcld: yea, theres a chip that is programmed to changed between the gpu i guess... not entirely sure how it works
03:07 snkcld: but you "outb" some data to it, and it switches some stuff
03:09 imirkin: bonbons: would you be so kind as to file a bug for your situation, including bisection results, your .config, and a bootup log?
03:17 snkcld: imirkin: is the difference between hardware-mux and optimus the fact that an optimus GPU is simply not directly connected to any ouputs? in all other regards, it is a pci device that is not part of the CPU device itself right?
03:18 imirkin: that's right.
03:18 imirkin: the cpu integration is purely secondary to the whole concept as well
03:19 snkcld: so why do people talk about optimus as if its so drastically different when talking about battery life?
03:19 airlied: optimus GPU can be connected to outputs as well, just not usually the internal pane
03:19 airlied: panel
03:20 snkcld: airlied: that makes sense, so e.g. hdmi output etc
03:20 imirkin: well, optimus is more a marketing term than anything else.
03:20 snkcld: heh
03:20 nyef: That's a bit better. Now I can relax a bit before trying to figure out the USB traces for the IR emitter.
03:21 snkcld: airlied: imirkin: i guess what im trying to get at is this: from the perspective of nouveau and vgaswitcheroo, if one is on optimus or hardware mux... it looks the same, right
03:22 imirkin: switcheroo is in reference to where the panel and potentially other outputs are hooked up
03:22 airlied: with no mux there should be in theory no switcheroo, just power management
03:35 snkcld: airlied: ohhhhhh
03:35 snkcld: so optimus systems only report _1_ gpu?
03:41 snkcld: oh, sorry, that assumption doesnt make sense i guess. i guess im just confused as to how, in theory if you had multiple gpus... how would one select which one to use?
03:42 CookieJar: had popped in here to ask for help, but I figured it out
03:43 CookieJar: was having trouble setting tv_norm to ntsc-m
03:43 airlied: snkcld: DRI_PRIME= env var, but other APIs have different ways,
03:43 imirkin: CookieJar: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
03:43 airlied: really to support optimus properly we'd need a lot or changes to X/wayland/GL stack
03:43 CookieJar: imirkin, yeah I'm aware of that page, just couldn't figure out how to actually set it
03:43 CookieJar: just figured it out now though
03:43 CookieJar: and all is good
03:43 airlied: in order to get the battery life savings that Windows/OSX do
03:44 imirkin: CookieJar: cool
03:44 CookieJar: also found that my bench tv/monitor supports pal as well as ntsc through this, so that's nice to know
03:51 imirkin: probably not the right way for that stuff to be exposed, but ... oh well
03:51 imirkin: should be a connector property...
03:53 imirkin: oh. there is a connector property.
03:53 imirkin: this just affects which one is set by default.
03:57 nyef:notes that -rc5 is out, and that it doesn't have that gt215 audio fix.
03:57 nyef: I suppose it might end up in 4.11?
03:58 imirkin: nah, skeggsb will send a fixes pull
03:58 imirkin: i dunno why he hasn't sent one in yet...
03:58 imirkin: maybe coz airlied was at lca? dunno.
03:58 imirkin: also he usually doesn't send them publicly, which is a little annoying since you never know what's being sent in.
03:58 airlied: skeggsb: ^ :)
03:59 imirkin: but i guess they sit 3 feet apart, so sending emails is more annoying than saying "yo dave, pull!"
04:01 skeggsb: it's on my list of things to get to
04:02 nyef: Okay, that's fair, I guess.
04:02 nyef: And it's not like I can't patch my kernel locally.
04:02 imirkin: skeggsb: dunno if you've been following my conversation with bonbons, but it looks like c85ee6ca79590cd51356bf24fb8936bc352138cf somehow managed to regress nv1a
04:02 imirkin: i've stared at that change inside and out, and it seems fine, which means that i'm either blind, or the issue is due to some surrounding infra that's not part of the change
04:04 nyef: Hrm. My new panel has different EDID for DP and HDMI... Which means that I really need to scare up a DVI cable to check the EDID on that interface.
04:05 imirkin: nyef: at the very least, the EDID tells you whether it's an HDMI connection or not - so the literal edid bits will be different
04:05 imirkin: (some monitors forget to fix the edid checksum to account for that)
04:06 nyef: In this case, the DP EDID is a 1.4 with a max dotclock of 330MHz and the HDMI EDID is a 1.3 with a max dotclock of 170MHz.
04:07 imirkin: that's ... surprising
04:07 nyef: What I'm not seeing is any declared latency information in either, and I've already checked for that three-pin sync connector and it doesn't have one of those.
04:10 imirkin: skeggsb: it does change the ordering of that tile init thing wrt the "remainder" of the gr_init function.
04:13 skeggsb: imirkin: i can't imagine that'd be the cause, but, it also wouldn't hurt to test it
04:13 imirkin: well, that's the only plausible difference i've dug up
04:18 snkcld: in order for KMS to work, would i915/nouveau need to be built in? or can they remain modules?
04:19 imirkin: snkcld: they can remain as modules
04:19 imirkin: the system boots with vgacon or efifb, and then the relevant driver can take over when it is loaded.
04:20 snkcld: awesome
05:27 nyef: ... I wwonder if part of this IR widget startup sequence is actually calibrating for USB latency?
05:54 bonbons: imirkin, skeggsb: filed as FDO bug 99499
05:56 nyef: Almost to six digits?
05:56 bonbons: I won't be on IRC for the next 36 hour so please add patches for testing or questions to the bug
05:56 bonbons: nyef: 500 to few to be last-5-digits
11:30 karolherbst: mhh oh right, 4.11 is comming :D
11:31 karolherbst: will post updated power budget stuff on the ML today then
15:41 Echelon9: Popping in to say hi on #nouveau, as I've created a few code and documentation PRs for envytools
15:44 Echelon9: I'm already a contributor to Mesa (vc4 and i965 mostly)
15:45 imirkin_: hi Echelon9
15:49 Echelon9: I'll start out doing some basic "janitorial"-style work on envytools, as a means of familiarizing myself with the code and tools
15:50 Echelon9: It's been helpful so far starting with the limited tests, understanding what they're doing and then improving the documentation of those parts
15:50 imirkin_: cool. do you have any specific goals in mind in the future?
15:52 Echelon9: I'd in jest say reclocking support -- but will start off with more achievable goals
15:53 imirkin_: on what gpu family?
15:53 Echelon9: So perhaps taking a look at some failing piglit tests
15:53 imirkin_: it's all fairly achievable - just requires a ton of effort
15:54 Echelon9: I've had experience looking at Newton-Rapshon to improve trig primitives on vc4 -- and I know that's been used on certain nv gpu series in the past
15:54 imirkin_: ok, well, on the practical side of things - what nvidia gpu's do you have access to?
15:54 Echelon9: I'm getting a mobile Maxwell
15:55 imirkin_: do you know which one?
15:55 imirkin_: GM20x or GM10x?
15:55 Echelon9: And I want to get the Shield TV (Tegra X1)
15:56 imirkin_: cool
15:56 Echelon9: GM107 on the mobile side
15:56 imirkin_: well there are a few fairly easy things that could be done on GM20x that haven't because ... well, really because i don't have one :)
15:56 imirkin_: ok, reclocking should work fine on GM107 with kernel 4.10
15:56 Echelon9: which I understand a few here have GM107's
15:57 karolherbst: imirkin_: hopefully he has one which doesn't reclock successfully yet
15:57 karolherbst: there are some bits inside those memory tables left
16:20 karolherbst: Echelon9: did you see the trello board already?
16:58 Echelon9: karolherbst: yes, I've seen that trello board and will find some that work for me
19:46 karolherbst: mupuf: are you there?
19:46 mupuf: yop
19:47 karolherbst: regarding the max power consunption values. I had the one patch where I parse the vbios and store the result into nvkm_iccsense. You noticed, that I should rather parse the stuff inside hwmon and directly output it there.
19:48 karolherbst: here are the patches: https://github.com/karolherbst/nouveau/commits/power_budget
19:48 karolherbst: I could add a function to the second patch to parse the max values with a TODO mentioning, that it is only trivial in this case and there is a different way to get those values if the one header byte isn't set
19:48 karolherbst: would that be okay for you?
19:49 karolherbst: (also I don't want to reparse the vbios over and over again inside the hwmon functions)
19:49 karolherbst: I am refering to https://lists.freedesktop.org/archives/nouveau/2016-October/026329.html and https://lists.freedesktop.org/archives/nouveau/2016-October/026330.html
19:49 mupuf: karolherbst: because of performance reasons? :D
19:50 karolherbst: no, because we shouldn't parse the vbios outside nvkm
19:50 mupuf: oh, right
19:50 karolherbst: well, we do for display stuff anyway
19:50 mupuf: that part is definitely true
19:50 karolherbst: but still
19:50 karolherbst: it doesn't belong inside nouveau_hwmon
19:50 mupuf: ok, checking out the patches!
19:50 karolherbst: yeah, I rewrote them a little since the first series
19:52 karolherbst: and I expect this to change with pascal anyway, so we will most likely end up with chipset specific code paths sooner or later
19:52 karolherbst: by the way, I found one semi and one fully interested person for gsoc nouveau stuff, will most likely talk with them tomorrow about it in more depth :)
19:55 mupuf: karolherbst: that would be fantastic!
19:55 mupuf: we need to recruit more devs!
19:55 karolherbst: yeah :)
19:55 mupuf: and I need to deliver on my: 2017 will be a geekier year
19:55 mupuf: 2016 was overly social :D
19:55 karolherbst: :D
19:55 imirkin_: can't have any of that :p
19:55 karolherbst: true
19:55 karolherbst: but I like it
19:56 karolherbst: 2017 will stay social and become a lot geekier :p
19:56 karolherbst: at least for me
19:56 mupuf: :)
19:56 karolherbst: have to buy my ticket for sha still :D
19:57 imirkin_: karolherbst: coz finishing up kepler reclocking wasn't geeky enough?
19:57 mupuf: mine will definitely tune down on the social, that is for sure! But that still means going out 3 times a week at least :D
19:57 karolherbst: imirkin_: of course not :P
19:57 mupuf: imirkin_: it is not done yet ;)
19:57 imirkin_: well, it's never done
19:57 imirkin_: but it's a lot more done.
19:57 karolherbst: especially gm20x isn't done yet :D
19:57 imirkin_: gm20x isn't kepler :p
19:57 mupuf: yeah, 2016 was awesome for this
19:57 karolherbst: well
19:57 karolherbst: reclocking wise it is nearly the same
19:57 karolherbst: just with some fancy features we don't need :p
19:58 karolherbst: (yet)
19:58 imirkin_: yeah. like correct voltage.
19:58 karolherbst: we have correct voltage
19:58 imirkin_: oh you mean gm20x
19:58 imirkin_: yea
19:58 mupuf: imirkin_: what about you?
19:58 imirkin_: dunno, we'll see
19:58 mupuf: you'll tell us in 2018 ;)
19:58 karolherbst: dynamic reclocking this year is on my list
19:58 imirkin_: i haven't done much in nouveau-land in the past ... 6 months?
19:59 imirkin_: maybe longer
19:59 mupuf: well, I assume you have been finding new shiny stuff to do, no point in burning out
19:59 mupuf: and Samuel has been a machine
20:00 karolherbst: quite sad that samuel isn't there for us anymore :(
20:00 imirkin_: nothing serious since ssbo's and the half-impl of images
20:00 imirkin_: [for me, that is]
20:00 karolherbst: maxwell scheds?
20:01 karolherbst: also the counter things will really help us out in the future
20:01 mupuf: karolherbst: give him time to adjust, he may surprise us with some work from time to time
20:01 karolherbst: mupuf: :D hopefully
20:01 mupuf: but I am sad we *still* did not finish writing the support for perf counters :D
20:02 mupuf: It is not like I got interested in it in .... 2012?
20:02 mupuf: wait, no!
20:02 mupuf: 2011 was my first demo with them
20:02 mupuf: lol
20:02 karolherbst: :D
20:02 mupuf: it crashed the machine
20:02 mupuf: wait, no, fosdem 2012 was the one that crashed
20:02 mupuf: XDC 2011 worked
20:03 karolherbst: if I get really bored I will look into the NVFBC and NVIFR things :D
20:03 karolherbst: aka scren/buffer capturing
20:04 karolherbst: NVFBC is framerbuffer capturing and NVIFR is inban frame readback
20:04 mupuf: karolherbst: really? Before zcull?
20:05 karolherbst: mhhhh
20:05 karolherbst: okay zcull first
20:05 karolherbst: NVFBC and NVIFR are part of NVENC anyway
20:05 imirkin_: karolherbst: on top of any RE with that, might want to sync up with the intel & other folk who are looking into adding readback support to linux
20:05 karolherbst: nvenc is just a monster
20:06 karolherbst: and I am not even sure we can use NVFBC and NVIFR on linux anyway
20:06 mupuf: karolherbst: well, given the current situation with vdec, not sure it is worth it, honestly
20:06 karolherbst: it's for encoding
20:06 karolherbst: not decoding
20:06 mupuf: I know
20:07 mupuf: but when do you need this?
20:07 mupuf: Only when you don't want to hog your CPU
20:07 karolherbst: right
20:07 mupuf: when do you not want to hog your CPU?
20:07 mupuf: when you are gaming
20:07 mupuf: can you game on nouveau?
20:07 karolherbst: encoding on the GPU is like 10 times faster
20:07 mupuf: well... hmm ... not really?
20:07 karolherbst: or even more
20:07 mupuf: yep, but the quality is bad, so it is more for streaming in real time
20:07 karolherbst: okay, sure
20:07 mupuf: where is twitch for linux :D
20:08 karolherbst: I will look into perf things first anyway
20:08 mupuf: sounds like a better plan ;)
20:08 karolherbst: it would be just a huge interesting project
20:08 karolherbst: :D
20:08 karolherbst: perfect for a gsoc student!!! :D
20:08 karolherbst: mhh
20:08 karolherbst: might be overkill though
20:08 mupuf: Dave said at LCA that Ben *really* wants to work on vulkan
20:08 karolherbst: I heard the rumors
20:08 mupuf: lol, GSoC project out of nvenc
20:09 karolherbst: mupuf: enough for 5 years
20:09 imirkin_: i dunno - i figure nvenc could be worked out to a reasonable extent in a 3-month period by a sufficiently dedicated individual
20:09 imirkin_: (working on it full-time)
20:09 karolherbst: might be enough
20:09 mupuf: and I thought, in retrospect, that I had been crazy with my idea to implement perf counters
20:09 karolherbst: good thing is, that userspace supports it already
20:09 imirkin_: not implemented in mesa, but RE'd enough for another gsoc student to implement it in another 3 month
20:10 karolherbst: yeah, sounds reasonable
20:10 imirkin_: this stuff ain't that complicated
20:10 mupuf: imirkin_: not sure how many people could figure this shit out that quickly without extensive knowledge about it
20:10 karolherbst: mupuf: I looked with imirkin_ into that already a bit
20:10 mupuf: maybe, but you need to teach them about pushbuffers fiest
20:10 karolherbst: it looked "reasonable"
20:10 mupuf: and PFIFO
20:10 imirkin_: i'm trying to remember how long it took me to RE vp2... which i wasn't working on full-time
20:10 imirkin_: i think it was a few months
20:10 mupuf: etc...
20:10 imirkin_: and that was my first (real) contact with nouveau
20:11 mupuf: yeah, but you were already a veteran coder ;p
20:11 mupuf: not a student
20:11 imirkin_: i guess.
20:11 mupuf: well, I mean, better under-scope a project than overscope
20:11 mupuf: it
20:11 imirkin_: anyways, that's why i said "sufficiently dedicated" :)
20:11 mupuf: I have been coordinating the gsoc effort for the xorg foundation for 3 years now
20:12 mupuf: or 4
20:12 mupuf: students really get good after the second year
20:12 imirkin_: RSpliet and hakzsam have been "sufficiently dedicated". dunno about any others.
20:13 imirkin_: but yeah, you really need to have some experience with the project
20:13 mupuf: RSpliet was not ordinary GSoC student
20:13 mupuf: just like curro
20:13 mupuf: both of them were actually EVoC students IIRC
20:14 imirkin_: well i'm sure roy would have done fine as a gsoc student as well :p
20:14 mupuf: hakzsam was a real gsoc student
20:14 karolherbst: looking back I would also wanted to do a gsoc project :D
20:14 mupuf: I am sure, but 4 years of experience in nouveau help a lot when starting a GSoC :D
20:14 mupuf: karolherbst: better late than never
20:14 karolherbst: I am no student currently :p
20:15 mupuf: sorry, meant: better get involved late than never
20:15 karolherbst: but no degree yet as well :D
20:15 mupuf: how german of you
20:15 karolherbst: kind of
20:16 mupuf: curro did not finish IIRC
20:16 mupuf: Calim did not finish either
20:16 mupuf: ok, he is austrian
20:16 mupuf: but close enough, right? :D
20:16 mupuf:is bracing
20:16 karolherbst: most of the so called hackers don't finish it in germany
20:16 hakzsam: and I did not finish as well :)
20:16 karolherbst: most even make jokes of you, that you are only a real hacker if you aborted your studies
20:16 mupuf: ?
20:16 karolherbst: so I guess it must be true
20:17 mupuf: hakzsam: what didn't you finish? Don't you have your masters degree already?
20:17 hakzsam: mupuf: ah, I thought it was GSoC related
20:17 mupuf: nope
20:17 karolherbst: no
20:18 hakzsam: (didn't read carefully to be honest)
20:18 mupuf: yeah, it is getting long
20:18 karolherbst: wondering if I ever will get a degree at some point
20:18 mupuf: at this point, better get the job you want and make it your CV
20:18 mupuf: just don't go close to france
20:18 karolherbst: :D
20:19 karolherbst: I guess getting reclocking working the way we want it on gm20x would help as well
20:20 hakzsam: imirkin_: are you going to be a gsoc mentor this year, btw?
20:21 karolherbst: what are the requiernments to become one by the way for any Xorg related projects?
20:21 hakzsam: time and patience? :)
20:21 karolherbst: because the ones I will talk to I will meet in person, like from eye to eye
20:21 karolherbst: :D
20:21 karolherbst: k
20:21 imirkin_: hakzsam: if there's a student that's worth it, sure
20:21 hakzsam: cool
20:21 karolherbst: imirkin_: I found you some if you want
20:21 karolherbst: *find
20:22 karolherbst: depends on which topic you want to mentor
20:23 hakzsam: instructions scheduler would be nice, but it's hard
20:23 karolherbst: more or less. I prefer to have a tool which gives us all the information about latencies and what not
20:24 karolherbst: in an automatic way
20:29 hakzsam: you might want to write a pre-RA pass which reduces GPR pressure (in a first time). And we already know the latencies for Maxwell (eg. maxas and my code)
20:30 hakzsam: anyways, I don't have time for gsoc this year :)
20:30 karolherbst: mupuf: updated https://github.com/karolherbst/nouveau/commit/0c9ac0adcf500607a6371391562ea9874befbf48
20:30 karolherbst: hakzsam: ohh nice, so that at least for maxwell we are good now
20:31 karolherbst: hakzsam: but we need this for all previous gens anyway
20:31 hakzsam: yep
20:31 karolherbst: and also to verify that the maxwell stuff is right and for all future gens as well :D
20:42 pmoreau: I was wondering if working on ARB_gl_SPIRV and/or adding support for OpenGL-related stuff to the SPIR-V translation pass could be worth a GSoC. I would need to send an initial serie for the SPIR-V stuff though.
20:43 pmoreau: And I should send those quickly, before I disappear again for reason of paper deadline
20:43 imirkin_: pmoreau: how is the texture/sampler stuff resolved? vk does it the DX way (where sampler and texture are separate)
20:43 pmoreau: IIRC, it is separate
20:44 imirkin_: but the surrounding stuff is GL...
20:44 pmoreau: It can be separate in OpenGL as well, if you create your own sampler objects, can’t it?
20:44 imirkin_: kinda-sorta
20:44 imirkin_: you have to attach samplers to texture units
20:44 imirkin_: so they're not really separate
20:45 pmoreau: That’s true
20:46 mupuf: re
20:46 mupuf: pmoreau: yeah, would be a good project!
20:46 pmoreau: https://www.khronos.org/registry/spir-v/specs/1.1/SPIRV.html#OpSampledImage it seems that you first create a sampled image before sampling it, with the sampler being separate from the image and only associated when creating the sampled image.
20:47 imirkin_: pmoreau: i understand how vk works (i think)
20:47 imirkin_: pmoreau: the question is how does it integrate into a GL environment
20:47 imirkin_: since you're talking about ARB_gl_spirv
20:48 mupuf: karolherbst: so, when you said "no vbios parsing in hwmon", you meant "no calling of vbios-parsing functions from hwmon" or "we should not interpret results from the bios in hwmon"?
20:49 karolherbst: both actually, but much more the first
20:50 nyef: Would that mean something else parses the vbios and configures hwmon, or another approach entirely?
20:52 pmoreau: imirkin_: I haven’t looked at the SPIR-V code that glslang would produce for a GLSL 450 shader using texture(). I’ll have a quick look
20:52 airlied: optypesampler is illegal ingl
20:53 airlied: the extension mentions a bunch of diffs
20:55 pmoreau: airlied: In the GLSL450 extension of SPIR-V? I only had a quick look, but it seems to be exclusively math functions that are added by that extension.
20:59 pmoreau: It seems to be taking as input an OpTypeSampledImage directly
21:00 airlied: pmoreau: in ARB_GL_spirv
21:00 airlied: Non-acceptance of SPIR-V features, relative to Vulkan:
21:00 pmoreau: Ah, makes sense
21:01 pmoreau: Thanks
21:07 mupuf: karolherbst: I have no problem with the first
21:07 mupuf: but I do get your point for patch 2
21:07 mupuf: you will need it later
21:07 mupuf: so, why not put it there
21:10 mupuf: ok, I guess the main hold for me is that you did not RE what the other entries mean
21:10 mupuf: On my nve4: 0x00007f72: 20 0d 22 09 64 00 01 04 06 07 ff e8 03
21:10 karolherbst: yeah I know
21:11 mupuf: I guess it is pretty clear that 0, 1, 4, 6, 7 and ff are other entries
21:11 karolherbst: they have "odd" effects
21:11 mupuf: ?
21:11 karolherbst: sure
21:11 karolherbst: but I couldn't get my head around what they do
21:11 karolherbst: this one entry was the most obvious one
21:11 mupuf: e8 03 --> is it the average period?
21:11 mupuf: in ms
21:11 mupuf: 0x3e8== 1000
21:12 karolherbst: might be, yes
21:12 mupuf: I wonder what the 64 means too
21:12 mupuf: ok, let's have a plan of attack for this. How would we RE this?
21:13 karolherbst: my main goal was to figure out how nvidia decides what the highest possible power consumption is
21:13 karolherbst: and point is, the ever header fields didn't help with that
21:13 mupuf: karolherbst: well, sure, you likely are in the right place
21:13 karolherbst: right
21:14 karolherbst: there is one important byte in the entries
21:14 karolherbst: which is byte 0
21:14 karolherbst: this is some kind of flag byte
21:14 mupuf: now, do we agree that each cap is for certain conditions, right?
21:14 karolherbst: giving those entries certein "functions"
21:14 karolherbst: or rather meaning
21:14 karolherbst: no
21:14 karolherbst: I couldn't agree to this yet
21:14 karolherbst: might be, but no
21:14 karolherbst: look at those entries
21:14 karolherbst: it makes hardly sense
21:15 mupuf: well, what does "min" means anyway? :D
21:15 karolherbst: no idea
21:15 karolherbst: I think it depends on the meaning of the entry
21:16 karolherbst: this is my table: https://gist.github.com/karolherbst/fc0142816040ad02a65e5bc723b07ac6
21:16 mupuf: by any chance, how likely is it that the same conditions you got for the vptable would apply here?
21:16 mupuf: that would greatly help, right?
21:16 karolherbst: it would, if it would make sense
21:17 mupuf: there may be other factors
21:17 karolherbst: sure
21:17 karolherbst: but if you look at my table... it makes hardly sense anymore
21:17 mupuf: why do you select the entry 7 when "nvidia-smi cap entry: 255"?
21:17 karolherbst: especially because our header is nearly the same
21:17 mupuf: well, do not expect OEMs to do the right thing
21:17 karolherbst: I didn't change that part
21:17 karolherbst: true
21:18 mupuf: they botch vbios all the time
21:18 karolherbst: mhhh
21:18 karolherbst: I know that the 00 and the 01 byte _change_ things
21:18 karolherbst: they don't select entries
21:18 karolherbst: if you flip the 01 to 00, there is no power capping anymore
21:19 mupuf: what about if you set it to 3?
21:19 karolherbst: the painful part is, that nvidias driver is also kind of crappy here
21:19 karolherbst: chances are high if I do something wrong, the driver crashes
21:19 karolherbst: it's really no fun to RE this table
21:19 mupuf: yeah, they got really bad at this
21:19 karolherbst: I think I wrote stuff down at some point
21:19 karolherbst: let me find it
21:20 mupuf: being able to figure out what is co-depend would help
21:20 karolherbst: one thing I am sure of is
21:20 karolherbst: that byte 0 of the entries is the key to most questions
21:20 karolherbst: and it is splited in two parts
21:20 karolherbst: 0x02 mask means "affects power cap"
21:20 karolherbst: somewhat
21:21 karolherbst: so entry 0 is important for the actual power cap on my gpu
21:21 mupuf: so you think that the entry is like ap rogram?
21:21 karolherbst: 0xc0 _changes_ the parsing
21:21 mupuf: and the byte 0 is a condition on how to apply the other values as a mask?
21:21 karolherbst: so if I have only 0x02 a different power cap is there
21:21 karolherbst: or a differen behaving one
21:21 karolherbst: maybe?
21:21 karolherbst: but then there is entry 3
21:21 mupuf: well, I doubt it but this is possible
21:22 karolherbst: which makes like no sense
21:22 karolherbst: (yet)
21:22 mupuf: it is unused for you, if we are to believe this
21:22 karolherbst: I have a long weekend in the first week of februrar
21:22 mupuf: http://pastebin.com/pcaxFdAk
21:22 karolherbst: I guess instead of going to fosdem I will re some tables
21:23 karolherbst: yeah, with yours it is obvious
21:23 karolherbst: the power cap is 228W and 243W criticial
21:23 karolherbst: nvidia-smi should tell you the same
21:24 karolherbst: maybe the min value in 7 means something like "minimu power consumption on full load"?
21:25 mupuf: probably is a bump the clocks one
21:25 mupuf: but why not have done it earlier anyway?
21:25 karolherbst: highly doubt it
21:25 mupuf: exactly, you should be surfing the avg power usage
21:26 karolherbst: nvidia doesn't care that much about power consumption though afaik
21:26 karolherbst: except you are near the budget
21:26 mupuf: yeah, that makes a lot of sense
21:27 karolherbst: anyway, I am more interested in the P.50 table
21:27 karolherbst: this is more important right now
21:27 karolherbst: well somehow
21:27 karolherbst: if we know the power cap, this helps as well
21:27 karolherbst: because we can at least protect the GPU from drawing to much power
21:28 karolherbst: and then, we should figure out how to software throttle the GPU, which we do with P.50
21:28 karolherbst: we hardly reach the power cap anyway yet
21:34 mupuf: karolherbst: agreed
21:35 karolherbst: I mainly wanted to push the cap into hwmon so that user complain if the values make no sense at all, but I am pretty sure that I know what at least this one byte in the header means
21:36 mupuf: well... hmm
21:36 mupuf: I could not complain about this
21:37 mupuf: but at least make it clear that the parsing is very likely wrong
21:37 mupuf: and that you are trying to collect data more easily
21:37 karolherbst: well, the parsing is very likely right, because I confirmed it with nvidia-smi
21:37 karolherbst: allthough
21:37 mupuf: hmm
21:38 karolherbst: there might be rules to overwrite those values
21:38 mupuf: ack, please detail your RE in the cover letter for the patches
21:38 karolherbst: at least I know that if this byte is set, it has preference over the way my table is parsed
21:38 mupuf: :)
21:38 karolherbst: also
21:38 karolherbst: if the header isn't set
21:38 karolherbst: nvidia-smi doesn't show any power cap at all
21:38 karolherbst: *header byte
21:39 karolherbst: so my current theory is: this byte selects a "virtual" or "unconditional" power cap, where a different kind of power capping might occur depending on all the other fields/entries
21:39 karolherbst: and situation
21:51 karolherbst: mupuf: gpus within reator: https://gist.github.com/karolherbst/024ec932c724e44bd68bf036310c6fb9
21:52 karolherbst: power budget entry of the gm206: 6: min = 60000 mW, avg = 130000 mW, peak = 150000 mW (unkn12 = 7650)
21:52 karolherbst: power budget entry of the gm107: 2: min = 30000 mW, avg = 38500 mW, peak = 38500 mW (unkn12 = 0)
22:31 snkcld: is optimus considered "dedicated graphics"/"discrete graphics"? it is, right?