02:13 thaytan: Lyude, I just realised that the backlight patch I linked you the other day as being the one I am testing was missing an uncommitted line, and it was important
07:04 drawat: https://lists.freedesktop.org/archives/dri-devel/2020-June/270028.html is totally different effort, I am doing on my spare time. I was not aware of other GPU related work from MS until it went public
07:10 drawat: This is a simple video device already exposed by hyper-v for which nobody wrote a DRM driver.
07:58 bbrezillon: karolherbst, jekstrand: When you get a chance, could you have a look at the vtn/nir bits in https://gitlab.freedesktop.org/kusma/mesa/-/commits/ms/cl-packed-struct ?
08:00 bbrezillon: one thing in particular that's bothering me is the fact that some places use the cached stride/offset info while others calculate it based on a size_align() func
08:31 danvet: sumits, imo just add könig for all of dma-buf, he's also done the p2p stuff, locking changes, it's plenty all around
08:34 j4ni: is there a way to only build src/intel/tools/i965_asm.c in mesa? meson config tips?
08:35 danvet: airlied, I guess backmerge -rc3 because of the conflict sfr hit? after you pulled in mlankhorst's latest pr
08:36 danvet: hm only just landed
08:36 danvet: mlankhorst, ^^ I guess high time for that backmerge, -misc-next seems to be quite diverged
08:44 MrCooper: j4ni: meson configure <build dir> -Dtools=intel , then ninja -C <build dir> src/intel/tools/i965_asm
09:09 bbrezillon: jekstrand: oh, and there's also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5588 if you find some time for a review
09:39 j4ni: MrCooper: thanks, but the trouble is I have dependency issues with things other than tools (libdrm)
09:40 MrCooper: you mean something requires newer libdrm than you have available?
09:47 j4ni: MrCooper: yeah
09:47 MrCooper: and it doesn't say what requires the newer libdrm?
09:48 j4ni:looks
09:58 j4ni: MrCooper: okay, that gave me enough clues to get config phase, thanks. you really can't configure with empty/no vulkan-drivers, you always have to choose something?
09:58 j4ni: now, onto the next problem, a build failure &/%/&!!%¤
09:59 MrCooper: you can configure -D{dri,gallium,vulkan}-drivers=
09:59 j4ni: hmm, I thought I tried that
09:59 j4ni: ../src/intel/dev/gen_debug.c:37:10: fatal error: git_sha1.h: No such file or directory
10:02 j4ni: maybe fails because of the partial build, trying to build the whole thing now
10:02 mlankhorst: danvet: ok will do
10:02 mlankhorst: danvet: was hoping for drm-next to update first
10:03 MrCooper: j4ni: partial builds should work, otherwise probably something's missing / wrong in meson.build
10:04 j4ni: MrCooper: I know this is probably basic stuff, but I don't need to build mesa even once a year, so I keep tripping over...
10:04 j4ni: (I probably look like my son trying to learn to unicycle...)
10:18 mlankhorst_: pushed backmerge now to drm-misc-next
10:40 MrCooper: j4ni: building Mesa while unicycling will be impressive though! :)
10:53 karolherbst: bbrezillon: yeah.. seems to make sense, just wondering if it could break GL/Vk in a few places
11:14 bbrezillon: karolherbst: CI says it doesn't, but I'm not sure it covers all cases
11:14 karolherbst: bbrezillon: did you push it through intels CI? that usually covers a lot
11:15 bbrezillon: I don't remember how I can do that
11:15 karolherbst: then you probably can't :p
11:15 karolherbst: they listen on a branch in your repository for pushes
11:15 karolherbst: and once the branch changed the build is triggered
11:15 karolherbst: but this needs to be set up
11:17 j4ni: MrCooper: there's still some work to do on that front ;)
11:17 bbrezillon: ok, I can rebase what I have on master and provide you with a branch if you have intel CI set up on your repo
11:18 bbrezillon: karolherbst: BTW, still don't understand why nir_deref.c has its own field-offset/array-elem-stride calculation when it could use glsl helpers
11:19 bbrezillon: are there cases where we change the size_align() function (thus making cached values invalid)?
11:22 karolherbst: bbrezillon: don't kno
11:22 karolherbst: w
11:22 karolherbst: but yeah, I'd be happy to push your branch through the CI
11:42 Venemo: jekstrand or Kayden, in nir_lower_gs_intrinsics why is the set_vertex_count appended to each predecessor of the end block, rather than at the beginning of the end block?
11:46 Venemo: what happens if the shader emits one more vertex in the end block?
11:46 Venemo: or is that impossible?
11:59 karolherbst: Venemo: "emit" as in "emit" or just writing it out without actually doing an emit?
11:59 Venemo: karolherbst: I'm not sure what you mean. what I mean is the emit_vertex intrinsic
12:01 Venemo: what nir_lower_gs_intrinsics does is replace emit_vertex -> emit_vertex_with_counter, and end_primitive -> end_primitive_with_counter. then it appends a set_vertex_count at the end of the shader, to all predecessors of the end block. that is why I'm wondering why that isn't actually in the end block itself
12:05 Venemo: also what if the shader only has one block?
12:10 pendingchaos: Venemo: IIRC the end block isn't really an actual block and doesn't ever have any instructions
12:11 Venemo: that would explain it pendingchaos
12:14 jenatali: bbrezillon: I had asked karolherbst that same question a couple weeks ago when I first looked at packed structs. Seems like an oversight, unless there's a really good reason for it
12:30 bbrezillon: karolherbst: here is the branch => https://gitlab.freedesktop.org/bbrezillon/mesa/-/commits/nir-load-store-alignment
12:32 karolherbst: bbrezillon: triggered the CI. Result should be there in like 1-2 hours
12:32 bbrezillon: karolherbst: thanks
12:41 karolherbst: bbrezillon: build 147 in https://mesa-ci.01.org/karolherbst/builds/
12:41 karolherbst: doesn't exist yet, but it will later :p
12:45 bbrezillon: karolherbst: looks like it regresses freedreno https://gitlab.freedesktop.org/bbrezillon/mesa/-/jobs/3338877 :-/
12:47 karolherbst: :/
12:47 karolherbst: annoying to debug
12:47 karolherbst: let's wait for intels result, that's usually quite simple to debug on local hardware :p
12:51 Kayden: Venemo: Yeah, the end block is just a "this is the end" marker, it doesn't actually contain anything at all
12:51 Kayden: so we can't put anything there
12:52 Kayden: there's typically only one "predecessor of the end block"
12:52 Kayden: but in theory if you hadn't lowered returns there could be a couple
12:53 Kayden: (returns in main(), that is)
12:53 karolherbst: well, we don't lower returns
12:54 karolherbst: or.. does it happen automatically when doing glsl to nir?
12:54 karolherbst: mhh
12:55 karolherbst: ohh right, it's required before inlining functions
12:55 karolherbst: nvm then
13:03 Kayden: yeah
13:03 Kayden: so practically "add to predecessors of the end block" is just a weird trick to "put these at the end of the program"
13:03 Kayden: instead of trying to ... make a block ... then merge the block with whichever is actually already in the right spot
13:03 Kayden: it's a bit awkward since there really only is one, but...*shrug*
13:09 Venemo: Kayden: thanks for explaining
13:43 danvet: pinchartl, nag about the review on the vblank reset patch
13:46 pinchartl: danvet: thanks for pinging me, I'll give it a look
13:47 danvet: much appreciated
13:59 sumits: danvet: oh, I didn't mean konig doesn't know other areas, I just meant it seemed like he was interested in the dma-fence bits the most. Apologies if my response sounded otherwise!
14:00 pcercuei: I'm pretty certain that mipi_dbi_spi1_transfer() in drm_mipi_dbi.c never worked, even when it was introduced in 2017
14:00 pcercuei: I looks just broken
14:02 pcercuei: It unpacks (len) 8-bit values into (len) 9-bit values in 16-bit storage form, that's fine. But then it sets the SPI transfer to (len) bytes
14:02 pcercuei: It should be (len) * 2
14:03 pcercuei: If I add the * 2, my panel starts to work
14:06 pcercuei: I'll ping sravn about it when he's online
15:59 jekstrand: Venemo: The end block is a dummy that's not allowed to contain instructions
16:10 Venemo: jekstrand: thx, yeah
16:12 Venemo: jekstrand: does this make sense to you? https://gitlab.freedesktop.org/Venemo/mesa/-/commit/f6d9fdbc31eb87d1fe19d005b3a743d8adaf4d8c and https://gitlab.freedesktop.org/Venemo/mesa/-/commit/5e3ebb604180332c7d58e3c1d4fc39c0d3151982
16:16 Venemo: I think those are all we need from the GS intrinsics, for now at least
16:22 Kayden: Venemo: You have everything named consistently "primitive count". But it doesn't look like it's counting primitives. It looks like it's counting vertices per primitive...?
16:22 Kayden: ah, no, it's doing both
16:23 Kayden:rereads
16:24 Venemo: Kayden: one of the patches counts the number of emitted primitives, the other the number of vertices per primitive
16:24 Kayden: right.
16:25 Venemo: or at least that's what I indend them to do :P
16:27 Kayden: Venemo: found a bug in patch 2
16:27 Kayden: nir_lower_gs_intrinsics_count_primitives = 1 << 1,
16:27 Kayden: nir_lower_gs_intrinsics_count_vertices_per_primitive = 1 << 1,
16:27 Kayden: think you want 1 << 2 there. :)
16:28 Kayden: otherwise these look fine to me
16:29 Kayden: do you actually care about the total vertex count?
16:29 Kayden: (the existing counter?)
16:29 Kayden: if not, I guess you could make that undef as well...?
16:30 Venemo: thx, yeah good catch, Kayden
16:30 Venemo: and yes, I need the total count too
16:33 Kayden: cool. looks good then :)
16:40 Venemo: will open a MR once the whole thing comes together
17:41 Lyude: thaytan: hm?
17:43 thaytan: Lyude, I linked to a gist the other day with the DPCD brightness patch I was testing, but I left out the line from the dpcd_quirk_list[] table thinking it wasn't important because of the tcon_cap[] test
17:43 thaytan: but it turns out that on this laptop the quirk is being set by matching the table entry, not the tcon bits
17:44 thaytan: only noticed when I rebuilt the kernel without that line
17:51 Lyude: thaytan: I forget, did we have you test the vesa backlight interface on that machine?
17:51 Lyude: it might also be that we're just not setting the source OUI early enough - it probably should be programmed before we query for any kind of backlight support
17:52 thaytan: Lyude, I tested with i915.enable_dpcd_backlight - is that the VESA method?
17:52 Lyude: thaytan: if you didn't have the patches I linked to you yeah
17:53 thaytan: right - I tested the param with a fedora 5.6.19 kernel
17:53 thaytan: patching came later
17:53 Lyude: did vesa work or not?
17:53 Lyude: (sorry-can't remember D:)
17:55 thaytan: oops :)
17:55 thaytan: i915.enable_dpcd_backlight had no effect
17:55 Lyude: gotcha, it's probably the OUI not being set early enough then
17:55 thaytan: but a patched kernel does work with https://gist.github.com/thaytan/7cba2e4170dcd16119bc2c4f82426566
17:55 Lyude: hopefully I should have patches for you to try today or tommorrow that set it while probing the panel
17:56 thaytan: and the key part is the dpcd_quirk entry that's setting the quirk
17:56 Lyude: thaytan: yeah-that's why I'm suspecious it's just us not having the OUI programmed early enough
17:56 Lyude: since if it's not programmed it's likely the tcon_cap fields will be all zeroes
17:57 thaytan: our timezones don't overlap well (it's nearly 4am here), but if you want me to test anything feel free to drop an email
17:57 Lyude: sure thing
18:41 Marex: anholt_: mripard: hi, do you happen to know whether there is documentation for the RPi 7" display I2C protocol for that ATTINY88 ?
18:42 Marex: (that power sequencing chip, which can also program the tc358762 registers)
18:48 anholt_: there is not.
18:51 Marex: anholt_: can it do 4 byte writes into the tc358762 at least ? it seems the DSI host on stm32mp1 has broken register read/write over the DSI bus, so I wanted to test the display by writing the tc358762 registers via the i2c via that attiny
18:51 anholt_: I have nothing else to offer.
18:51 Marex: I almost succeeded, except I think the clock-invert bit is wrong
18:51 Marex: all right, thanks
18:58 Lyude: anarsoul: it's ok if you don't have the machine yet, but I figured I should let you know I have some quirkless patches to try :)
19:00 anarsoul: Lyude: it's quite opposite - I have the machine yet (haven't received a box yet to ship it to Dell - I assume it should arrive with replacement laptop - but Dell hasn't shipped it yet), I can give the patches a try
19:00 Lyude: anarsoul: perfect, let me throw them up on a gitlab branch then
19:16 Lyude: anarsoul: https://gitlab.freedesktop.org/lyudess/linux/-/commit/cb9db305cc33d05116fceae57d6feff8c428de4b shouldn't need to pass it any kind of kernel params
19:18 anarsoul: what branch is it?
19:19 anarsoul: found it
19:25 anarsoul: compiling
19:41 anholt_: kusma: looks like your CL branch is basically the thing that's left using the pre-baremetal cheza CI. you ok with just turning off freedreno ci in your branch?
19:41 anholt_: (I'm assuming it hasn't been rebased becasuse that's hard)
19:48 jenatali: anholt_: Pretty sure kusma's on vacation. Sounds like a question for daniels?
19:49 anholt_: ok, that seemed to be the repo things were flowing to
19:50 kusma: Yeah, it's my repo, but I'm away. But daniels has admin access ;-)
19:54 daniels: anholt_: sure, can do
19:55 anholt_: great, give me a heads up and i'll turn off the remaining 4 and start moving them over
20:01 anarsoul: Lyude: works for me (I cherry-picked last 2 commits from your branch onto 5.7.y and applied rejected hunks manually)
20:01 airlied: imirkin, mareko : in GL_NV_viewport_swizzle should the get params be ENUM16 not ENUM?
20:01 daniels: yep, just eating dinner so will do afterwards
20:02 Lyude: anarsoul: cool, it might take a little bit for this to go onto the mailing list because I want to poke vendors about legal stuff, but i'm going to poke a lot to speed that up as much as possible
20:02 imirkin: airlied: iirc i thought about that and decided on ENUM
20:02 imirkin: because they're a custom location
20:02 anarsoul: Lyude: sounds good, thanks for working on this!
20:02 imirkin: airlied: however i didn't do deep testing with things that'd be sensitive to that
20:03 airlied: imirkin: lots of other custom ones are ENUM16
20:04 airlied: enum16 getting is very broken on big-endian, I just noticed while fixing that
20:04 imirkin: airlied: there was some other reason...
20:04 imirkin: coz it has a custom Get impl? dunno. maybe my thinking was bunk too. i'm not looking at the code atm
20:07 airlied: maybe the indexed version
20:08 imirkin: yeah
20:09 imirkin: anyways, i wasn't putting a *ton* of thought into it, just making things work with minimal change. if it can all be done with ENUM16, that's fine too - just make sure the tests pass.
20:09 imirkin: (which will require a gm200+ GPU)
20:13 airlied: yeah my caring was limited to asking the question :-P
20:14 airlied: fixing big-endian is already unforgiving enough
20:14 imirkin: it's pretty unfortunate... someone makes an effort to fix it every like 2 years
20:14 imirkin: and then it slowly goes down the tubes
20:16 airlied: yeah I expect I'll just be making that effort every 2 years as well :P
20:16 airlied: I don't really feel like maintaining a distro to run on my big-endian ppc64 machine :-P
20:17 imirkin: maybe you can use qemu-softmmu to run stuff in CI?
20:17 imirkin: like is done for s390x (if that actually happened)
20:18 airlied: you can't do anything serious like that, too sllooow for regular CI
20:18 imirkin: hm ok. i've never tried that, but i did use intel's emulator for $betterprocessor on $shittierprocessor
20:18 airlied: but yeah we run some basic format tests in s390x
20:18 imirkin: and it was moderately fast, all things considered
20:19 imirkin: since it was emulating AVX/AVX2 on my ... non-AVX-capable processor :)
20:20 airlied: yeah so we run the unit tests under emulation
20:20 airlied: but piglit would me a major pita
20:20 imirkin: ah ok
20:20 airlied: and our unit tests expected fail for formats
20:20 airlied: which is kinda not great :-P
20:20 imirkin: kinda.
20:21 imirkin: hard to fix the world all at once
20:21 airlied: in theory if we still have travis ci and pushed a branch to github we could access s390 CI resources there :-P
20:21 airlied:doesn't really want to go down that road either
20:21 imirkin: should just get one yourself
20:22 imirkin: run over to best buy - i bet they're just full of s390's :)
20:23 airlied: the one I'm using right now might be very under provisioned
20:23 airlied: it's like how many LPARs can we sanely put on this, let's double that and see how we go
20:26 anholt_: for bonus points, the unit tests themselves have bad expectations for big endian
20:26 anholt_: so you can't even use them to make things better on be
20:26 imirkin: i assume that's the "expected fail" bit of airlied's comments?
20:27 anholt_: imirkin: one kind of xfails is "we know the impl is broken"
20:27 anholt_: "the test itself is busted" is just rude
20:27 imirkin: right
20:29 indrarahul: Hello Everyone, I am Rahul Indra, an undergraduate student at Indian Institute of Engineering Science and Technology, Shibpur. I am interested to work on the XOrg Endless Vacation of Code Program.
20:32 zmike_: hi!
20:34 indrarahul: Hi !!
20:35 indrarahul: I would love to start working on few issues before applying for the program, so that I can get to know the working environment.
20:36 indrarahul: Is the program still going on ?
20:38 anholt_: yeah, it's still running
20:39 indrarahul: Great !!
20:39 indrarahul: I am already working on Warmups.
20:48 airlied: anholt_: indeed those u_format_tests are pretty endian hostile
20:52 airlied:isn't even sure how to cleanly save them
20:53 airlied: like ifdefine the packing macros might work, but seems ugly
21:14 robher: pinchartl: r u okay with being maintainer on connector bindings? https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200618202447.872851-1-robh@kernel.org/
21:23 pinchartl: robher: sign me in
21:23 robher: pinchartl: thanks!
21:23 pinchartl: it's a very small burden compared to being the global DT bindings maintainer :-)
21:24 robher: pinchartl: that position has openings too. ;)
21:28 pinchartl: robher: and very few applications I would assume :-)
21:56 karolherbst: bbrezillon: you also use the same data layou across all address spaces, don't you?
21:57 karolherbst: bbrezillon: btw, those are the intel regressions in case you didn't see them: https://mesa-ci.01.org/karolherbst/builds/147/group/63a9f0ea7bb98050796b649e85481845
21:57 jenatali: Yeah we use the same layout across all address spaces
21:57 karolherbst: I can see that some don't for GL and Vk :/
21:58 karolherbst: but there it matters less
22:16 pcercuei: Is there a Makefile trick to build a foo.ko module from foo.c + bar.c files?
22:16 pcercuei: Or do I need to rename foo.c to foo_drv.c?
22:36 bbrezillon: karolherbst: yep, I saw them. trying to figure out what's going on there
22:40 Lyude: Hey y'all! I've been working on igt support for nouveau, and I've had a couple of patches for igt that have been sitting on the ML for a while without any review: https://patchwork.freedesktop.org/series/74806/ https://patchwork.freedesktop.org/series/74808/ (I'll fix the doc error for that one on the next respin) https://patchwork.freedesktop.org/series/74811/
22:41 Lyude: would anyone outside of nouveau be willing to volunteer to review (or at least ack) these?
22:45 Lyude: (if you want, I can even trade for reviewing your patches ;)