01:08imirkin: mwk: how does pmpeg work? <reg32 offset="0x270" name="IMAGE_BASE" variants="NV31:G80"/>
01:08imirkin: mwk: how is the surface set for pre-nv31?
01:08mwk: it isn't really
01:08imirkin: where does it decode to then?
01:09imirkin: there's a CMD_SURFACE which takes an index
01:09imirkin: but an index into what?
01:10mwk: you can set up 8 surfaces
01:10mwk: by CMD_SURFACE
01:10mwk: every surface has two things
01:10mwk: chroma offset and luma offset
01:11mwk: CMD_SURFACE sets either chroma or luma offset of a single surface
01:11imirkin: oh. are there words that follow CMD_SURFACE?
01:11mwk: on pre-NV31, IIRC there is no base, the offsets are just VRAM addresses
01:11mwk: bits 0-23 of CMD_SURFACE are the offset
01:11imirkin: oh wow. i'm just blind. ok.
01:12mwk: AFAIK the surface state is not exposed in MMIO for pre-NV31
01:12imirkin: yeah, that's less important
01:12mwk: few things are, really
01:13imirkin: ok, so you can set 4 full surfaces, i.e. 2 planes each?
01:13mwk: 8 surfaces, 2 planes each
01:13imirkin: ah, so each index can store 2 planes?
01:13imirkin: ok cool
01:13mwk: has to, in fact
01:13imirkin: well, you only need a P and B frame...
01:13mwk: the offsets are independent, but they form a single surface
01:14imirkin: (and the current frame)
01:14mwk: yeah, well
01:14imirkin: or maybe not? been a while since i've thought about mpeg1 or mpeg2
01:14mwk: PMPEG has no shortage of frames
01:14mwk: that's true
01:14mwk: but you can also have a pipeline of 8 frames or so
01:14mwk: and avoid resending offsets all the time
01:15mwk: in principle, you can do with 3 frames, sure
01:15imirkin: right. my plan is to create a custom libXvMCW btw :)
01:15imirkin: er, a custom library loaded by libXvMCW
01:15imirkin: but that's ... eventually.
01:15mwk: haha, finally
01:16imirkin: (mesa produces that for nv31+, but that won't fly for those earlier boards)
01:16imirkin: i want to use it in conjunction with overlays
01:17imirkin: it'll be a lot of pointless work =]
01:17mwk: well, I'm the one REing NV1...
01:34imirkin: mwk: and presumably those surfaces must be in VRAM right?
01:35mwk: PMPEG image surfaces in SYSRAM are not supported until G80
01:35mwk: more annoyingly, even DATA/CMD buffers can only be in AGP and not PCI memory until NV40
01:36imirkin: the NV4A got upset at that too
01:37imirkin: btw, just double-checking ... there's no way to even feed it a data buffer for nv17 -- it has to be inline right?
01:38imirkin: and i fiddle with CMD_* to write new commands in
01:38imirkin: <reg32 offset="0x228" name="CMD_PUT"/> <!-- ffffffc0 on pre-NV31, fffffffc NV31+ -->
01:38imirkin: wait, is this saying that i have to write commands in blocks of 0x40??
01:39mwk: yeah, separate data buffer is not supported prior to NV31
01:39mwk: pre-NV31, you have to submit shit in blocks of 0x40 bytes
01:40imirkin: i guess that's what the NOP command is for
01:40mwk: you're welcome to make use of NOP commands
01:40mwk: FWIW the pre-NV31 path and NV31 are quite damn different
01:41mwk: even on NV31, if you request the NV17 class, PMPEG becomes.... different
01:41mwk: it suddenly accepts only 0x40-byte aligned blocks and stuff
01:42mwk: and inline data instead of external
01:43mwk: damn, I really need to make hwtests for PMPEG
01:43mwk: I used to think it was impossible due to all these strange internal computations involved
01:43mwk: but... I've learned a few tricks since then
01:43mwk: it seems downright easy compared to the hell that is the Celsius XF unit
01:44imirkin: wait, you mean the class written into ... i forget-where in the nv31 grobj?
01:45imirkin: iirc we decided that was cargo-culted and unnecessary
01:45mwk: I mean the COMPAT_MODE thing
01:45imirkin: or you just mean the fifo vs direct interface?
01:45mwk: reg 0xb220
01:45imirkin: ah fun
01:45mwk: if you write 0x17 here, PMPEG suddenly reverts to the direct-mode NV17 interface
01:45mwk: and half the features are unsupported
01:46mwk: write anything other than 0x17, and it becomes the PFIFO-loving NV31 version
01:46imirkin: nvkm_wr32(device, 0x00b220, 0x00000031);
01:46mwk: yeah, that's rather necessary
01:47mwk: since, on reset, PMPEG has 0x17 here and is in the old mode
01:47mwk: matter of fact, absolutely any value other than 0x17 will do in practice
01:48imirkin:wonders if it's worth exposing this mode in nouveau
01:48imirkin: kind of a pain to do that, unfortunately
01:48imirkin: would help with testing though
01:50mwk: the entire NV17 mode is made of pain, unfortunately
01:56whompy: imirkin: want an NVA5 glxinfo?
01:56imirkin: whompy: yes please!
01:56imirkin: for 17.1.x
01:56whompy: Looks like its missing, and I'm oh-so-conveniently running 17.1.5:)
01:56imirkin: glxinfo -l -s
02:00mwk: gotta love these "suggested alternative" things in gcc
02:00mwk: it keeps coming up with perfectly useless suggestions
02:00imirkin: whompy: thanks, it's up now
02:02mwk: "undefined variable mode, surely you meant that modf function from math.h you never heard of?"
02:05mwk: "undefined variable mode, surely you meant that modf function from math.h you never heard of?"
02:09imirkin: skeggsb: what prevents a reloc'd buffer from moving in between 2 submits?
02:10imirkin: skeggsb: e.g. let's say i set the RT to some buffer and provided it as a reloc thing, the address gets fixed up, everyone's happy
02:10imirkin: skeggsb: and then i do another submit that leaves the RT alone, but in the meanwhile stuff has happened and that buffer got evicted and placed back into a different location
02:11imirkin: skeggsb: won't the HW have a confused view of the world, since its RT setting still points at the old place?
02:11skeggsb: you have to make sure you submit the methods (or whatever) the change the address *every* submit
02:11imirkin: but you're not changing the address...
02:11skeggsb: it's what the stupid PUSH_MTHD stuff is in the nv30 gallium driver
02:11imirkin: so basically on EVERY submit it pushes the RT address and whatnot?
02:11skeggsb: they'll turn into NOPs if the buffer doesn't move
02:12imirkin: almost as if you thought of that scenario ;)
02:12skeggsb: the whole thing is fucked up if you ask me, but, necessary...
02:12imirkin: yeah. just thinking about an API for this mpeg thing
02:12skeggsb: haha yeah, i didn't make it horrific for the fun of it :P
02:13imirkin: that doesn't sacrifice perf, but that also isn't completely horrid
02:13imirkin: i think it's fine to let userspace pin up to 8 surfaces for the duration of decoding
02:13imirkin: and then the reloc stuff becomes less horrible
02:14imirkin: although it presents some other annoying scenarios... hm
02:15imirkin: yeah ok. so for each tracked surface i could keep track of a watermark - once i get a sync, i know it's ok to release it (if it's been unpinned)
02:16imirkin: skeggsb: how do you feel about userptr's in nvif?
02:17imirkin: (or do i need to use usif? what is that thing?)
02:19imirkin: and/or suggest a proper way of implementing a way to pass a chunk of data to mpeg
02:20skeggsb: i think you just want a standard ioctls like the existing submission ones
02:21skeggsb: standard ioctl*
02:21imirkin: and some kind of nvif_mpeg_submit_data() thing that gets called?
02:22imirkin: that stuff needs to end up in vram i guess
02:23skeggsb: nope, leave nvif out of it aside from implementing the 0x1774 class
02:23skeggsb: everything else in the drm code
02:23imirkin: well there's no fifo involved... what would the 0x1774 class do?
02:23imirkin: just to get a handle on the device?
02:24skeggsb: point PMPEG at its ring buffer, and whatever other poking you need to do to make it ready to accept comamnds
02:24skeggsb: (ie. what the fifo classes do now)
02:24imirkin:will have to go do a lot more reading
02:26imirkin: so e.g. nv17_fifo has a .chan = &nv17_fifo_dma_oclass. and presumably some surrounding thing instantiates that class.
02:27imirkin: but the way all this stuff works together is completely incomprehensible to me
02:27skeggsb: i think the closest example to what you want is probably sitting in the devel-fault branch in my repo actually
02:27skeggsb: you'd implement the nv17 mpeg in a similar way to i did the fault buffer class
02:27imirkin: ok, will take a look
02:27skeggsb: as in, the plumbing for it, not the actual code :P
02:29imirkin: fault/gp100: initial implementation of MaxwellFaultBufferA
02:29imirkin: specifically that commit right?
02:31imirkin: ok, and that user.c contains the "fake" class stuff
02:32skeggsb: yeah, that's the implementation, the plumbing stuff is in base.c
02:33imirkin: so base.c is going to be nv17.c and user.c is going to be channv17.c (sorta)
02:33skeggsb: yeah, if you will
02:34skeggsb: or just stick it all in nv17.c, up to you
02:34imirkin: sure, code can go whereever
02:35imirkin: and then in the nouveau (non-nvkm) code, i instantiate a NV17_MPEG_CLASS object, and can use it via nvif to do whatever?
02:35imirkin: ok. i think that makes sense.
02:36imirkin: unfortunately i'm tired now, but hopefully it'll still make sense to me tomorrow :)
02:45imirkin: skeggsb: what should i search for in the driver for how nouveau_bo_wait works?
02:46imirkin: aha. nouveau_bo_sync_for_cpu
02:46imirkin: and probably reservation_object_wait_timeout_rcu ?
02:47imirkin: and it's all done via nvbo->bo.resv
02:50skeggsb: imirkin: the simple version is: every submission, a fence is created and assigned to all the buffers that submission touches, bo_wait waits on that fence
02:50imirkin: aha, so i just create a new fence and attach it to the bo
02:50imirkin: and then ... hopefully some way to signal it.
02:50imirkin: (do you remmeber where that lives offhand?)
02:50skeggsb: the specifics, i'm not 100% familiar with these days, i wasn't the last to touch it
02:50imirkin: maybe it's that one :)
02:51skeggsb: it's all been converted to some common fence/reservation thingo
02:51imirkin: hmmmmm unfortunately it seems to be directly tied to this seqno business
02:52imirkin: ok, but i can just expose that api
03:46mwk: so VP textures accept only linear textures and cannot do swizzle, correct?
03:46skeggsb: nfi, i don't think any of us have ever tried to use them
03:49mwk: it seems the only accepted thing is linear, not-rect, format 0x1b or 0x1c
03:49mwk: neither of which is known
03:50skeggsb:would guess some floating point formats?
03:50skeggsb: those seem to make sense for vertex data
03:50mwk: also, only 1D and 2D textures; 3D is rejected and CUBE doesn't even bother with having a bit to reject
03:51mwk: oh right
03:51mwk: 0x1b is RGBA32F
03:51skeggsb: #define NV40_3D_TEX_FORMAT_FORMAT_R32F 0x00001c00
03:51skeggsb: #define NV40_3D_TEX_FORMAT_FORMAT_RG16F 0x00001f00
03:51mwk:hasn't noticed that
03:51skeggsb: we have those defined on the gallium driver
03:52mwk: and 0x1c would be R32F, ok
03:53mwk: it's going to be a long journey once the dust settles on hwtest
03:53mwk: gathering all the information from various sources on what the values *mean* and compiling it into some documentation
03:56mwk: alright, full 8 wrapping modes supported, good
03:56mwk: no cylindrical wrap obviously
03:59airlied: mwk: is that nv30?
03:59airlied: seems pretty limited to implement any sort of vertex texturing API
03:59mwk: NV30 doesn't have any vertex textures
04:03airlied: mwk: oh indeed the docs say it only supports two formats
04:03airlied: page 12
04:03mwk: well then, let's rejoice
04:03mwk: documentation matches hardware
04:03airlied: well powerpoint presentations :-P
04:05mwk: ah right, weirdo CGI mermaid
04:05mwk: good times
04:05airlied: the CGI mermaid knows all
04:09mwk: well that was real quick for something that is related to texturing
04:09mwk: this hting really is limitted
04:09mwk: absolutely nothing surprising found
04:11mwk: and that concludes today's TODO list, good night
14:10mwk: that's a lot of unks.
14:11imirkin_: ah ... the cylwrap thing. gotta love that.
14:11mwk: got any experience with cylinder wrapping?
14:11imirkin_: none whatsoever.
14:11mwk: I mean, the cylwrap B thing is sort of a guess, but it matches
14:11imirkin_: beyond knowing of its existence.
14:45Bl4ckb0ne: hi, is the FeatureMatrix up to date for NV110?
14:51karolherbst: Bl4ckb0ne: not quite sure. There was work done on the 2D parts
14:51karolherbst: also power management ist done for nv11X
14:52Bl4ckb0ne: I could give it a try this week end with the latest kernel available for arch
14:53imirkin_: Bl4ckb0ne: do you have a concrete question about it? should all be mostly supported.
14:53Bl4ckb0ne: I remember having a lots of problem with my card
14:53Bl4ckb0ne: no, jsut the overall status
14:53Bl4ckb0ne: I don´t often check the matrix, but nothing has change in the last few months for NV110 (might be wrong tho)
14:58Bl4ckb0ne: I have a msi GTX970, does anybody run this card here?
14:59mooch: sorry, mine's a gtx 750ti
14:59imirkin_: Bl4ckb0ne: no one here i think, but it should work now
14:59imirkin_: there were issues with GTX 970 with 4GB of VRAM
14:59imirkin_: however they are now resolved.
14:59Bl4ckb0ne: I´ll give it a try this week end
14:59Bl4ckb0ne: on latest kernel?
14:59imirkin_: 4.12.x should be fine for it
15:00imirkin_: note that there's no reclocking, so you'll have shit-for-perf compared to blob
16:20ccaione: hi. I'm hitting hard against https://bugs.freedesktop.org/show_bug.cgi?id=101782, any hint / idea?
16:27imirkin_: try booting with HDMI plugged in?
16:28imirkin_: oh, i probably should read the bug, huh
16:28imirkin_: the issue is that something's returning -ENOSPC ?
16:28imirkin_: which means .... something funny's happening.
16:29imirkin_: ccaione: are you logged in on this setup right now?
16:31ccaione: imirkin_: yup
16:31imirkin_: can you run
16:31imirkin_: xrandr --output HDMI-1-1 --same-as eDP1 --auto
16:32ccaione: imirkin_: with the HDMI cable connected?
16:33ccaione: imirkin_: https://pastebin.com/etT5ZAdT
16:33ccaione: also `xrandr: Configure crtc 4 failed`
16:33imirkin_: fckn gdm. ok.
16:33imirkin_: er, not gdm. gnome. whatever.
16:34ccaione: also I had to patch xorg with https://bugs.freedesktop.org/attachment.cgi?id=116150 to avoid Xorg from crashing when connecting the cable
16:34imirkin_: ah, yeah, can't have that.
16:34imirkin_: you must be running an old xf86-video-nouveau.
16:34imirkin_: and a new xorg
16:35imirkin_: er hm, maybe not
16:35ccaione: I swear I tried with the xf86-video-nouveau HEAD and it is the same. let me try again.
16:35imirkin_: hold on
16:35imirkin_: what version of Xorg and what version of nouveau do you have?
16:36imirkin_: (can you just pastebin your xorg log?)
16:36ccaione: nouveau: 1.0.15 + xorg: 1.19.2
16:37imirkin_: yeah that should be fine
16:37imirkin_: i figured you were on like nouveau 1.0.12 or something silly like that =/
16:37imirkin_: try with modesetting as the driver for G0? should be about the same
16:38ccaione: imirkin_: by disabling nouveau at all?
16:39imirkin_: in xorg config.... hrm. might not be easy.
16:40ccaione: yeah, do you have any idea what could be the deeper cause?
16:41imirkin_: not offhand
16:41imirkin_: try restarting X with hdmi plugged in?
16:41ccaione: no luck
16:42ccaione: also it's weird that without the patch I have Xorg crashing
16:42imirkin_: yeah. it's highly related though.
16:42imirkin_: can you pastebin your xorg log?
16:42imirkin_: i suspect there's something interesting in there
16:42imirkin_: unfortunately you only have snippets in that bug
16:43ccaione: yeah, let me reboot to have a cleaner log
16:48ccaione: imirkin_: https://pastebin.com/KVGN3YMX, extracted from journal since `(++) Log file: "/dev/null"`
16:53imirkin_: of course it is..
16:54imirkin_: Aug 08 18:44:53 endless gdm-Xorg-:0: (EE) NOUVEAU(G0): Error creating GPU channel: -19
16:54imirkin_: Aug 08 18:44:53 endless gdm-Xorg-:0: (EE) NOUVEAU(G0): Error initialising acceleration. Falling back to NoAccel
16:54imirkin_: ok, that's why it doesn't work
16:55ccaione: we have a quirk in place to boot with `noaccel` IIRC
16:55ccaione: is that related?
16:55imirkin_: highly :)
16:56imirkin_: why did 'we' have such a quirk?
16:56ccaione: because otherwise we are unable to boot :)
16:56imirkin_: well, then that is a problem for us :)
16:56imirkin_: (right, i remember now)
16:57imirkin_: yeah, your gr is fucked iirc
16:57imirkin_: sorry... can't do the prime offload without accel
16:57imirkin_: it uses the copy engine to (surprise surprise) copy the framebuffer out iirc
16:58imirkin_: you could run a separate X screen on there just fine of course
16:58imirkin_: although that's generally not what people want
16:59imirkin_: (and in the xinerama darkness bind them)
16:59ccaione: yeah, not something on the table
16:59ccaione: well, at least we have now an explanation for this
17:00ccaione: thank you for looking into this
17:02imirkin_: sorry there's not a better answer
17:03ccaione: yeah, we should really fix the `noaccel` thing then
17:04imirkin_: yes ... we ...
17:04imirkin_: taken to mean 'the class of people that does not include me'
17:07ccaione: well, I swear I try my best to make my mind around nouveau and GFX drivers in general but I guess you have to work 100% on this topic to be able to contribute with something sensible
17:07imirkin_: or work on problems that aren't completely dumbfounding
17:08ccaione: yeah, unfortunately most of the time I'm bouncing on 20 different hw issues at time
17:08imirkin_: that's a lot of bounce.
17:08imirkin_: can you update that bug with our findings?
17:11imirkin_: [and probably close it, since it's not a bug]
17:11imirkin_: [and you have another bug open for the accel thing iirc]
17:13mwk: and done
17:13mwk: all remaining Curie methods do scary things or nothing at all
17:34karolherbst: I feel like wanting to fix bugs today, any suggestions?
17:36mangix: karolherbst: MMIO read errors with your maxwell2 branch :P
17:37karolherbst: I also kind of need the hardware for this
17:37karolherbst: and those are super unimportant though
17:37karolherbst: I rather fix bugs which have some kind of negative effect
17:41imirkin_: karolherbst: ARB_pipeline_statistics_query for compute.
17:41imirkin_: or any of the other CTS failures for that ext
17:41karolherbst: uhh CTS, perfect
17:42karolherbst: first I care about those 4.4 mustpass
17:42karolherbst: then 4.5
17:43imirkin_: it's core in 4.6 ;)
17:43karolherbst: well, 4.6 comes after 4.5 ;)
17:43imirkin_: really? huh. maybe that's why my math prof failed me...
17:47imirkin_: fine, then fix the ARB_query_buffer_object failures
17:47imirkin_: that's GL 4.4
17:50karolherbst: is it possible to do a full run now by the way?
17:54karolherbst: imirkin_: did you see my bug fix I send out? mul const folding with sat?
17:54karolherbst: imirkin_: https://patchwork.freedesktop.org/series/28082/
17:59imirkin_: i need to rtfs to see if it's reasonable
17:59imirkin_: i can't tell from just the patch
17:59imirkin_: keep pinging me ;)
17:59imirkin_: [did i merge your OP_MUL stuff?]
17:59imirkin_: er, the POW thing?
17:59imirkin_: oh, i wanted you to redo it right
18:00karolherbst: yeah, true
18:00karolherbst: but you merged the precise series
18:00karolherbst: I should make a list
18:14imirkin_: hakzsam: there are bindless CTS tests right?
18:14imirkin_: could try to use those to figure wtf i'm doing wrong
18:16hakzsam: imirkin_: no bindless CTS
18:16imirkin_: srsly? :(
18:16hakzsam: or they are pretty recent
18:29karolherbst: "KHR-GL44.arrays_of_arrays_gl.InteractionFunctionCalls2" needs a lot of time to finish :/
18:29imirkin_: and it crashes iirc
18:29imirkin_: it triggers some sort of super-slow in our compiler i think?
18:30karolherbst: might be
18:30karolherbst: or it just does a lot of tests? dunno
18:52karolherbst: uhh, "KHR-GL44.arrays_of_arrays_gl.SubroutineFunctionCalls1" has spilling fun
19:15karolherbst: okay nice, KHR-GL44.copy_image.functional triggers an assert
19:16Tom^: karolherbst: does the 10xx series upclock? i know about the other issues like fan and things. :P
19:16karolherbst: unknown packed format
19:16karolherbst: Tom^: no
19:16karolherbst: need signed pmu firmware for that
19:17Tom^: so the firmwares that were released for them wasn that?
19:17karolherbst: uhm, PIPE_FORMAT_B4G4R4A4_UNORM
19:18karolherbst: imirkin_: do you know offhand what get_canonical_format(PIPE_FORMAT_B4G4R4A4_UNORM) should return?
19:19karolherbst: reading the comment it might not be even called with that
19:23karolherbst: disabling the BGRA4 formats "fixes" this....
19:28imirkin_: karolherbst: i sent a question about it
19:28imirkin_: to the list
19:28imirkin_: it's a VERY annoying issue
19:28karolherbst: seems like it
19:28karolherbst: we also had this bug in roguelegacy
19:29imirkin_: when you create a GL_RGBA4 *render buffer*
19:29karolherbst: well, still have
19:29mwk: hmm, do we know anything about instanced drawing on NV40?
19:29imirkin_: not at all.
19:29imirkin_: mwk: it works fine, afaik
19:29karolherbst: ohh okay, different issue, same feature?
19:29imirkin_: karolherbst: when you create a GL_RGBA4 renderbuffer, the backing buffer is, in effect, BGRA8
19:29imirkin_: which is perfectly legal.
19:29mwk: imirkin_: looking at gallium driver right now, the PIPE_CAPs are not supported
19:30imirkin_: mwk: iirc i couldn't get the gl_InstanceID working? osmething like that.
19:30imirkin_: karolherbst: glCopyImage is supposed to work between a renderbuffer and texture of the same format
19:30imirkin_: karolherbst: and at the GL-level they *do* have the same format
19:30imirkin_: karolherbst: however their backing buffers are totally different
19:31imirkin_: karolherbst: this causes various chaos on the st/mesa stuff.
19:32mwk: imirkin_: nope, sorry, I don't see anything about instances in gallium
19:32imirkin_: mwk: i could be mixing it up =/
19:33karolherbst: imirkin_: the question I have now is, is it worth fixing it all up or should we simply disable BGRA4 until we fix it?
19:33karolherbst: which might never happen if there is no benefit
19:33imirkin_: karolherbst: yes, a good question. i ahte the idea of nuking BGRA4. i think it "plays" for dx9
19:34karolherbst: but having a "broken" feature enabled doesn't work out well as well
19:34imirkin_: mwk: yes, you are correct. not sure what i was thinking. nv40 *does* have instancing afaik
19:34karolherbst: and rogue legacy is broken due to this
19:34imirkin_: karolherbst: they were broken due to unreasonable expectations of GL formats
19:35karolherbst: yeah, I am aware
19:35imirkin_: karolherbst: and afaik they changed their stuff to be more reasonable
19:35imirkin_: karolherbst: the copy image thing is a bit more annoying
19:35karolherbst: doesn't make it less pain for the users though
19:35karolherbst: imirkin_: ohh okay, I could check it
19:35imirkin_: of course i've *never* *ever* *ever* seen *anyone* copy from *any* renderbuffer, of any format
19:35imirkin_: [using glCopyImage]
19:35imirkin_: so it's not exactly likely to come up for the average user.
19:36karolherbst: mhh, assert inside "KHR-GL44.enhanced_layouts.varying_array_locations"
19:37karolherbst: ../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:5809: ureg_src src_register(st_translate*, const st_src_reg*): Assertion `t->inputMapping[index] < ARRAY_SIZE(t->inputs)' failed.
19:37imirkin_: lol. too many inputs, overflowed the array.
19:37imirkin_: probably some dumb packing thing.
19:38karolherbst: 176 in t->inputMapping[index]
19:38imirkin_: seems high.
19:38imirkin_: i thought like 64 was the max :)
19:38imirkin_: maybe not
19:38karolherbst: ARRAY_SIZE is 80
19:38imirkin_: i don't remember how that stuff works.
19:39karolherbst: yeah okay
19:39karolherbst: I disable those tests for now anyway, because I want a list of tests which have to be fixed to do a complete run
19:41airlied: I think you can run inside piglit to get a better list and parallel execution
19:42imirkin_: mwk: flag to NV30_3D_VERTEX_BEGIN_END if nv50 is to be believed, and then an instance increment thing in VTXFMT? dunno.
19:44karolherbst: airlied: yeah, I heard about this, but parallel execution is kind of dangerous on nouveau, but maybe it's fine now. Just wanted to use whatever works for now
20:07karolherbst: imirkin_: https://gist.github.com/karolherbst/c32728e2aa1e0d8f62c4d501a1061f23
20:09imirkin_: karolherbst: should probably get the list of Failed lists too
20:09imirkin_: anyways, not so bad.
20:09imirkin_: i've seen worse ;) is that just the GL44 list, or the GL45 list too?
20:09imirkin_: karolherbst: you can use log_to_csv.py | grep Failed
20:10imirkin_: i think the AoA stuff is mostly RA fail, but dunno
20:11garlox[m]: Hi channel. After upgrading my Arch Linux kernel from 4.11.9 to 4.12.4, modesetting with my M1000M doesn't work anymore. It just gives distorted output and Xorg doesn't start.
20:12garlox[m]: Has support for this graphics chip been dropped?
20:12imirkin_: more likely added
20:12imirkin_: is it a GM107?
20:12karolherbst: imirkin_: 4.4
20:13imirkin_: if it's a GM107 i dunno what would have changed
20:13imirkin_: pastebin dmesg + xorg logs
20:13garlox[m]: GM107GLM yes
20:14garlox[m]: Okay I'll try
20:14karolherbst: imirkin_: log_to_csv.py?
20:14imirkin_: karolherbst: in the scripts dir
20:15imirkin_: it analyzes the giant TestResults.qpa file
20:15karolherbst: of deqp?
20:15karolherbst: or piglit?
20:15karolherbst: inside the build directory...
20:16imirkin_: well, whereever you ran glcts
20:16karolherbst: no, the script is inside my build dir
20:16imirkin_: ah. that's surprising.
20:20rhyskidd_: ccaione: I'm going to spend more time this weekend on the GP107 (mobile) accel problems.
20:20rhyskidd_: I have proper mmiotrace's now of the blob, so going to give nouveau a push again on v4.13-rcX
20:21ccaione: rhyskidd_: great. I have the hardware if you need anything
20:21rhyskidd_: Will put comments here, as the main bug tracking that hw bringup: https://bugs.freedesktop.org/show_bug.cgi?id=100228
20:22rhyskidd_: OK. I've got the hardware too. Comes in variants of Dell's XPS 9560
20:23rhyskidd_: And I know from bug reports one other Mesa developer has the hw too with problems, although they are primarily an i965 dev
20:31garlox[m]: imirkin_: I compared the kernel logs before and after the kernel update. Here are the relevant dmesg snippets before / after: https://pastebin.com/y34iCMb5
20:32garlox[m]: It suddenly says "eDP-1: EDID is invalid"
20:37garlox[m]: Looks just like this error: https://firstname.lastname@example.org/msg1395798.html
20:40imirkin_: oh, i know that issue
20:40imirkin_: aaaand skeggsb hasn't backported the fix yet
20:40garlox[m]: Ah, so there is a fix?
20:41imirkin_: yeah hold on
20:41imirkin_: skeggsb: backport that :)
20:45garlox[m]: Ah, well, cool. At least I know somebody has it on his list already ;) I will use the integrated (slow & laggy) intel graphics for now then
20:45garlox[m]: imirkin_: Thanks!
20:46imirkin_: or you can use v4.13-rcN
20:46imirkin_: actually i'm not sure if ben's done a fixes pull for that either yet....
20:46imirkin_: ah yes, looks like he has.
20:47imirkin_: commit 13a86519202c5d119d83640d6f781f3181205d2c upstream
20:48imirkin_: in v4.13-rc3 and up
20:49garlox[m]: Great. Then I just need to find suitable AUR package
20:50garlox[m]: ..found ;)
22:31garlox[m]: imirkin_, skeggsb Just as a feedback, with the 4.13-rc3 my GM107 works fine. Thanks again!