00:40jenatali: alyssa: If you were curious I found the Vulkan CTS cases for the missing component border handling. I tripped over them because of a bug in WARP for integer texture sampling :)
00:41jenatali: Doesn't help for GL though :P
02:59alyssa: jenatali: Delight
09:50Siddh[m]: Hi, can anyone review https://lore.kernel.org/dri-devel/cover.1672957022.git.code@siddh.me/ ? Thanks. (For 1st patch, please consider the reply)
10:09sravn: Hi Siddh[m] - I like that we slowly move away from the deprecated logging functions.
10:10sravn: The first path - please cosider to split inline struct device *___drm_get_dev_ptr(const void *ptr, bool is_drm) in two funtions, so we avoid the is_drm flag.
10:11Siddh[m]: sravn: Oh okayy, noted. I will do that. Thanks!
10:11sravn: The confidence level for the following patches had been higher, if you hade used cocinelle to do the job you did manually here. Have you looked at that possibility?
10:13sravn: I looked brifly - and found no mistakes. But cocinelle just do a better job for this kind of changes
10:13Siddh[m]: sravn: No, and I really did forget cocinelle existed. Thanks for pointing out
10:13Siddh[m]: Though I have never really used coccinelle outside of static analysis
10:14sravn: And then it is easier to repaet the same edits in drivers etc. See other changelogs how they include the cocinelle script in the changelog
10:14Siddh[m]: Sure, I will take a look. Thank you!
11:55Nyaa:waves at psykose
11:55Nyaa: hi
11:56Nyaa: didn't know you were here too
12:11Nyaa: hooray, I think I figured out the vdpau segfaults for r300
12:41DavidHeidelberg[m]: Nyaa: nice, now can you do rewrite to VAAPI? :P
14:47Nyaa: and with https://gitlab.freedesktop.org/mesa/mesa/-/issues/8031 i think that might be enough code archaeology for me today
14:52Nyaa: DavidHeidelberg[m], if I attempt that I might just try to get shader-based h264 decoding working too
17:35Siddh[m]: <sravn> "The first path - please cosider..." <- I split it and also removed simplified the Generic. Please check https://lore.kernel.org/dri-devel/625541825d76ae5ef0d82f4a0ce5c8976ceff9f0.1673110890.git.code@siddh.me/. Thanks.
17:59javierm: sravn: I see that you didn't provide your r-b for https://lore.kernel.org/lkml/20221228014757.3170486-3-javierm@redhat.com/, did you forget?
18:28sravn: javierm: I forgot. It is r-b, I have deleted the mail, but can resurrect it via lore if you likethe r-b om the mailing list
18:29sravn:just sent out a series of patches using b4 - that was easy
18:32javierm: sravn: no need to sent to the ML, thanks!
18:35sravn: Siddh[m]: Do you need the extra functions, or could you embed it in __get_dev_ptr? I know I asked to split it up, but looking now it looks like this is too much.
18:41Siddh[m]: <sravn> "Siddh: Do you need the extra..." <- Null check has to be in a function, we cannot check for null in a macro. Generics only evaluate the thing if type matches, but the syntax regardless have to be correct, so I cannot put a drm->dev directly under first case.
18:41Siddh[m]: <"but looking now it looks like this is too much"> yeah, that's why I originally used the bool thingy to do the work one function. It was a compile time thing anyways, but it did feel like a hack when you pointed it out.
18:42javierm: sravn: I was meaning to look at b4 too. I wonder what could give me that patman doesn't
18:43Siddh[m]: in one function*
21:01sravn: javierm: git send-eamil did not work well with my current mail provider (one.com) and I was not happy using my google account for this. With b4 I can send patches without the smtp server hassle and I heard people say positive things about by. So far I have just used git + some basic scripting and never bothered with patman/quilt etc.
21:02sravn: s/by/b4
21:46javierm: sven: interesting, I should take a look
21:46javierm: sorry, meant sravn ^