08:24 MrCooper: tanty: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7957
08:25 MrCooper: airlied: did you get a chance to test the latest revision of that?
10:10 tanty: dcbaker: would you have time for a quick review?
10:10 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/425
10:10 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/426
12:17 Sumera: danvet: I wanted to apply this patch https://lore.kernel.org/lkml/cover.1561950553.git.rodrigosiqueiramelo@gmail.com/#t so I wanted to know if there is any way to do this without manually doing all the code change.
12:19 danvet: Sumera, so this is the annoying part, you need to grab the raw message of each patch
12:19 danvet: so for first one here https://lore.kernel.org/lkml/f5b654ec89aa754d5f572f9fc983fbd0d861e1ce.1561950553.git.rodrigosiqueiramelo@gmail.com/
12:19 Sumera: I could, technically write a script to fetch the changes but it might take me longer.
12:19 danvet: there's the raw link https://lore.kernel.org/lkml/f5b654ec89aa754d5f572f9fc983fbd0d861e1ce.1561950553.git.rodrigosiqueiramelo@gmail.com/
12:19 danvet: then you need to feed that into git apply-mbox
12:19 danvet: can do a unix pipline, like
12:20 danvet: curl https://lore.kernel.org/lkml/f5b654ec89aa754d5f572f9fc983fbd0d861e1ce.1561950553.git.rodrigosiqueiramelo@gmail.com/raw | git apply-mbox
12:20 danvet: there's probably some conflicts, apply-mbox will tell you if so
12:20 danvet: and store the parts of the patch it couldn't apply into .rej files
12:20 danvet: so those you need to open, plus the source file, and manually try to make things fit
12:21 danvet: once it's all done and tested, run git add -u to add your changes and then git apply-mbox resolved
12:21 danvet: git will then construct a commit out of that patch and commit message and any manual changes you applied
12:21 danvet: or something like that
12:21 danvet: it's rather annoying
12:21 danvet: other option is to ask rodrigo for a git tree you could pull, but he's not around right now
12:22 danvet: hwentlan, siquiera not around?
12:22 Sumera: ah, no let me try this first
12:22 danvet: yeah it's at least an experience ...
12:23 Sumera: so, just curious, is this what maintainers do for *every* patch?
12:25 pq: maintainers get the patches in their inbox, and they have tooling in their MUA to apply an email as a patch to some git tree, but yes :-)
12:26 pq: some maintainers have made art of creating their own tooling around the email-based workflow
12:28 Sumera: wow, I am just a touch amazed, given the scale o.o
12:29 pq: it really is mindboggling
12:31 danvet: it is
12:31 danvet: job dissatisfaction as maintainer was a big reason I've pushed for commit rights
12:32 danvet: Sumera, so yeah imo reasonable projects don't work like this, but can't hurt to do this once and go through the pain
12:32 danvet: for the other side, watch one of the talks by gregkh
12:33 danvet: https://www.youtube.com/watch?v=L8OOzaqS37s
12:41 danvet: airlied, just realized the xilinx-ai-engine thing
12:41 danvet: should we bring that entire discussion up again?
12:47 danvet: airlied, cc'ed you
12:47 danvet: might be good if you look, you've dug around in AI stacks a lot more than I have
12:48 danvet: agd5f, ^^ since iirc amd bought xilinx, so if you can make sure we connect properly and there's no misunderstandings, would be awesome I think
12:48 danvet: Subject: Re: [PATCH 2/9] misc: Add Xilinx AI engine device driver
12:48 danvet: agd5f, I hit send before a thought about adding you
12:55 Sumera: Daniel, thanks, will check out the talk
12:55 emersion: otoh, email-based workflow allow you to merge patches without going through gitlab's painfully slow UI
12:58 pq: I'm a few magnitudes slower than gitlab.
12:59 emersion: maybe that
12:59 emersion: 's because you have a beefy computer
13:00 pq: my equipment has never been accused of being "beefy" before :-D
13:01 pq: more like "you have 8 gig ram? Dude? Aren't you starving with that?"
13:17 danvet: hey I'm pondering whether to retire my 4gb laptop or not yet
13:18 danvet: but it's not my main work station, only for travels and stuff
13:19 danvet: but mostly because the screen on the 4k dell xps13 is soooooo pretty :-)
13:19 pcercuei: send it to me, I can retire it for you
13:26 melissawen: danvet, if I got it well, Sumera can also try to download the mbox patches from Patchwork (https://patchwork.freedesktop.org/series/63010/#rev1) and then "git am <the_mbox_file_path>"
13:36 Sumera: Melissa, looks good, will try this as well.
13:38 danvet: yeah the important part is that the archive provides the raw mail
13:38 danvet: patchwork can also give you multiple patches in one mbox file
13:38 danvet: which git apply-mbox can apply in one go
13:38 danvet: but it gets messy when you have conflicts
13:39 pq: on a normal project, I'd just find a base commit from around the time the patches were posted, so that they apply without any conflicts, but that probably won't work for the kernel
13:40 pq: I've found git-rebase conflicts easier to deal with than git-am conflicts.
14:19 hwentlan: danvet, siqueira should be around
14:20 danvet: ah now, or I screwed up my ircing
14:20 danvet: Sumera, you can also ping siqueira here
14:52 siqueira: Sumera yes, feel free to ping me if you need help
15:49 jekstrand: airlied: ¯\_(ツ)_/¯
16:12 emersion: paulk-leonov: i think you can just expose two connectors and a single CRTC compatible with both connectors
16:12 emersion: that's already how some widely available hw exposes it
16:12 emersion: e.g. on my snd i have 3 connectors but only two CRTCs
16:12 emersion: snb*
16:13 emersion: intel sandybridge*
16:14 emersion: then user-space can choose to disable one connector to be able to enable another one
16:16 MrCooper: tanty: thanks for the R-b! Have you confirmed that !7957 fixes the failure you hit?
16:33 paulk-leonov: emersion: oh you're right, that's already possible
16:33 paulk-leonov: emersion: in my case I guess it'd be two encoders
16:33 paulk-leonov: thanks :)
16:33 emersion: np :)
16:49 alyssa:complains about dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_*
16:49 alyssa: anholt: I saw those tests are "fun" on v3d too :<
17:23 anholt: hm?
17:24 alyssa: e8dc3c0c36e830f4b134151ac1e18d979e70f0c6
17:45 dcbaker[m]: tanty: I'll see what I can do. I'm home with my kids today, but if they get some nap time in I'll have a look
17:59 bschiett: hi all
17:59 bschiett: trying to get lvds working on a rk3288 platform but probe seems to fail all the time with [ 5.594021] rockchip-lvds ff96c000.lvds: [drm:rockchip_lvds_bind] *ERROR* failed to find panel and bridge node
18:00 bschiett: any ideas? relevant dts stuff here https://pastebin.com/SqZxMJtY
18:00 bschiett: i recently upgraded from kernel 4.11 to 5.9.12 stable so not sure what's up with the changed lvds node definitions.
19:16 sravn: bschiett: the kernel do not know the panel. auo,b101ew05 is not known
19:17 sravn: bschiett: Did the same dts work with the older kernel?
19:30 bschiett: @sravn you are right, this panel driver is missing so the panel is not added
19:30 bschiett: @sravn since I am using a panel for which there is no driver, maybe I should use panel-lvds and specify timings in dts?
20:38 Kayden: hmm, so I'm trying to port ACO's uniform subgroup optimizations to NIR, since they're general optimizations anybody could benefit from
20:38 Kayden: ran into a bit of a snag
20:38 Kayden: inclusive scan of a uniform value with min/max/and/or is just any invocation
20:39 Kayden: but exclusive scan is supposed to be <identity, value, value, value, value ...>
20:39 Kayden: and I'm not seeing a way to do that kind of "write one lane" trick in NIR
20:39 Kayden: except maybe the write_invocation_amd intrinsic?
20:43 pendingchaos: write_invocation_amd can be done (less efficiently) with "bcsel(load_subgroup_invocation() == src2, src1, src0)"
20:45 Kayden: ah, thanks
20:46 Kayden: I should probably just add support for write_invocation_amd, but I wasn't sure all drivers would want to / be able to do that
20:47 Kayden: I guess I could use it in the opt pass, and have nir_lower_subgroups lower it to the bcsel if drivers don't support it
21:06 agd5f: danvet, I'll see what I can do. My understanding at a high level is a commitment to open source, but I'm not at all familiar with their stack.
21:07 danvet: agd5f, neither me :-)
21:08 danvet: but yeah it sounds like this might be the first serious attempt at actually fully open stack, so I want to give it all the best chances for success we can
21:09 agd5f: yeah
21:10 tanty: dcbaker[m]: Really appreciated. I can relate so, whatever you can do will be welcome.
21:11 tanty: MrCooper: Yes, I confirmed it works and left a comment in the MR. Thanks to you for the fix!
21:47 enunes: hi, I'm implementing half float textures and OES_texture_half_float for lima; that all works if I use GLES, but apparently I can't use it with desktop GL apps
21:48 enunes: 32bit float textures are not supported so I can't implement ARB_texture_float, looks like I won't be able to enable 16bit either in desktop GL since OES_texture_half_float is really only for GLES and ARB_texture_float would be needed for half float desktop GL
21:48 enunes: do I get it right?
21:51 enunes: if I hack _mesa_has_half_float_textures into returning 1 it works, but since something like "ARB_texture_half_float" doesn't really exist, it can't really be rightfully enabled
21:56 ajax: enunes: is ARB_half_float_pixel not what you're looking for?
21:57 enunes: I don't think so, I think this is to render half float, not half float texture
21:58 sravn: bschiett: Yep, I think that would be a fine approach to move forward.
21:58 ajax: enunes: not the way i'm reading it? it talks about accepting HALF_FLOAT_ARB for TexImage2D but not for like RenderbufferStorage
22:00 ajax: why GL_HALF_FLOAT_OES isn't numerically equal to GL_HALF_FLOAT_ARB i have no idea though
22:00 ajax: and the big-gl extn for half-float render targets is EXT_color_buffer_half_float i'm pretty sure
22:01 enunes: ajax: hmm I can't find a reference for textures in https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_half_float_pixel.txt
22:02 enunes: but GL_ARB_half_float_pixel is enabled once I added support for the formats
22:02 enunes: so if it's really the case, _mesa_has_half_float_textures might be missing the check for that extension
22:02 ajax: Accepted by the <type> parameter of DrawPixels, ReadPixels,
22:02 ajax: TexImage1D, TexImage2D, TexImage3D, GetTexImage, TexSubImage1D,
22:02 ajax: ...
22:03 ajax: ARB_half_float_pixel ought to be enabled unconditionally if my read of extensions_table.h is right
22:03 anholt: right, we always expose half_float_pixel, but it's only as of much later stuff that you get any guarantee of storing half floats in your textures/rbs.
22:03 bnieuwenhuizen: dcbaker[m]: any idea why 0fcd379184d658285f3313c5c4026253e0ec6930q has nominated = false? (https://cgit.freedesktop.org/mesa/mesa/tree/.pick_status.json?h=staging/20.3#n7275)
22:03 anholt: thanks, gl!
22:04 enunes: ok I missed those, so do we want to add that extension to _mesa_has_half_float_textures?
22:04 bnieuwenhuizen: dcbaker[m]: okay we found the likely cause is the missing mesa-stable in cc, ignore me
22:05 ajax: enunes: i think you want to change _mesa_has_float_textures to say _mesa_has_ARB || ctx->Extensions.OES_texture_float || _mesa_is_gles3
22:05 ajax: _mesa_has_OES_texture_float requires that the context actually _be_ gles since that's all the OES extn is defined for
22:06 ajax: but we set the extn support bits without regard to the context's API, so if you _would_ support the OES one, then you can take the internal half-float-storage path for big-gl too
22:06 ajax: assuming i'm correct then a big ol' comment explaining that in _mesa_half_float_textures would be wise too
22:07 dcbaker[m]: bnieuwenhuizen: ok :)
22:09 enunes: ajax: cool thanks, that matches what I found out trying to understand that code, ctx->Extensions.OES_texture_half_float is indeed set but the context doesn't match
22:09 enunes: though none of those feature checks check the Extensions bit directly
22:10 ajax: yeah, the _mesa_has_blah autogenerated macros are a bit subtle
22:11 enunes: I'll send that along with my MR for that then
22:11 enunes: thanks
22:15 jenatali: Anybody (airlied?) have opinions on moving flush_frontbuffer from pipe_screen to pipe_context? I'd really like to enqueue a copy so I don't have to put the main framebuffer in system memory
22:31 karolherbst: jenatali: do you actually have an implementation for it?
22:31 jenatali: karolherbst: Right now we're following Zink's trick of abusing the swrast frontend, so yeah
22:32 karolherbst: ahh
22:32 jenatali: It's going to take us quite a while before we can build a proper winsys integration where content doesn't have to be brought back to the CPU
22:33 jenatali: (For WSL, to be clear, Windows has a proper swapchain)
22:33 ajax: sounds plausible to me i think. the frontbuffer is right on the line of what belongs to the screen or the context but since it can sometimes be the context...
22:34 jenatali: ajax: Yeah, the flush is always called while flushing a context, but the context info just isn't sent into that call...
22:36 karolherbst: :/
22:37 bschiett: @sravn managed to get it working by using panel-lvds in my DTS file. thanks!
23:10 Kayden: pendingchaos: hrmm...my new optimization pass wants to use divergence information, but also generates new code that needs to be flagged as convergent. any advice on how best to handle that?
23:11 Kayden: just run divergence analysis again?
23:11 Kayden: ah, nir_update_instr_divergence maybe?
23:12 pendingchaos: you can run it again or use nir_update_instr_divergence (works in most but not all cases)
23:12 pendingchaos: you can also set nir_builder::update_divergence to true to update most ssa defs
23:12 Kayden: ooh, nice! that sounds like what I want :)
23:12 pendingchaos: IIRC nir_update_instr_divergence/nir_builder::update_divergence doesn't work if you're invalidating LCSSA or inserting loop header phis
23:13 Kayden: yep, not touching phis
23:13 pendingchaos: nvm, nir_update_instr_divergence() doesn't work for any phis
23:13 pendingchaos: actually it works for phis other than loop header phis, I was looking at update_instr_divergence() instead of nir_update_instr_divergence()
23:14 Kayden: awesome, thanks, that works
23:20 pendingchaos: nir_update_instr_divergence() also doesn't work if you're replacing a ssa def that's consider divergent with a uniform one or a uniform one with divergent, since it only updates that instruction's destinations, not it's users
23:20 pendingchaos: I don't think that should be a problem for a pass optimizing uniform subgroup intrinsics though
23:21 Kayden: right
23:21 Kayden: yeah, I'm just generating new convergent code to replace other convergent code
23:21 Kayden: and it was defaulting to not having any info associated which was "divergent"