ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rasterman has quit [Quit: Gettin' stinky!]
LaughingMan[m] has joined #dri-devel
<bnieuwenhuizen> jekstrand: it looked usable for radv if we can subclass the cache object (which seemed doable)
<bnieuwenhuizen> but actually trying something is for tomorrow
Eighth_Doctor has joined #dri-devel
nchery has quit [Quit: Leaving]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
cmarcelo1 has joined #dri-devel
DrNick has joined #dri-devel
DrNick is now known as Guest1834
heat has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
cleverca22[m] has joined #dri-devel
shashank1202 has joined #dri-devel
idr has quit [Quit: Leaving]
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
boistordu_old has quit [Ping timeout: 480 seconds]
aura[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
<jekstrand> bnieuwenhuizen: Fair enough. :)
<jekstrand> bnieuwenhuizen: Please let me know if you run into any trouble or if there's anything I can change to make your life easier.
JohnnyonFlame has quit [Read error: Connection reset by peer]
<jekstrand> It was +162/-625 for ANV. I'd hope for an average of -400ish for most drivers.
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
PiGLDN[m] has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
jessica_24 has quit [Quit: Connection closed for inactivity]
Dylanger has joined #dri-devel
shashanks has joined #dri-devel
gnustomp[m] has joined #dri-devel
Duke`` has joined #dri-devel
jekstrand[m] has joined #dri-devel
slattann has joined #dri-devel
HayashiEsme[m] has joined #dri-devel
Guest1819 is now known as go4godvin
allfox has joined #dri-devel
kisak has quit [Ping timeout: 480 seconds]
kisak has joined #dri-devel
Company has quit [Quit: Leaving]
jewins has quit [Read error: Connection reset by peer]
mclasen has quit [Ping timeout: 480 seconds]
allfox has left #dri-devel [#dri-devel]
gdevi has joined #dri-devel
allfox has joined #dri-devel
allfox has left #dri-devel [#dri-devel]
tzimmermann has joined #dri-devel
allfox has joined #dri-devel
<allfox> com test
itoral has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<allfox> While still not sure if my message get through, greetings everyone. There an upstream change making Mesa 21.2.3 can not be built with LLVM 13 as i386 arch, it should be fixed 2 months ago by the merge request 11940. However, this fix didn't get into the 21.2.3 release package. So yesterday when Debian maintainer upgrading, they failed to build an i386 package, log at https://buildd.debian.org/status/logs.php?arch=i386&pkg=mesa&ver=21.2.3-1
<allfox> And now one of my Steam games stopped working as I have to downgrade to 20.3.5. Would it be possible to cherrypick merge request 11940 into 21.2.x branch please?
<Sachiel> dcbaker: ^
Duke`` has quit [Ping timeout: 480 seconds]
allfox has quit []
zzoon[m] has joined #dri-devel
Hi-Angel has joined #dri-devel
danvet has joined #dri-devel
kmn has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
ngcortes has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
Hi-Angel has quit [Quit: Konversation terminated!]
Hi-Angel has joined #dri-devel
chivay has joined #dri-devel
gawin has joined #dri-devel
_alice has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<HdkR> Not sure if I got a response or missed it. Was there a way for an application to tell mesa its application name for driconf? Vulkan already has something for this I think, is there anything for GL?
<airlied> nope, don't think GL has anything like that
<HdkR> Hmmm
<HdkR> Time dor a new GL_MESA extension? :)
<HdkR> Time for*
<airlied> set argv[0] :-P
<HdkR> har
<HdkR> To set `/proc/self/exe` correctly will result in..a lot of pain
frieder has joined #dri-devel
<airlied> I suppose setting program_invocation_name might be enough, though not sure how to set that
<HdkR> Oh, I wonder what that comes from
<HdkR> Hm, that might be writable and work
<HdkR> Some quirky logic there where it pulls both that variable and `/proc/self/exe` then compares. using invocation_name in the case of mismatch
<airlied> HdkR: yeah it's strips off command line args if they end up in there
<airlied> but if that var differs from exe it ignores it I think
orbea1 has joined #dri-devel
orbea1 has quit []
<HdkR> Worth poking at to see what mesa things some programs are :)
orbea1 has joined #dri-devel
orbea1 has quit []
orbea has quit [Ping timeout: 480 seconds]
<HdkR> Although I probably also need to eat the pain of remapping the launch executable just to rebrand proc/self/exe...
orbea has joined #dri-devel
rasterman has joined #dri-devel
pnowack has joined #dri-devel
itoral has quit [Remote host closed the connection]
tursulin has joined #dri-devel
Ahuj has joined #dri-devel
unsolo has joined #dri-devel
MrCooper__ is now known as MrCooper
<MrCooper> HdkR: why do you want to override that, out of curiosity?
<HdkR> MrCooper: My emulator needs to replace its program name with the one that it is emulating
<HdkR> `FEXInterpreter` for every single GL application doesn't tell much :)
<HdkR> Which is what `PR_SET_MM_EXE_FILE` is for
<HdkR> Just a pain to deal with
rgallaispou has joined #dri-devel
slattann has quit []
tobiasjakobi has joined #dri-devel
<MrCooper> is Mesa the right place for workarounds to specific emulated apps though?
tobiasjakobi has quit [Remote host closed the connection]
<MrCooper> couldn't the workarounds be in the emulator instead?
<airlied> MrCooper: mesa already has the workarounds for those apps
<MrCooper> any specific examples?
<HdkR> I just need to dedicate time to setup PR_SET_MM_EXE_FILE correctly. That's the emulator side workaround
pcercuei has joined #dri-devel
<airlied> MrCooper: any x86 GL app that has a driconf entry that needs to run on aarch64
itoral has joined #dri-devel
<MrCooper> ah, now I get it, thanks
<MrCooper> I thought this was about some kind of console emulator
<HdkR> If you stick a PC under a TV does it turn in to a Console? :P
<MrCooper> I mean the kind of emulator which controls the GL/Vulkan API usage as well
<HdkR> Sadly the most I do there is intercept. Don't want to change behaviour
<MrCooper> yeah it's clear now, just wasn't from "My emulator needs to replace its program name" alone :)
gawin has quit [Remote host closed the connection]
<HdkR> :)
<HdkR> Tricksy Linux emulators are tricky
reductum is now known as Guest1875
reductum has joined #dri-devel
Guest1875 has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
slattann has joined #dri-devel
elongbug has joined #dri-devel
unsolo_ has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
slattann has quit []
slattann has joined #dri-devel
guru_ has joined #dri-devel
reductum has quit [Remote host closed the connection]
oneforall2 has quit [Ping timeout: 480 seconds]
slattann has quit []
reductum has joined #dri-devel
slattann has joined #dri-devel
hansg has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
JohnnyonFlame has joined #dri-devel
vivijim has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
slattann has quit []
slattann has joined #dri-devel
co1umbarius has joined #dri-devel
itoral has quit []
columbarius has quit [Ping timeout: 480 seconds]
slattann has quit []
<karolherbst> tagr: btw, do you have some patches or MRs for the Jetson bug? People on my side are getting a bit impatient :/ If you have the patches though I can deal with adding them to the fedora packaging or something
<karolherbst> at least I can also easily try out if gnome starts and everything as I already set up everything on my nano for that
Company has joined #dri-devel
muhomor has quit [Remote host closed the connection]
muhomor has joined #dri-devel
allfox has joined #dri-devel
allfox has left #dri-devel [#dri-devel]
flibitijibibo has quit [Remote host closed the connection]
ppascher has quit [Ping timeout: 480 seconds]
unsolo has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
kmn has quit [Quit: Leaving.]
kmn has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
nchery has joined #dri-devel
Bennett has joined #dri-devel
DPA has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
DPA- has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
jessica_24 has joined #dri-devel
DPA- has quit []
DPA has joined #dri-devel
ybogdano has joined #dri-devel
DPA- has joined #dri-devel
DPA- has quit []
DPA- has joined #dri-devel
gawin has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
DPA has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
jewins has joined #dri-devel
slattann has quit []
<dcbaker> Sachiel: thanks
ds` has quit [Quit: ...]
ds` has joined #dri-devel
<zmike> jekstrand: any chance you could help me figure out what's going on with this failure from vk shared code https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13141
<zmike> I don't understand how/why that test is running at all
ds` has quit [Quit: ...]
<jekstrand> zmike: Ugh... I have no idea why that test would be running either.
ds` has joined #dri-devel
<zmike> :/
<jekstrand> zmike: Well, lavapipe does advertise all the display extensions without a lvp_wsi_display.c file, so I'm guessing they don't work. :)
<zmike> 🤔
<jekstrand> On my ToDo list: Roll WSI into common code and use vk_common_Foo for almost all WSI functions.
moki12011 has joined #dri-devel
<jekstrand> Actually.... I could do that now....
<zmike> jekstrand: then why aren't those tests crashing currently?
<jekstrand> zmike: Because lavapipe/meson.build doesn't have a with_platform_display case
<jekstrand> So those ENV vars are never set
<zmike> huh
<zmike> which env vars?
<jekstrand> #defines, rather
<jekstrand> VK_USE_PLATFORM_DISPLAY_KHR
<zmike> huh
<zmike> weird
<zmike> thanks!
slattann has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
shashank1202 has joined #dri-devel
gouchi has joined #dri-devel
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #dri-devel
ybogdano has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<danvet> mlankhorst, mripard tzimmermann did you guys see my mails about drm-misc-fixes pull?
<danvet> the thing needs some serious sorting to get unstuck
<danvet> airlied, ^^
<danvet> I think pull request tomorrow would be good so there's time to try again
ngcortes has joined #dri-devel
flto has quit [Read error: Connection reset by peer]
<dcbaker> \o/
ppascher has joined #dri-devel
xexaxo has quit [Read error: Connection reset by peer]
<zmike> gotta wait for an airlied signoff on the lavapipe bit and then I'll marge overnight
<zmike> should be a nice little cleanup
<dcbaker> Agreed, I left an r-b on it
<zmike> 👍
flto has joined #dri-devel
xexaxo has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<jekstrand> zmike: I RBd the lavapipe patch
moki12011 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
frieder has quit [Remote host closed the connection]
gawin has quit [Quit: Konversation terminated!]
<karolherbst> mlankhorst, mripard, mlankhorst: do you have anything against me putting Link: gitlab MR tags in addition to the patchwork ones for patches we pushed through our gitlab CI pipeline? Or should we wait with that once we update all the tooling for this?
hansg has quit [Quit: Leaving]
<karolherbst> It also kind of is relevant to the question of "where do the r-by or whatever" tags are coming from if they are e.g. MR only and not on a mailing list
<demarchi> is it just me or we have a bunch of warnings from amdgpu display with macro redefinitions?
<demarchi> like this:
<demarchi> 542 | #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0a3 /* 2.0 */
<demarchi> |
<demarchi> from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
<demarchi> In file included from ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:35,
<demarchi> from ./drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
<demarchi> from drivers/gpu/drm/amd/amdgpu/amdgpu.h:66,
<demarchi> from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h:29,
<demarchi> from drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c:24:
<demarchi> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:866: note: this is the location of the previous definition
<karolherbst> demarchi: mhh which commit are you on?
<jenatali> jekstrand: If you want to put out a MR with a patch like the you proposed, I'd be happy to take that instead of the extension list
<demarchi> karolherbst: this is on drm-tip
dviola has joined #dri-devel
<karolherbst> demarchi: yeah.. seems right about drm-tip
<karolherbst> demarchi: I think the reason is, that drm-next and drm-misc-next have a different version
<karolherbst> so drm is fine
<karolherbst> drm-misc is also fine
<karolherbst> drm-tip merging both kind of, is not
<vsyrjala> i think they were going to put in some ifdefs or something
<karolherbst> vsyrjala: well.. that doesn't explain why drm and drm-misc diverged on that part, no?
<karolherbst> but mhh, this looks weird kind of
<vsyrjala> amdgpu have their own custom defines for some dp spec stuff for whatever reason. and they used DP_ namespace for it
<karolherbst> right
<vsyrjala> at the same time same defines landed into dp_helper from elsewhere
<vsyrjala> i think
<karolherbst> not saying that it isn't true, I am just wondering why drm-misc and drm diverged here
<vsyrjala> what do you mean by 'drm'?
<karolherbst> drm-next
<karolherbst> let's see...
ybogdano has quit [Ping timeout: 480 seconds]
<vsyrjala> i guess airlied merged in some amdgpu stuff? dunno. i just always disable amdgpu when it has a build failure, which is semi regularly
<karolherbst> yeah... I think that's true
<karolherbst> drm-misc landed the generic defines
<vsyrjala> then six months later i wonder why i'm not test building amdgpu
<karolherbst> and drm merged the AMD stuff
anholt has quit [Quit: Leaving]
gawin has joined #dri-devel
<karolherbst> drm-misc: 241ffeb028e4b include/drm/drm_dp_helper.h (Fangzhi Zuo 2021-09-27 15:23:24 -0400 542) #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0a3 /* 2.0 */
<karolherbst> drm-next: f01ee01958622 (Fangzhi Zuo 2021-08-03 18:46:00 -0400 866) #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0A3
<karolherbst> I guess once drm-misc-next gets merged into drm-next we need to resolve this...
<karolherbst> or maybe resolve this inside drm-misc-next by pulling in drm-next in?
<vsyrjala> there was some discussion on the ml already iirc
<karolherbst> okay
anholt has joined #dri-devel
ybogdano has joined #dri-devel
xexaxo has quit [Read error: No route to host]
slattann has quit []
lyudess has quit []
Lyude has joined #dri-devel
<demarchi> karolherbst: vsyrjala thanks... for now I'm going with vsyrjala's strategy, hopefully I don't break anything
karolherbst has quit [Remote host closed the connection]
pushqrdx has joined #dri-devel
karolherbst has joined #dri-devel
karolherbst has quit []
karolherbst has joined #dri-devel
<pushqrdx> there's a very werid mesa related bug in BespokeSynth that makes it drop input events if it's using hardware, running with LIBGL_ALWAYS_SOFTWARE or LIBGL_DRI(2&3)_DISABLE makes the problem go away but idk why
<pushqrdx> how can we try to figure this out?
<pushqrdx> i think it's mesa related since it goes away with software rendering? maybe not
<HdkR> Are you using a Zen CPU platform?
<pushqrdx> no i am on intel
<HdkR> Alright, so not affected by the Zen USB problem at least :)
<pushqrdx> at least that a step forward :D
idr has joined #dri-devel
<pushqrdx> are aware of any other bugs that might cause this behavior? for some stranger reason the workaround that Bespoke implemented was halving the framerate on linux
<pushqrdx> but if the application runs at full framerate it starts dropping input which is perceived as stutter/lag
<pushqrdx> also full framerate works without issues if i just run with software rendering or disable dri
<jekstrand> jenatali: I was hoping someone else would pick it up and make sure it actually contains the extensions *someone* needs. I haven't even build-tested it. 😂
<jekstrand> jenatali: I was hoping someone else would pick it up and make sure it actually contains the extensions *someone* needs. I haven't even build-tested it. 😂
<jekstrand> jenatali: I was hoping someone else would pick it up and make sure it actually contains the extensions *someone* needs. I haven't even build-tested it. 😂
<jekstrand> jenatali: I was hoping someone else would pick it up and make sure it actually contains the extensions *someone* needs. I haven't even build-tested it.😂
<jekstrand> Bah. Stupid IRC client...
<jenatali> Lol fair enough
<HdkR> pushqrdx: No idea past this point :)
<jekstrand> jenatali: This was one of those cases where the best way to give precise review feedback is a patch or MR. :)
<jekstrand> And I'm too lazy to make a proper MR
zackr has joined #dri-devel
* zmike eyes https://gitlab.freedesktop.org/dashboard/merge_requests?scope=all&utf8=✓&state=opened&author_username=jekstrand
<jenatali> jekstrand: Yeah, fair enough. I don't have much stake in it right now, except that I need to be able to turn off extensions that break stuff, and I want to try to keep the interface as isolated as possible so it can be consumed externally
<jekstrand> jenatali: Ugh... SPIR-V caps might make that tricky. :-/
<jenatali> Yeah
<jenatali> I can add an opaque getter though as long as it's in the args as a pointer (like it was in your proposed patch)
<jenatali> But then that's still kinda ugly to force the calling pattern to be get-and-set, so I'd probably just add a wrapper in microsoft/clc
<jenatali> ... which I'll probably end up doing for the majority of stuff that got moved anyway :)
<jekstrand> How do you fill out the SPIR-V caps struct today?
<jekstrand> Just smash everything you care about on?
<jenatali> It's done in microsoft/clc when prepping vtn either for app kernels or libclc
<jenatali> And yeah, it's whatever the DXIL backend can understand, and if there's caps that need to be based on the underlying D3D driver's support, those come in from the CLOn12 runtime
<jenatali> I think so far it's all just static caps though
<jekstrand> Ah
<jekstrand> Ultimately, I'd think you'd want to base it on D3D12 feature levels/bits but maybe you just haven't needed that complexity yet.
<jekstrand> Especially if clang likes to use random caps "just because"
<pushqrdx> running with INTEL_DEBUG=sync to sync after batches seems to 80% reduce the input dropouts, i am not a graphics person so idk where to look now but it seems like something with batching to gpu causes the app to hang/drop input events
<jekstrand> zmike: Ok, maybe "lazy" is the wrong word....
<zmike> no, no, it's fine, you can be lazy and the rest of us will just keep struggling along with our measly 20-30 open MRs, barely clinging to life
<jekstrand> git branch | wc -l
<jekstrand> 1025
<zmike> 19 🤔
* jekstrand needs to do some house cleaning
<dj-death> pushqrdx: what version of bespoke are you using?
<dj-death> 282
<dj-death> jekstrand: yeah you must have some stuff to drop in there
<jekstrand> Nah. I'll just make them all MRs. :P
<jenatali> jekstrand: We do have some D3D caps that feed into the compilation process, but I think they're all turning on/off things at the Clang and NIR pass level, I don't think anything affects vtn caps right now
<jekstrand> jenatali: Hrm..
<pushqrdx> dj-death 1.0.1 just built from git and removed the 30 fps cap hack to try and debug what the real cause of the issue is
<Company> question:
<jenatali> E.g. "emulate 16-bit math" vs "use native 16-bit math" and same for 64-bit
<Company> how do I figure out if my monitor supports 10 bits per pixel?
<pushqrdx> dj-death they added that cap on linux because if Bespoke runs at framerate it starts dropping input for some bizarre reason
<pushqrdx> dj-death it appears to be a hang, batch related
<pushqrdx> dj-death the higher the framerate the more apparent it becomes, hence halving the framerate kinda worked around the issue
lemonzest has quit [Quit: WeeChat 3.2]
<dj-death> right
<dj-death> never experienced it
<pushqrdx> you on linux?
<dj-death> yep
<pushqrdx> interesting, are you running 60fps?
<pushqrdx> +
<pushqrdx> if it's running at 32fps then that's why
<dj-death> no, I left the default of 30
<dj-death> I wasn't sure why it was limited to that
<pushqrdx> it shouldn't that's a hack they added to work around the unknown bug that doesn't happen on other platforms (windows and mac)
<dj-death> last time I looked at JUCE there was some Nvidia expectations in there so I kind of gave up ;)
<pushqrdx> happens for me on intel too
<dj-death> let me recompile main
<HdkR> Company: use edid-decode to decode your panels edid. ala `edid-decode /sys/class/drm/card0-DP-3/edid` and look for "Bits per primary color channel"
<Company> HdkR: that says 6, which sounds wrong
<pushqrdx>
<pushqrdx> if (sRenderFrame % 2 == 0)
<pushqrdx> if DEBUG || BESPOKE_LINUX
<pushqrdx> need to remove this to uncap it
<HdkR> Company: 6 bit panels are very common in low end panels. Uses a feature called FRC to make it look like 8-bit
<dj-death> pushqrdx: rebuilding
<Company> HdkR: does it also use FRC for 10bit?
<dj-death> sad fact: I need to make -j1 when c++ is involved, or I hang my machine
<HdkR> Company: Yes, it's common for an 8-bit panel to use FRC to get to 10-bit fidelity.
fxkamd has quit []
<Company> HdkR: and 6bit? does that also get FRC'ed to 10bit?
<HdkR> I don't believe so
<HdkR> Too much of a gap
<Company> HdkR: asking because egl/gbm advertises 10bit framebuffers
<Company> this is my 2017 thinkpad
<Company> 2016 probably
alyssa has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<HdkR> You can get 10bit Framebuffers, but you likely can't get a 10bit visual
<alyssa> jekstrand: Hey want to trade NIR review? :-p
rbrune has joined #dri-devel
<jekstrand> alyssa: Depends on what I'm trading for. :P
<HdkR> Company: Same thing here where glxinfo will give 10bit GLXFBConfigs but they don't exist for the GLXVisuals
<alyssa> jekstrand: polluting nir_opcodes.py further for moar fps
ybogdano has quit [Ping timeout: 480 seconds]
* alyssa was going to review the NIR opencl stuff anyway but, details
<Company> HdkR: how do I check that?
<HdkR> Company: glxinfo prints this information
<HdkR> eglinfo also prints similar information but I've not checked out how to interpret that :)
<Company> yeah, I was wondering about eglinfo
<HdkR> eglinfo I only get 8-bit out of X11, gbm seems to report 10bit support for me there
<dj-death> pushqrdx: how do you reproduce?
<Company> yeah, same here
<Company> but if I only have a 6bit monitor, it seems kinda not-so-useful if I get 10bit and you're right that it doesn't make use of it
<HdkR> Wide gamut is hard :)
mclasen has joined #dri-devel
<jekstrand> alyssa: Ugh... The hardest part of that MR is coming up with a good opcode name. :-/
<HdkR> Maybe this is a GBM bug/quirk
<pushqrdx> dj-death just try to select multiple node and move them around
<pushqrdx> you will notice that it's "lagging" or having micro hangs
<jekstrand> alyssa: Maybe we should just make the magic opcode have fabs(fddx(x)) behavior and you can emit the fabs in your back-end?
<pushqrdx> dj-death also clicking around will sometimes miss
<Company> HdkR: I'm just trying to understand what I'm doing, so that I know who's at fault when something doesn't work :)
<dj-death> pushqrdx: yeah, I see
<dj-death> pushqrdx: seems to miss some inputs
<Company> HdkR: and if everybody claims to do 10bit and then my monitor can't do it, I don't need to blame me or mesa
<pushqrdx> dj-death yeah, something with render batching is causing those hangs, for me if i run with INTEL_DEBUG=sync to force wait for idle reduces the issue by ~80%
<alyssa> jekstrand: Agreed (on the name)
<pushqrdx> dj-death graphics aren't my cup of tea tho so i am kinda struggling to know what could be causing this
<alyssa> jekstrand: Doing |ddx(x)| behaviour, instead of ±ddx(x) would work in practice, but makes the patch wrong on a technicality
<jekstrand> alyssa: ?
<alyssa> That is-- the code emitted in the backend there really does botch the sign half of the time
<jekstrand> alyssa: Yes
<alyssa> and fabs is a source modifier, not a destination modifier
<jekstrand> oh...
<jekstrand> right
<jekstrand> *sigh*
<jekstrand> fdxdy_random_sign()?
<alyssa> I guess I could see through that in the optimizer, might even work as-is. Guess I should give that a try.
<alyssa> haha
tzimmermann has quit [Quit: Leaving]
<alyssa> (But in principle, emitting a FABS instruction for the sake of deleting it later seems suspect)
<alyssa> (The sign isn't random. It's correct for one side of the quad and wrong for the other side of the quad. From the perspective of a single thread that's random though ;p)
vocalfan has joined #dri-devel
<gawin> talking about NIR someone wants to check short MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12995
ybogdano has joined #dri-devel
<jekstrand> alyssa: Hrm... Could you implement fddx(x) as fddy_pan(x) * i2f(1 - (lane & 2))?
<jekstrand> alyssa: I assume broadcast isn't free
<jekstrand> fddy(x), of course
<alyssa> errrrr
<alyssa> I... guess? Why would I do that?
<alyssa> on bifrost, broadcast is basically free
<jekstrand> Maybe fewer instructions?
<jekstrand> idk
<jekstrand> Trying to come up with more uses for fddy_pan() to justify it. 😂
txenoo has quit [Remote host closed the connection]
<vocalfan> Yo, I've been getting a crash after updaing to the Oct 4th build and onwards. "Value cannot be null. (Parameter 'ptr')"?
<alyssa> fddx right now is fadd(broadcast(lane_1, x), -broadcast(lane_2, x)) where lane_1 = lane_id & 2 and lane_2 = lane_2 + 1
<alyssa> which is 5 alu ops
<alyssa> on the older (simpler) bifrost, abs(fddx) with that MR instead becomes
<jekstrand> right...
<alyssa> fadd(broadcast(lane_id ^ 1, x) - x)
<alyssa> [well, abs of that]
<alyssa> 3 alu ops
<dj-death> pushqrdx: my guess is a bug in JUCE, but never know
<dj-death> pushqrdx: putting some traces
<alyssa> and then newer bifrost (+valhall) have a broadcast_xor which lets us do that code as
<alyssa> fadd(broadcast_xor(lane_id, 1, x), -x)
<alyssa> 2 instructions, which is optimal
<gawin> vocalfan: can you bisect? (check on which commit it starts)
<vocalfan> I know Oct 3rd worked, Oct 4th broke x3
<jekstrand> alyssa: Yeah
<vocalfan> *Cat face, not a times three-*
<jekstrand> alyssa: You may also be able to optimize any txd which consumes a derivative to use the fddx_i_dont_care_about_sign(). I think all the LOD calculations do a fabs() internally.
<alyssa> ooh, fun
<alyssa> I don't think I have txd implemented tbh. I guess that's not till ES3.2
<gawin> vocalfan: you use some kind package like mesa-git from aur? also what hardware?
* jekstrand reads the intel/fs ddx impl
<vocalfan> Ryzen 9 3900X, 5700XT 8GB, 32GB DDR4.
<alyssa> jekstrand: unless Intel can benefit from this, I can drop the _fine/_coarse, suffix _mali, and if other hardware wants this it's their problem?
<vocalfan> Mesa 21.3.0-devel (git-c6b8702 2021-10-03 focal-oibaf-ppa) - WORKED
<vocalfan> Mesa 21.3.0-devel (git-4459963 2021-10-04 focal-oibaf-ppa) - BROKEN
<jekstrand> alyssa: Yeah, I don't think it helps us.
<alyssa> Alright. I didn't think so but I don't understand your crazy register regioning
<jekstrand> alyssa: So maybe make it fddx_nosign_mali or something
<jekstrand> or badsign?
<jekstrand> or must_abs?
* alyssa gets a can of paint
<airlied> mlankhorst, mripard, danvet : what danvet said, need to get a clean misc somehow, I'd rather not cherry-pick my way through it
<dj-death> pushqrdx: I wonder if it could be JUCE eating the X11 events that Mesa is also using
<dj-death> pushqrdx: like the complete event, configure notify
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<danvet> airlied, I was almost doing that, but then figured "hey w/e" :-)
fxkamd has joined #dri-devel
<pushqrdx> dj-death i don't think so, because running with LIBGL_ALWAYS_SOFTWARE to force software rendering fixes the issue
<gawin> vocalfan: it'd be superb if you could try to revert 0dd0f6cf752b0423dfa2b323196771266d4aed3b commit, rebuild mesa and try again
<vocalfan> gawin... How do I do that? XD
<pushqrdx> it's a hardware render batching related hang, perhaps it's causing mini spikes that end up blocking events for some weird reason
<vocalfan> Do I just clone and type git revert (id)?
<dj-death> pushqrdx: yeah, but when I run in software, xcb_poll_for_special_event() is not called
<dj-death> pushqrdx: so I think mesa is using a different path for software that doesn't talk dri3
<vocalfan> Alright, it's loading
<pushqrdx> dj-death oooh, well that makes sense cause if you run with LIBGL_DRI3_DISABLE to disable both dri2/3 the issue also is gone
<pushqrdx> LIBGL_DRI2_DISABLE and LIBGL_DRI3_DISABLE
<gawin> vocalfan: ofc you also need to rebuild package
<dj-death> pushqrdx: tbf I don't really know how to have an application & mesa share the same connection
<vocalfan> meson is upset about my llvm-config version. -w-
<pushqrdx> dj-death wdym?
<vocalfan> "Found '10.0.0' but need '>= 11.0.0'"
<dj-death> pushqrdx: both components are fetching events from X11
<dj-death> pushqrdx: and they appear to use the same connection
<dj-death> pushqrdx: so one might eat the events of the other
<pushqrdx> dj-death they aren't competing, it should going down the chain starting from the application afaik
<pushqrdx> but in case of mesa i think it takes over...
lynxeye has quit []
YuGiOhJCJ has joined #dri-devel
<pushqrdx> if you notice this issue doesn't happen while dragging only 1 node, tho
rbrune has quit [Quit: Leaving]
<danvet> demarchi, there's already a thread about this with jani and agd5f on dri-devel
<dj-death> pushqrdx: no idea
boistordu has joined #dri-devel
<demarchi> danvet: thanks
<pushqrdx> it's almost definitely a mesa bug tho so i'd love if someone can assist in figuring it out
<demarchi> danvet: regarding this item you added in the i915/TODO.txt: "i915_utils.h needs to be moved to the right places"... do you know if someone ever attempted to move those yesno/enabledisable etc to linux/string_helpers.h ?
reductum has quit [Remote host closed the connection]
reductum has joined #dri-devel
<dj-death> pushqrdx: I notice the issue when panning around, with no node selected
<pushqrdx> dj-death doesn't happen with pan for me
<jani> demarchi: it's a fscking bikeshed fest https://lore.kernel.org/r/87y2fpbdmp.fsf@intel.com
<alyssa> jani: this is why the kernel can't have nice things
<dj-death> pushqrdx: I guess it depends how busy you make the CPU
<demarchi> jani: thanks... surprised string_helpers.h was not the place where this was attempted
<jani> alyssa: yeah, that's why we all cuddle in the drm subsystem
<alyssa> jani: "Upstream thinks distros move too slow, we think upstream moves too fast, we get home and cuddle."
shashank1202 has quit [Quit: Connection closed for inactivity]
<vsyrjala> and when we can't have nice things in the drm subsystem we cuddle in our individual drivers
<jani> demarchi: I forget the reasons. maybe I was hoping *that* would be the point of contention, and easily fixed ;)
<pushqrdx> dj-death yeah something definitely clogs event handling, that's why the 30fps hack works. also running with INTEL_DEBUG=sync
<danvet> demarchi, for these questions, git blame plus https://lore.kernel.org/all/
<danvet> which searches all mailing lists ever
<jani> vsyrjala: and when we can't have nice things in our individual drivers, then what? :o
<danvet> back to cuddling in the corner
<alyssa> "now who shall hug me?" "SWEETIE BELLE!"
<danvet> jani, demarchi looks like andy has taken over string helpers, so looks like time is right to resurrect that series and drop it in
<danvet> maybe just with drm/i915
<danvet> and let the remaining bikeshed for andy to sort out :-)
<danvet> opportunistic approach here is probably to ask andy for an ack for merging this through drm trees
<danvet> gives everyone enough distance and plausible deniability to ignore any bikeshed and proceed
<jani> that just ruined my plausible deniability
<demarchi> yep, I think so... and just read the thread, the opposition from akpm was not quite right
elongbug has quit [Ping timeout: 480 seconds]
<jani> maybe add some helpers as static inline, some with EXPORT_SYMBOL(), some as macros, and spread them across kernel.h, string.[ch] and string_helpers.[ch]. something for everybody.
<jani> :p
<demarchi> then add an entry in kconfig and you can choose whatever version you want
<jani> oh that too
<jani> forgot about adding a printf format modifier %psdh6sX for one of them
<jani> I remember the common std C modifiers, but the kernel has just gone completely crazy with that stuff
<alyssa> uh why is my DNS no longer working
<ccr> facebook broke it too?
<ccr> :P
The_Company has joined #dri-devel
<alyssa> ccr: i don't even use facebook
Company is now known as Guest1932
The_Company is now known as Company
<dj-death> pushqrdx: INTEL_DEBUG=sync will just slow down the pace of driver, hiding the problem :(
<Sachiel> in ultracapitalist north america, facebook uses you
<demarchi> jani: I only read your last version and the version from andy... after that it doesn't seem to have true opposition to it... maybe just figuring out where to merge?
<alyssa> Sachiel: canada's whole thing is that we're not the us, except for being ruled by american-owned multinationals that have maple leaf logos on their .ca domains
<pushqrdx> dj-death yeah it doesn't even get rid of it 100% just reduces it ~70%, tbh i think the problem is too deep for me to figure out without kind help from folks working on mesa
<pushqrdx> dj-death the same problem (i think) is affecting Helio Workstation for me too
Guest1932 has quit [Ping timeout: 480 seconds]
<pushqrdx> with hardware acceleration helio drops frames/input alot and is also alleviated with software rendering but not with INTEL_DEBUG=sync though
<danvet> demarchi, worst case we volunteer airlied's head
Duke`` has quit [Ping timeout: 480 seconds]
<danvet> or mine
<danvet> and stuff it into drm.git
<danvet> since this bikeshed is clearly getting silly
* airlied also loves saying no on bikesheds
<danvet> I can also throw a dice if we can't decide on the color
<danvet> on vidoe or something in a call with witnesses and everything
mclasen has quit []
<danvet> but for the drm.git option need to limit the refactor to drm drivers
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
<demarchi> danvet: but if it is still going to be implemented in string.h or string_helpers.h, then we don't have much choice other than also converting the others, do we?
gouchi has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
<jani> demarchi: it's always opt-in, we can start small
<jani> the more you convert in the same series, the more it's going to attract bikeshedding all over the place
<demarchi> jani: problem is that if you add it to string.h or string_helpers.h and for some reason the other driver also included it, then it will be broken
<jani> it's just something absolutely *everyone* understands and wants to have an opinion on
<jani> ah, right, for the same names yes
<demarchi> I'm optimistic today, dunno why... to me it seems its close to a final version
<demarchi> so I'd still aim for having everything converted
i-garrison has quit []
pushqrdx has quit [Remote host closed the connection]
<gawin> mareko: I've found third bitshift which kinda should be fixed, do you have idea for this one?
<gawin> lod_bias = CLAMP((int)(state->lod_bias * 32 + 1), -(1 << 9), (1 << 9) - 1);
<gawin> sampler->filter1 |= (lod_bias << R300_LOD_BIAS_SHIFT) & R300_LOD_BIAS_MASK;
vocalfan has quit [Remote host closed the connection]
<idr> The problem is shifting a signed value?
<gawin> yeah, lod_bias can be negative, which is UB
agd5f has quit [Remote host closed the connection]
<idr> You should be able to rearrange it to be something like 'sampler->filter1 |= (unsigned)(lod_bias & SOME_MASK) << R300_LOD_BIAS_SHIFT;'
agd5f has joined #dri-devel
<idr> SOME_MASK would be (R300_LOD_BIAS_MASK >> R300_LOD_BIAS_SHIFT), I guess.
<idr> ...and definitely add a comment like "The ordering of the shifting as mask is done to make UBSan happy."
<idr> *and masking is done...
<karolherbst> shifting a negative value is UB?
<idr> Left shifting is, I think.
<ajax> shifting into the sign bit generally, yeah
<idr> Because 1's complement might exist.
<karolherbst> ajax: ah
<karolherbst> gawin: why not just store it unsigned?
<karolherbst> do the clamp signed, and make either lod_bios unsigned, or cast it before shifting
<idr> That should work too.
<karolherbst> oh well
<karolherbst> yeah I guess either solution is fine
<karolherbst> btw.. checkpatch is annoying
<gawin> at this point when I touch something which is a bit weird I'm afraid if there's another r300's hardware limitation
<gawin> recently I've read that r500 doesn't fully support pixel shader 3
<karolherbst> what does "fully support" even mean :p
<gawin> hardware can "implement" specific set of features, I guess?
fxkamd has quit []
vocalfan has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
flibitijibibo has joined #dri-devel
<clever> robclark: i flipped composition off for a bit, to see if it might help with a 3d game, and suddenly seeing the latency of Exposed based redraws, makes me realize how damn overloaded my chrome is, and the off-screen buffers where hiding it, lol
vivijim has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
mlankhorst has quit [Ping timeout: 480 seconds]
iive has quit []
pushqrdx has joined #dri-devel
Hi-Angel has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
tursulin has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
nchery is now known as Guest1937
nchery has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> anv_state_pool SIGSEGV caused the pipeline to fail
<alyssa> I seem to recall this was a known issue..
nchery is now known as Guest1938
Guest1938 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
Guest1937 has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
<alyssa> oh there's a dedicated issue for it and everything
<alyssa> zmike: I see you griping about it..?
Bennett has quit [Remote host closed the connection]
ngcortes has quit [Read error: Connection reset by peer]
<pushqrdx> any mesa devs online?
<zmike> nah I don't gripe about it
<zmike> 0.6% ci failure rate innit
<alyssa> zmike: be grateful you don't have hw errata to deal with in zink
<alyssa> ("no but I have other people's driver bugs")
<Sachiel> there are no bugs, just happy little mysteries
<zmike> not my bugs, but my problems
* alyssa currently working around a hardware bug
<alyssa> workaround requires punching through a bunch of abstractions..