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