00:17 <Lyude> HdkR (and alyssa if you're curious to see): https://gitlab.freedesktop.org/lyudess/mesa/commits/wip/bifrost rebased to mesa master, wasn't too difficult to get compiling

00:18 <alyssa_> Lyude: I'm always curious :)

00:18 <alyssa_> And looks good :)

00:22 <HdkR> :D

00:30 <Lyude> HdkR: how far (if at all) did you get with scheduling on this branch btw? before I spend too much time reading into this

00:34 <HdkR> no

00:34 <HdkR> One op per clause packing :P

00:42 <alyssa_> HdkR: "#define PP() if (++loc && progress) printf("progress at: %d\n", loc); "

00:42 <alyssa_> I don't know what this macro is for but don't do it

00:43 <alyssa_> assert(src->is_ssa && "Only supports SSA form");

00:43 <alyssa_> You're going to quickly regret this; accept registers too at least for some edge cases

00:44 <HdkR> alyssa_: I was being lazy one evening :P

00:44 <alyssa_> I see you've inherited my garbage for uniform/varying counting. Don't. :P

00:44 <alyssa_> (The "nir_to_bi" stuff is objectively wrong and Eric yelled at me about it during code review :P)

00:46 <alyssa_> " .lower_ffma = false, " You don't need to say that explicitly; you're setting fuse_ffma so it's fine

00:47 <HdkR> Code review on IRC doesn't scale very well :)

00:47 <alyssa_> HdkR: That's true. So get it in my inbox! ;)

00:51 <HdkR> There's a reason why I haven't pushed it. It isn't anywhere near ready :P

00:52 <alyssa_> RFC

00:53 <HdkR> RFC before I feel it is ready for one? :P

00:53 <alyssa_> :P

06:16 <tomeu> alyssa_: you have gathered a very nice team of initial contributors, the atmosphere in this channel is great

06:24 <tomeu> alyssa_: btw, got panfrost+kbase working on the veyron, and looks like the stride of the fb is wrong

06:25 <tomeu> any ideas?

09:20 <tomeu> robher: this is what breaks things in the rk3288:

09:20 <tomeu> drm_mm_init(&pfdev->mm, SZ_32M, SZ_4G);

09:20 <tomeu> passing 0 instead of SZ_32M gets things working again

09:26 <tomeu> maybe we have a smaller address space there?

13:58 <mmind00> urjaman: you're way to fast ... I'm still working on the response to your v2 comment ;-)

13:58 <mmind00> (for the dithering patch)

14:02 <urjaman> I mean i already had the patch at hand when i started writing the email(s) :P

14:03 <urjaman> most of the time to do this was spent on building and boot-testing the newer kernel (and making a smaller kernel config so that building random kernels doesnt take forever, and also making a seperate PKGBUILD for such testing stuff...)

14:12 <mmind00> urjaman: as for dither_down_sel.mask, I'm not sure if it shouldn't be enough to rely on the test in vop_reg_set?

14:13 <mmind00> urjaman: from skimming over some manuals, I guess allegro would be the default method

14:15 <urjaman> yeah it would be the default ... so in theory i could just not write that bit at all ... but then i'm like i'd like the driver to set all the bits that matter just in case it gets loaded eg. after some future driver that either purposefully or accidentally globbered them

14:17 <urjaman> one idea i had would be to have a macro that signifies that it's expected that the bit doesnt always exist and in that case skip the warning print

14:18 <urjaman> (i mean it's behind drm.debug so nobody except devs will see that anyways, but then ... booting with drm.debug=0x1 was already too verbose, i'd rather not make it more verbose with unnecessary output)

14:22 <urjaman> but yeah I could actually simplify the code even more if one can ignore registers that dont exist (the pre_dither bit from 10bit), and then maybe cleanup the output afterwards

14:31 <mmind00> urjaman: I was thinking of just going the easy way for now ... drop the "if (&vop->data->common->dither_down_sel.mask)" line and trust that vop_reg_set will correctly drop the access when it tries to set dither_down_sel all the time

14:37 <urjaman> one could also drop both of the VOP_FEATURE_OUTPUT_RGB10 tests then ... (also the unknown bpc path could instead "be" the upper path with bpc set to 10)

14:43 <mmind00> haha ... always the hard question, where does one start and where end ... but yeah, the original code also didn't care about the VOP_FEATURE_OUTPUT_RGB10 when handling pre_dither_down

14:58 <alyssa_> tomeu: Yeah, we have stride issues across the board, but particularly obvious on veyron. The quick hack is to edit pan_mfbd.c to change the width field to ALIGN(width, 16)

14:59 <alyssa_> Same issue occurs on RK3399 if you render a window (in Wayland etc) that's not 16-pixel aligned, for that matter

15:07 <alyssa_> I'm not saying it can't be done... I mean, we don't do warping on this arch so one of the big objections is gone... memory bw / cache locality'll be a big issue...

15:27 <tomeu> alyssa_: you meant something else than http://paste.debian.net/1073625/ ?

15:31 <tomeu> because the stride doesn't seem to be right yet

15:46 <urjaman> mmind00: v4 sent :P (i went all in basically)

15:47 <tomeu> robher: with the offset removed, I now get TRANSLATION_FAULT_LEVEL3 when the GPU tries to read from some buffers

15:47 <tomeu> for example: 0x000000000C3F6000

15:52 <daniels> tomeu: yeah, in that case you're going to be reading too much from the fb

15:52 <daniels> tomeu: it would be better to just fix it so that we correctly align stride, and allow buffers of any width

15:53 <daniels> because not everyone's desktops has the width of every buffer aligned to 16px :P

15:53 <tomeu> oh, the fault is unrelated to the width issue

15:53 <tomeu> I get it from a igt test case, not from mesa

15:54 <tomeu> there's too many things broken atm :)

15:55 <tomeu> I guess that when running mesa with the ALIGN hack, the GPU would be reading for adjacent buffers, and not faulting

15:55 <tomeu> but in the igt case the GPU just errors out when starting to read from a particular buffer

16:34 <alyssa_> daniels: *eyes*

18:20 <HdkR> Lots of OpenXR news today, wasn't expecting the provisional spec to go public :D

18:26 <Lyude> OpenXR?

18:31 <HdkR> The Khronos spec that will save us from ever VR/AR/MR headset from making a proprietary library

18:31 <HdkR> from every*

18:35 <HdkR> Dolphin literally can't use any of the VR APIs since all of their licenses are incompatible with GPLv2+

18:42 <Lyude> yikes, good to hear there's some work on actual spec though

18:44 <daniels> and a day-one open-source implementation, made by what i hear is a _really_ good company

18:45 <HdkR> Haven't been able to confirm myself, but that statement might be true :P

18:51 <HdkR> hah

19:17 <chrisf> HdkR: i doubt anyone would take issue with you calling the VR API impl `part of the system`

19:20 <HdkR> chrisf: Nah, that is only one issue. Their licenses put additional restrictions on GPL

19:21 <HdkR> Getting everyone to sign off on an exception for each libraries licenses is infeasible :P

19:21 <HdkR> library's

19:26 <HdkR> I think the only one that /could/ have worked was OpenVR?

19:26 <HdkR> Been a long while since I last cared :P