00:01 gfxstrand: We've got a general shape of a plan, yes. But it'll take a while to prove it all out.
00:01 DemiMarie: I see.
08:31 mareko: does anybody need libgl-xlib and osmesa? can we remove it?
09:39 anarsoul: could someone take a look at GLSL and NIR parts of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33331 ?
10:32 outofkilomers: now you see why I had mathematics as grade 3 all the time, because there is something wrong with my life if not thinking. There are family of possibilities of the depchain to roll a solution filtering out other elements, but i can come up with only few (probably not the best ones), because i get very confused due to variety of solutions possible, confused such as anxiousness or rather
10:32 outofkilomers: excitedness or something, and every freaking senses blow up along with solutions. But let's go back to the lines. 178-242=-64 where as 388-420=-32 now 210+210+89+89-64=534 aka 6*89 where as 89+89=178-32+210=356=4*89 removing 4*89 from each yields 178. Dudes i am sorry, i am mistaken too much at times, though it seems to work again here. I see you removed my ramblings from one of the
10:32 outofkilomers: logsets.
12:16 stsquad: I'm having trouble following the vulkan device properties logic. Do I create a chain of VkPhysicalDeviceProperties2 and set pNext to point at an empty memory region to be filled by whatever sType says?
13:45 Company: stsquad: yes, you preallocate all the structs, set up their pNext and sType members - including the .pNext = NULL for the last one and potential array members, like for example VkDrmFormatModifierPropertiesListEXT.pDrmFormatModifierProperties and then the call fills in the rest
13:45 Company: stsquad: pretty much all the GetProperties calls inside Vulkan operate like that, device properties, image properties, format properties, whatever
13:48 Company: stsquad: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gsk/gpu/gskvulkanimage.c#L1152 is a simple example in code I wrote
13:59 stsquad: Company: thanks, thats helpful
14:05 stsquad: hmm I guess driverInfo = 535.183.01 as a string means its a freeform text?
15:14 nannybusiness: so let's try one more time as even the last one blew up again. -32+178+-32+178=292 now from single instanced 598+292=890 where as 890+712 where 292+210+210=712 and the sum of 890+712=1602/89=18 .... this is the first stable when i came back from town. i would not surprise if that is some type of wavelet transform. I try to shrink it to something smaller.
15:32 bl4ckb0ne: is there a way to track leaks from pools object in VK? like memory allocated through vkAllocateDescriptorSets
15:32 bl4ckb0ne: they dont ring with asan/valgrind
16:43 lumag: Lyude, imre: what is the preferred way for picking up the LTTPR changes: is it okay to merge nouveau and i915 changes through drm-misc or you'd prefer it to be handled in a different way?
17:18 imre: lumag: ok by me to merge through drm-misc, but jani needs to ack it
17:26 lumag: jani, ^^
17:48 denismitchell: And i took it to the bare minimum of size, it turned out that my math was not perfect again. so 141-17=124 72-17=55 the element we were after was 62low and 79high, so 55-124=-69 and adding 69 to those (remember how 69 came hopefully) so then add 72 to subtract upper operand to another hypothetical duplicate and 17 is got. 256-57-57-57-26=59 128-59=69, 256-115=141 256-115-115=26, however
17:48 denismitchell: last one worked with all sets too, but arguably this is the correct way to do it. now though it can be yet optimized as answer is gotten with 17-3=14/2 72+7=79 72-7-3=62 if you do not want to divide, you take a number and double it yourself. both those last versions got tested on all my sets however. Earlier ones i hallucinated, those were little too heavy too.
18:04 DemiMarie: Is there any working, open userspace for the restricted buffer patches?
18:23 daniels: WIP
18:36 DemiMarie: daniels: Is the open userspace useful or is it just a toy example? I'm genuinely curious here, as my understanding was that the only major use was digital restrictions management and that that required closed source userspace.
18:58 daniels: the TEE implementation, coupled to a better uAPI, will be fine with open userspace, but it’ll require closed (either non-OSS or non-modifiable or both) TEE to give you useful content
19:45 scrambledangel: I start to do the same things what you tried , but instead of connecting idiots from your countries to eliminate you, I connect to foreign authorities to help me to eliminate you, reason also included here, very stupid lazy and yet abusive people who's code is pretty much liquid crap. Code what you have authored and still do author,well you see there isn't much to do with any of this
19:45 scrambledangel: indeed. But that is not something new it was always so, the abuse from such people counts the hardest , all you say I feel being compliments to me, if stupidest trash on earth claims i am the stupidest, than I am satisfied. And by the way your ally wank spammers will be slaughtered one after another here as they were courageous indeed, but are all known long time ago, filthiest trash
19:45 scrambledangel: ever known walking on earth.
19:54 pac85: Are there uses of secure buffers outside of DRM? I mean by design the idea is that only "trusted" sw can put stuff into the secure world so I have an hard time imagining other uses.
20:04 pinchartl: pac85: there are users on the codec side, as someone has to put the data in those buffers
20:04 pinchartl: and use cases on the camera side though, even though I'm not entirely sure why
20:05 pinchartl: I was told that people want to capture face images in buffers not accessible to the CPU, when using cameras and face recognition to unlock phones or laptops for instance
20:05 pinchartl: but nobody was able to tell me why, they just claimed it was a security requirement
20:41 sima: DemiMarie, specifically you can use it to write the entirely open-source compositor support for protected content buffers
20:41 sima: but the video player needs to be blobby most likely
20:50 alyssa: pinchartl: well if you compromise the user's cpu you can access their photo collection, but at least you won't be able to know what their face looks like ;)
20:55 pinchartl: alyssa: given that the camera also have to be able to operate in non-secure mode (good luck doing video conferencing otherwise), I really don't see the point, someone taking control of the machine would be able to capture frames anyway
20:56 alyssa: that too =D
20:57 DemiMarie: pinchartl: It might be more about integrity (preventing spoofing) than about confidentiality.
20:59 DemiMarie: sima: is that enough to meet the DRM userspace requirements?
21:16 pac85: pinchartl: uhm regarding codec, I'd imagine it's like GPUs so they can process stuff inside the secure world but not get things in or out, so not really a different usecase? Regarding the camera perhaps the point is to avoid spoofing? Sounds somewhat interesting
21:18 alyssa: query alyssa
21:19 alyssa: oops
21:25 pac85: wonder in which textbox that was meant to go :p
21:40 sima: DemiMarie, there's vk/gl extensions, as long as mesa implements, it's all fine for drm drivers and display
21:40 sima: if video decode needs more, tough luck
22:42 alyssa: pac85: this one but with a / at the start
22:43 pac85: alyssa: ah, I don't know much irc let's see what it does
22:43 pac85: Ah you can open a chat to yourself
22:44 alyssa: pac85: no you can open a chat with me, that's what /query alyssa does ;)
22:49 pac85: til
22:50 Lynne: so if you want to use e.g. bgra images as storage images, you *have* to use an imageview with a format of rgba and swizzle, rather than being able to use bgra and swizzling inside the shader manually?
22:52 Lynne: I've been using the latter all this time and only *now* the validation layer spits out Undefined-Value-StorageImage-FormatMismatch with a warning that this is undefined behaviour
23:02 Lynne: "If descriptorType is VK_DESCRIPTOR_TYPE_STORAGE_IMAGE or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT, the imageView member of each element of pImageInfo must have been created with the identity swizzle"
23:03 Lynne: so *you cannot use any bgr images as storage images in a portable or predictable way*?
23:15 Lynne: https://paste.debian.net/plain/1353822
23:16 Lynne: if it really is impossible to portably use BGRA images as storage images, I'm done
23:17 gfxstrand: Well, you can if the implementation advertises VK_FORMAT_FEATURE_STORAGE_READ/WRITE_WITHOUT_FORMAT on BGRA
23:17 gfxstrand: On an actual BGRA format, that is.
23:18 gfxstrand: This is a really annoying thorn in the spec, especially on Linux where BGRA is your window system image
23:19 gfxstrand: We added the per-format READ/WRITE_WITHOUT_FORMAT features expressly for BGRA
23:20 Lynne: no one looked at this and said "well, all the letters are there, they're just in the wrong order, on you to fix it"?
23:21 gfxstrand: Oh who?
23:22 Lynne: the user
23:22 Lynne: you have the tools, a swizzle mask
23:22 Lynne: why would they not allow swizzling of storage images?
23:22 gfxstrand: Because hardware can't
23:23 Lynne: fine
23:23 gfxstrand: I think NVIDIA might be able to, depending on the swizzle. AMD maybe? Intel I don't remember.
23:23 gfxstrand: I know Intel can swizzle render targets as long as you don't move alpha
23:23 Lynne: ...is the issue GLSL? specifically, the fact that only e.g. "rgba32f" formats are specified, rather than "bgra32f"?
23:23 gfxstrand: I don't remember if it can swizzle storage images. I think maybe as long as there's nothing funny in the swizzle.
23:24 gfxstrand: That is also an issue
23:24 gfxstrand: There are several issues.
23:24 gfxstrand: If you have an implementation that relies on shader formats then the issue is the lack of bgra in the GLSL/SPIR-V enums. If you have those, you can re-order components in the shader easily enough.
23:25 gfxstrand: If you have an implementation that does it all in the hardware (this is necessary for the "without format" case) then the hardware needs to support swizzling in the image descriptor.
23:25 Lynne: I fail to see any issues that warrant the complete nuclear option of "no, you can't, in fact no one can, we will forbid it"
23:25 Lynne: let users use the images, they're smart enough to remap them in the shader
23:26 gfxstrand: Oh, well you can do that.
23:26 Lynne: you cannot
23:26 gfxstrand: Just make a view with an RGBA format
23:26 gfxstrand: And remap in your shader
23:27 gfxstrand: You just can't use the swizzle to make the hardware do it for you. But you're free to make an RGBA view and do it yourself.
23:27 Lynne: fine, guess I'll do that
23:29 Lynne: what a fucking fiasco
23:30 bl4ckb0ne: wait until you see how ahb does it
23:30 Lynne: ahb?
23:31 bl4ckb0ne: android ahardwarebuffer
23:33 Lynne: ah, I'm perfectly fine with that
23:34 Lynne: you see, you just accept that android uses a separate syntax of Vulkan called Android Vulkan, then you simply reject any and all code that tries to introduce any of those features into your code
23:34 Lynne: problem solved
23:35 alyssa: gfxstrand: Apple can swizzle storage images
23:36 alyssa: but can't compress them, so, don't get too cocky Kim Took
23:40 Lynne: the fact that at least 3 big vendors can swizzle storage images yet there's no extension is proof that none of them care about vulkan at all
23:42 Lynne: CUDA, HIP, oneAPI or whatever new thing Intel come up with this week
23:42 Lynne: I bet Metal can do it
23:44 DemiMarie: Lynne: time to add an extension to Mesa?
23:45 Lynne: tell the TSG to say to vendors blocking any of this bullshit "take your fucking toy 6502 to the dump and come back when you have something better"
23:59 gfxstrand: Their answer is "Use a BGRA format. We support shaderStorageImageRead/WriteWithoutFormat and BGRA storage. Have fun!"
23:59 gfxstrand: I have thought about writing the extension