00:25 imirkin: Lyude: when/if you get a chance, i'd appreciate more info about the dp-mst failure case with my patches
00:25 imirkin: Lyude: i updated the patch slightly to fix the crash
00:25 imirkin: but it's not immediately apparent to me what's missing when the new connector is added
00:31 Lyude: imirkin: sure; also-do you know anything about iccsense on maxwell1 GPUs?
00:31 imirkin: nope, sorry
00:31 imirkin: and my GM107 isn't plugged in, so i can't check (easily)
00:31 imirkin: my GF108 doesn't seem to have anything either
00:32 Lyude: darn. anyway; same branch as before?
00:35 imirkin: let me double-check that i force-pushed
00:35 imirkin: yeah, looks liek the updated thing
00:36 imirkin: just re-fetch
00:36 imirkin: basically if you could run 'xrandr --verbose' after adding a DP-MST monitor, that'd be great
00:39 karolherbst: Lyude: not all GPUs have the sensors
00:39 Lyude: damnit i knew it
00:39 Lyude: i'm guessing it's likely this maxwell1 is one of those isn't it
00:39 karolherbst: usually starting with high-mid GPUs they have those
00:39 karolherbst: there are other ways to calculate the power consumption, but mupuf knows more about that
00:40 karolherbst: Lyude: check the vbios. there should be a INA3221 Extdev entry on supported GPUs
00:41 Lyude: karolherbst: https://paste.fedoraproject.org/paste/x5N2cTx6FFtq-GleH5os2Q
00:41 Lyude: I think that's the vbios section you're asking for? not sure what P actually translates to with envytools
00:41 karolherbst: Lyude: extedv isn't part of P afaik
00:41 karolherbst: *extdev
00:42 karolherbst: it's where the GPIO and I2C stuff also is
00:42 karolherbst: but the table is empty most likely
00:42 karolherbst: you have no valid power rail anyway
00:42 karolherbst: allthough I still want to figure out at some point what that "unk0 = 0x2" thing is for
00:42 karolherbst: 1 is for the power sensors
00:43 imirkin: EXTDEV 0: type 0xa0 [INTERNAL_A0] at 0xa8 defbus 0
00:43 imirkin: what is that?
00:44 Lyude: oh btw
00:44 Lyude: i upload every vbios from every card I touch onto the repo, so this vbios is there as well if you gusy want to look closely
00:44 Lyude: (mmiotraces as well!)
00:47 karolherbst: imirkin: no clue
00:47 karolherbst: Lyude: I should do that for the GPUs I have access to as well...
00:47 Lyude: imirkin: btw: mind reminding me about testing your MST stuff next monday? unfortunately about to leave the office
00:48 karolherbst: Lyude: you can check if nvidia-smi reports the power consumption on the maxwell one
00:48 imirkin: Lyude: sure
00:48 Lyude: karolherbst: mm, I usually do it on the basis of "if I plug it into a machine, I force myself to label/vbios/mmiotrace"
00:48 karolherbst: since maxwell they unlocked that feature
00:48 Lyude: ooh true
00:48 karolherbst: I've labeled them, but...
00:49 Lyude: i do however, need to go through all the laptops here
00:50 endrift: Oh hey I am in the channel already
00:50 Lyude: yo
00:50 Lyude: yeah i think you were in here because I helped you with a nouveau bug at some point
00:50 Lyude: don't remember what it was
00:51 endrift: NV41 or something on PPC
00:51 endrift: I forget the chipset number
00:52 endrift: It was a 6800 Ultra IIRC
00:52 Lyude: ahhh
00:52 Lyude: btw: if anyone is curious, https://github.com/Lyude/linux/commit/4f9390067711c57d4389544ac3222369494db704
00:52 Lyude: that should work, although I haven't done very intensive testing of it just yet
00:52 imirkin: endrift: the PCIe one? (do you have a question?)
00:52 endrift: AGP
00:53 imirkin: NV40 then
00:53 endrift: No, I was talking to Lyude in DM about if porting nouveau to Switch for homebrew stuff made sene
00:53 endrift: Sense
00:53 endrift: And figured I should just pop into the channel
00:53 imirkin: a bunch of people are working on variously related items
00:53 endrift: (Hi plutoo)
00:53 imirkin: unfortunately i'm bad at keeping track of who's doing what
00:54 endrift: Well one of the people I'd expect to be involved I just pinged
00:54 endrift: :P
00:54 imirkin: some people are looking to emulate. others are looking to run homebrew.
00:54 karolherbst: hoi
00:54 endrift: yeah I saw some people I recognize from emulation
00:54 endrift: I'm an emudev and a homebrew dev haha
00:55 endrift: But right now I'm more interested on getting homebrew working with hw accel on the switch so I can port stuff to it
00:55 imirkin: iirc i was talking to Armada about some ways forward with homebrew
00:55 endrift: And I'd like to help if I can
00:55 imirkin: this was a few weeks ago i think, he may have gotten further since
00:55 endrift: I have a switch capable of running homebrew so that's the first step
00:56 karolherbst: imirkin: about porting mesa/nouveau to the switch os?
00:56 imirkin: the deal is that you have to use nvidia's gpu "service", so you have to conform to their various APIs for allocating, etc
00:56 endrift: Right
00:57 endrift: I'm familiar with that much
00:57 imirkin: it _may_ be easier to create a new gallium backend with a new winsys that's just heavily based on nouveau
00:57 imirkin: the current nouveau driver is in desperate need of a rewrite anyways
00:57 endrift: Oof
00:57 imirkin: that said...
00:57 imirkin: all of the hard work regarding actually operating the hw is all worked out
00:58 endrift: That's what I thought
00:58 imirkin: however the resource management, fencing, etc - that's what you'd have to reimplement.
00:58 karolherbst: imirkin: well if we do our rewrite we could make sure to not directly do libdrm stuff
00:58 imirkin: karolherbst: nouveau api's are currently fundamentally different from nvidia api's
00:58 imirkin: i think the current nvidia api's don't have implicit fencing
00:58 endrift: I still can't believe I have four TX1 devices heh
00:58 karolherbst: imirkin: yeah, they do explicit one afaik
00:59 imirkin: endrift: so you can reference current nouveau code for doing any particular thing with the hw, but the actual interaction with the winsys (i.e. the things "around" the gpu) will have to be redone
00:59 imirkin: and that's actually a large fraction of the driver
00:59 imirkin: like how do you fill a pushbuf
00:59 imirkin: how do you make sure you don't step all over the previous draw when you have a dependency
00:59 imirkin: etc
01:00 karolherbst: mhh would be still nice to share most of the stuff though
01:00 karolherbst: otherwise we end up with two drivers
01:00 karolherbst: not nice
01:00 imirkin: yeah, it would be nice to share.
01:00 imirkin: but the expedient thing for them would be to just copy and move on with life.
01:00 imirkin: once it all works, one can look at similarities and refactor
01:00 HdkR: Sup endrift :P
01:01 karolherbst: right, but that's why I was saing we should keep that in mind if we rework stuff
01:01 karolherbst: becuase we have to do that anyway
01:01 endrift: Hi HdkR, should you really be here? :P
01:01 karolherbst: :D
01:01 HdkR: pfft
01:01 karolherbst: who isn't here :p
01:01 imirkin: karolherbst: yeah. it can be kept in mind, but without knowing precisely what it is, can't really be catered to.
01:01 karolherbst: yeah
01:01 karolherbst: endrift: maybe this is an idea though
01:02 imirkin: does seem like a bunch of the dolphin people have made it here.
01:02 endrift: Yeah so it does
01:02 HdkR: endrift: As long as I don't tell secrety secrets it's fine :D
01:02 karolherbst: endrift: I think you could just do as imirkin is saying and just get _something_ working
01:02 endrift: Haha
01:02 endrift: Yeah maybe
01:02 karolherbst: maybe trivial opengl stuff like glxgears
01:02 endrift: I'll take a closer look when I have time
01:02 endrift: Which I don't right now
01:02 Lyude: i've been using freedreno's shader samples for getting panfrost working
01:02 karolherbst: and then when you have a good understanding how the nvidia API works, we can see how to move forward from there
01:07 HdkR: endrift: For now I can just complain to imirkin when my multi-head setup flickers with Nouveau :P
01:09 imirkin: and i can tell you to get an AMD GPU
01:10 HdkR: pffft, I'll run away to the blob :D
01:14 plutoo: hi endrift
01:14 plutoo: i have some basic shit working, like glClearBuffer
01:34 imirkin: almost done
01:37 karolherbst: \o/
11:05 kmarauskas: karolherbst: you here?
14:53 imirkin: anyone object to creating a envytools/firmware repo, to put various firmware extraction/processing scripts into?
14:53 imirkin: like my old extract_firmware script, as well as a new one i'm working on?
15:36 mwk: imirkin: if it's just a few scripts, just throw it to the envytools repo
15:37 imirkin: mwk: eh ... i dunno. envytools has such a mish-mash of stuff
15:37 imirkin: tbh i think it should get split up into separate things
15:37 imirkin: [also you said this as i hit the "create" button in github...]
15:49 rhyskidd: karolherbst: you asked me to remind you about GV100 vbios and HBM2: see here https://github.com/envytools/envytools/pull/129#issuecomment-380877378
15:50 karolherbst: rhyskidd: okay, thanks, but now I can only do so on Monday
15:50 karolherbst: sorry
16:03 imirkin: mwk: the main question is whether i should do it in a private repo or create one under envytools
16:07 imirkin: since you're not objecting to the premise of this stuff living under the envytools org, i'm going to go ahead with filling out the repo there
16:20 karolherbst: rhyskidd: did you see my other comments?
16:54 robclark: karolherbst, btw, you might be amused by my i_cant_believe_its_not_piglit.sh cl cts (or rather cl cts test_basic) runner script: https://paste.fedoraproject.org/paste/dmuvhxLowV7u~6VJLSsC6w/raw
16:54 karolherbst: :D
16:55 karolherbst: why not use parallel?
16:55 robclark: I wanted something that would merge back the output in serial order so I could diff output between runs
16:56 karolherbst: yeah, parallel does that as well
16:56 robclark: ofc maybe better ways to do that.. it was just a quick hack
16:56 karolherbst: allthough mhh, in worst case there is always sort
16:57 robclark: I've never really played with parallel.. maybe it would be better, idk.. but basic idea was not to spend more than 15min on this :-P
17:01 karolherbst: robclark: well you basically have your inputs as lines and each line will be executed in parallel. This is somewhat the basic idea
17:01 karolherbst: well the line is used as the input/params to a command or whatever
17:02 robclark: hmm, maybe that would be a better way
17:02 karolherbst: wow, the examples are nice
17:03 karolherbst: "ls | grep -E '\.log$' | parallel mv {} destdir"
17:03 karolherbst: "find . -name '*.jpg' | parallel convert -geometry 120 {} {}_thumb.jpg"
17:03 karolherbst: nice
17:03 karolherbst: I never used it as well, I just knew it was there
17:04 robclark: anyways, I have something now that is better than running all the test in series and crashing 90% of the way thru due to whatever I'm debugging atm ;-)
17:04 karolherbst: :)
17:04 karolherbst: yeah
17:12 imirkin: ok - new repo created - https://github.com/envytools/firmware
17:21 plutoo: is there an fpga in every nvidia gpu?
17:22 imirkin: don't think there is one in any gpu
17:22 plutoo: what's a netlist archive then
17:22 imirkin: i dunno
17:23 imirkin: (i.e. i dunno why it's called a netlist)
17:23 imirkin: https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=blob;f=drivers/gpu/nvgpu/gk20a/gr_ctx_gk20a.h;hb=refs/tags/tegra-l4t-r28.2#l69
17:23 imirkin: i'm just copying their names
17:25 imirkin: perhaps it should be renamed to firmware-tools...
17:25 imirkin: but envytools/firmware-tools ... dunno.
17:25 imirkin: i take suggestions :)
17:26 imirkin: the 3 hardest things in computer science -- naming things and counting.
17:27 mwk: plutoo: netlist refers to ASIC designs as well
17:29 plutoo: yeah but if it's part of upgradable fw
17:29 plutoo: seems to imply fpga
17:30 plutoo: otoh i've seen other things being named weirdly by nvidia so i'm not gonna take it too literally
17:41 rhyskidd: karolherbst: are you referring to comments about cmake / continuous integration?
17:42 rhyskidd: if so, yes
17:42 rhyskidd: was going to take a look this weekend
17:42 rhyskidd: do you have access to the GV100 via Brno?
17:49 imirkin: skeggsb: can you think of a good way to tell the netlists apart? like what in them might identify which gpu they're for?
17:49 imirkin: or mwk perhaps you have ideas
17:50 imirkin: with occasional exceptions, even the fecs/gpccs instruction streams are different
17:52 imirkin: although we can probably group generations by instruction stream size. or perhaps by data size actually... hmmm
17:53 imirkin: all the data files are also timestamped
17:53 imirkin: like "Oct 16 2013 16:52:45". so that's *probably* not a pascal one...
17:55 karolherbst: rhyskidd: yes
21:50 rhyskidd: karolherbst: nice speed up with the Travis changes
21:50 rhyskidd: as I noted, i'm happy for that to be merged with one small fix
21:50 rhyskidd: then i can reissue my standing PR with only the smaller subset of fixes that would be required
21:50 rhyskidd: thanks for the clean up