08:24MrCooper: tanty: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7957
08:25MrCooper: airlied: did you get a chance to test the latest revision of that?
10:10tanty: dcbaker: would you have time for a quick review?
12:17Sumera: danvet: I wanted to apply this patch https://firstname.lastname@example.org/#t so I wanted to know if there is any way to do this without manually doing all the code change.
12:19danvet: Sumera, so this is the annoying part, you need to grab the raw message of each patch
12:19danvet: so for first one here https://email@example.com/
12:19Sumera: I could, technically write a script to fetch the changes but it might take me longer.
12:19danvet: there's the raw link https://firstname.lastname@example.org/
12:19danvet: then you need to feed that into git apply-mbox
12:19danvet: can do a unix pipline, like
12:20danvet: curl https://email@example.com/raw | git apply-mbox
12:20danvet: there's probably some conflicts, apply-mbox will tell you if so
12:20danvet: and store the parts of the patch it couldn't apply into .rej files
12:20danvet: so those you need to open, plus the source file, and manually try to make things fit
12:21danvet: once it's all done and tested, run git add -u to add your changes and then git apply-mbox resolved
12:21danvet: git will then construct a commit out of that patch and commit message and any manual changes you applied
12:21danvet: or something like that
12:21danvet: it's rather annoying
12:21danvet: other option is to ask rodrigo for a git tree you could pull, but he's not around right now
12:22danvet: hwentlan, siquiera not around?
12:22Sumera: ah, no let me try this first
12:22danvet: yeah it's at least an experience ...
12:23Sumera: so, just curious, is this what maintainers do for *every* patch?
12:25pq: 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:26pq: some maintainers have made art of creating their own tooling around the email-based workflow
12:28Sumera: wow, I am just a touch amazed, given the scale o.o
12:29pq: it really is mindboggling
12:31danvet: it is
12:31danvet: job dissatisfaction as maintainer was a big reason I've pushed for commit rights
12:32danvet: 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:32danvet: for the other side, watch one of the talks by gregkh
12:41danvet: airlied, just realized the xilinx-ai-engine thing
12:41danvet: should we bring that entire discussion up again?
12:47danvet: airlied, cc'ed you
12:47danvet: might be good if you look, you've dug around in AI stacks a lot more than I have
12:48danvet: 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:48danvet: Subject: Re: [PATCH 2/9] misc: Add Xilinx AI engine device driver
12:48danvet: agd5f, I hit send before a thought about adding you
12:55Sumera: Daniel, thanks, will check out the talk
12:55emersion: otoh, email-based workflow allow you to merge patches without going through gitlab's painfully slow UI
12:58pq: I'm a few magnitudes slower than gitlab.
12:59emersion: maybe that
12:59emersion: 's because you have a beefy computer
13:00pq: my equipment has never been accused of being "beefy" before :-D
13:01pq: more like "you have 8 gig ram? Dude? Aren't you starving with that?"
13:17danvet: hey I'm pondering whether to retire my 4gb laptop or not yet
13:18danvet: but it's not my main work station, only for travels and stuff
13:19danvet: but mostly because the screen on the 4k dell xps13 is soooooo pretty :-)
13:19pcercuei: send it to me, I can retire it for you
13:26melissawen: 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:36Sumera: Melissa, looks good, will try this as well.
13:38danvet: yeah the important part is that the archive provides the raw mail
13:38danvet: patchwork can also give you multiple patches in one mbox file
13:38danvet: which git apply-mbox can apply in one go
13:38danvet: but it gets messy when you have conflicts
13:39pq: 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:40pq: I've found git-rebase conflicts easier to deal with than git-am conflicts.
14:19hwentlan: danvet, siqueira should be around
14:20danvet: ah now, or I screwed up my ircing
14:20danvet: Sumera, you can also ping siqueira here
14:52siqueira: Sumera yes, feel free to ping me if you need help
15:49jekstrand: airlied: ¯\_(ツ)_/¯
16:12emersion: paulk-leonov: i think you can just expose two connectors and a single CRTC compatible with both connectors
16:12emersion: that's already how some widely available hw exposes it
16:12emersion: e.g. on my snd i have 3 connectors but only two CRTCs
16:13emersion: intel sandybridge*
16:14emersion: then user-space can choose to disable one connector to be able to enable another one
16:16MrCooper: tanty: thanks for the R-b! Have you confirmed that !7957 fixes the failure you hit?
16:33paulk-leonov: emersion: oh you're right, that's already possible
16:33paulk-leonov: emersion: in my case I guess it'd be two encoders
16:33paulk-leonov: thanks :)
16:33emersion: np :)
16:49alyssa:complains about dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_*
16:49alyssa: anholt: I saw those tests are "fun" on v3d too :<
17:45dcbaker[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:59bschiett: hi all
17:59bschiett: 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:00bschiett: any ideas? relevant dts stuff here https://pastebin.com/SqZxMJtY
18:00bschiett: 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:16sravn: bschiett: the kernel do not know the panel. auo,b101ew05 is not known
19:17sravn: bschiett: Did the same dts work with the older kernel?
19:30bschiett: @sravn you are right, this panel driver is missing so the panel is not added
19:30bschiett: @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:38Kayden: hmm, so I'm trying to port ACO's uniform subgroup optimizations to NIR, since they're general optimizations anybody could benefit from
20:38Kayden: ran into a bit of a snag
20:38Kayden: inclusive scan of a uniform value with min/max/and/or is just any invocation
20:39Kayden: but exclusive scan is supposed to be <identity, value, value, value, value ...>
20:39Kayden: and I'm not seeing a way to do that kind of "write one lane" trick in NIR
20:39Kayden: except maybe the write_invocation_amd intrinsic?
20:43pendingchaos: write_invocation_amd can be done (less efficiently) with "bcsel(load_subgroup_invocation() == src2, src1, src0)"
20:45Kayden: ah, thanks
20:46Kayden: 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:47Kayden: 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:06agd5f: 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:07danvet: agd5f, neither me :-)
21:08danvet: 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:10tanty: dcbaker[m]: Really appreciated. I can relate so, whatever you can do will be welcome.
21:11tanty: MrCooper: Yes, I confirmed it works and left a comment in the MR. Thanks to you for the fix!
21:47enunes: 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:48enunes: 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:48enunes: do I get it right?
21:51enunes: 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:56ajax: enunes: is ARB_half_float_pixel not what you're looking for?
21:57enunes: I don't think so, I think this is to render half float, not half float texture
21:58sravn: bschiett: Yep, I think that would be a fine approach to move forward.
21:58ajax: enunes: not the way i'm reading it? it talks about accepting HALF_FLOAT_ARB for TexImage2D but not for like RenderbufferStorage
22:00ajax: why GL_HALF_FLOAT_OES isn't numerically equal to GL_HALF_FLOAT_ARB i have no idea though
22:00ajax: and the big-gl extn for half-float render targets is EXT_color_buffer_half_float i'm pretty sure
22:01enunes: 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:02enunes: but GL_ARB_half_float_pixel is enabled once I added support for the formats
22:02enunes: so if it's really the case, _mesa_has_half_float_textures might be missing the check for that extension
22:02ajax: Accepted by the <type> parameter of DrawPixels, ReadPixels,
22:02ajax: TexImage1D, TexImage2D, TexImage3D, GetTexImage, TexSubImage1D,
22:03ajax: ARB_half_float_pixel ought to be enabled unconditionally if my read of extensions_table.h is right
22:03anholt: 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:03bnieuwenhuizen: 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:03anholt: thanks, gl!
22:04enunes: ok I missed those, so do we want to add that extension to _mesa_has_half_float_textures?
22:04bnieuwenhuizen: dcbaker[m]: okay we found the likely cause is the missing mesa-stable in cc, ignore me
22:05ajax: 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:05ajax: _mesa_has_OES_texture_float requires that the context actually _be_ gles since that's all the OES extn is defined for
22:06ajax: 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:06ajax: assuming i'm correct then a big ol' comment explaining that in _mesa_half_float_textures would be wise too
22:07dcbaker[m]: bnieuwenhuizen: ok :)
22:09enunes: 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:09enunes: though none of those feature checks check the Extensions bit directly
22:10ajax: yeah, the _mesa_has_blah autogenerated macros are a bit subtle
22:11enunes: I'll send that along with my MR for that then
22:15jenatali: 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:31karolherbst: jenatali: do you actually have an implementation for it?
22:31jenatali: karolherbst: Right now we're following Zink's trick of abusing the swrast frontend, so yeah
22:32jenatali: 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:33jenatali: (For WSL, to be clear, Windows has a proper swapchain)
22:33ajax: 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:34jenatali: ajax: Yeah, the flush is always called while flushing a context, but the context info just isn't sent into that call...
22:37bschiett: @sravn managed to get it working by using panel-lvds in my DTS file. thanks!
23:10Kayden: 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:11Kayden: just run divergence analysis again?
23:11Kayden: ah, nir_update_instr_divergence maybe?
23:12pendingchaos: you can run it again or use nir_update_instr_divergence (works in most but not all cases)
23:12pendingchaos: you can also set nir_builder::update_divergence to true to update most ssa defs
23:12Kayden: ooh, nice! that sounds like what I want :)
23:12pendingchaos: IIRC nir_update_instr_divergence/nir_builder::update_divergence doesn't work if you're invalidating LCSSA or inserting loop header phis
23:13Kayden: yep, not touching phis
23:13pendingchaos: nvm, nir_update_instr_divergence() doesn't work for any phis
23:13pendingchaos: actually it works for phis other than loop header phis, I was looking at update_instr_divergence() instead of nir_update_instr_divergence()
23:14Kayden: awesome, thanks, that works
23:20pendingchaos: 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:20pendingchaos: I don't think that should be a problem for a pass optimizing uniform subgroup intrinsics though
23:21Kayden: yeah, I'm just generating new convergent code to replace other convergent code
23:21Kayden: and it was defaulting to not having any info associated which was "divergent"