ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
YuGiOhJCJ has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
nchery is now known as Guest1269
nchery has joined #dri-devel
yuq825 has joined #dri-devel
Guest1269 has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
ADS_Sr_ has quit [Ping timeout: 480 seconds]
<mareko> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23221 is assigned to Marge, I *think* the last commit isn't needed in stable
<mareko> the last commit should be fine in stable if it doesn't break the build
<DavidHeidelberg[m]> zmike: zink started brutally failing recently on Debian 12 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/42407683 not a flake
<DavidHeidelberg[m]> something must got broken in today MRs
<DavidHeidelberg[m]> (I guess, I hope I didn't introduce accidentally some fckup, but I don't expect to)
<zmike> uhhhhhhhh
<zmike> not sure what to do about that
alatiera has joined #dri-devel
nchery has joined #dri-devel
<DavidHeidelberg[m]> zmike: I'll try to revert tomorrow and see . thanks
Danct12 is now known as Guest1278
Danct12 has joined #dri-devel
nchery is now known as Guest1280
Guest1263 is now known as nchery
Guest1280 has quit []
Danct12 has quit [Quit: WeeChat 3.8]
aravind has joined #dri-devel
dcz_ has joined #dri-devel
Johnny has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
itoral has joined #dri-devel
clever has quit [Ping timeout: 480 seconds]
sukrutb_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has joined #dri-devel
gfxstrand is now known as Guest1286
gfxstrand has joined #dri-devel
clever has joined #dri-devel
Guest1286 has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
bgs has joined #dri-devel
rasterman has joined #dri-devel
ickle has quit [Quit: Off we go.]
ickle has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
fab has quit [Quit: fab]
kts_ has joined #dri-devel
kts_ has quit []
kts_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts_ has quit [Ping timeout: 480 seconds]
Leopold___ has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Leopold_ has quit [Ping timeout: 480 seconds]
schaeffer_ has quit []
schaeffer has joined #dri-devel
fab has joined #dri-devel
junaid has joined #dri-devel
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
pallavim has quit [Ping timeout: 480 seconds]
sghuge has joined #dri-devel
Guest522 has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
peelz has joined #dri-devel
peelz is now known as Guest1295
<MrCooper> mlankhorst: the diffstat in the drm-intel-fixes PR is 1 MB of mostly noise; if there's no way to get a more useful diffstat, might be better to just leave it out?
Guest1295 has quit [Read error: Connection reset by peer]
notpeelz has joined #dri-devel
zzoon has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
MajorBiscuit has joined #dri-devel
pochu has joined #dri-devel
smiles_ has joined #dri-devel
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
smilessh has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
Zopolis4 has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest1299
swalker__ has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
<jani> MrCooper: mlankhorst: there was already the question of how it was generated; doesn't seem done with dim. so maybe it's a question of the upstream used for generating the pull request?
sgruszka has joined #dri-devel
pochu has quit [Read error: Connection reset by peer]
pochu has joined #dri-devel
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
Haaninjo has joined #dri-devel
<dolphin> MrCooper, jani: are we talking about drm-intel-fixes, my last PR seems fine?
<dolphin> or did you mean drm-misc-fixes?
<MrCooper> maybe, apparently the subject was wrong as well
<MrCooper> the PR in question is still in the dri-devel moderation queue due to the above issue
<jani> oh wow
<jani> dolphin: you don't seem to be in Cc. it's drm-misc-fixes with drm-intel-fixes subject. rodrigovivi replied to it, but looks like that's also in the moderation queue due to size
Haaninjo has quit [Quit: Ex-Chat]
<MrCooper> yeah I rejected that, since it's 1 MB of quoted text, which was mostly noise in the first place :)
<MrCooper> moral of the story: trim quoted text
gouchi has joined #dri-devel
heat has joined #dri-devel
<jani> moral of the story: use the provided tooling for making pull requests ;D
JohnnyonFlame has joined #dri-devel
cmichael has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Zopolis4 has quit [Quit: Connection closed for inactivity]
lemonzest has quit [Quit: WeeChat 3.6]
<DavidHeidelberg[m]> zmike: first data suggest that you guessed the offending MR
<DavidHeidelberg[m]> zmike: verified, I propose to revert the MR and uprev CI and then wait until it pass, see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22378#note_1926396
junaid has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
zzoon has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
alyssa has joined #dri-devel
<zmike> DavidHeidelberg[m]: can you try adding asan to that job first so we can get an idea what's crashing?
<DavidHeidelberg[m]> Sure
<zmike> it's baffling that all this stuff gets hit on ci but nobody can repro locally
<pq> Isn't that what CI is for, finding problems no-one else does? :-)
smilessh has joined #dri-devel
smiles_ has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
pochu has quit [Quit: reboot]
Leopold___ has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
<cwabbott> gfxstrand: seems like VK_EXT_attachment_feedback_loop_dynamic_state is breaking some pretty fundamental assumptions in vk_graphics_state
<cwabbott> the state is part of vk_render_pass_state in the pipeline state but it's only part of the fragment output interface
<DavidHeidelberg[m]> zmike: https://gitlab.freedesktop.org/okias/mesa/-/jobs/42440333 is it useful to you?
<zmike> ughhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<cwabbott> just adding MESA_VK_DYNAMIC_ATTACHMENT_FEEDBACK_LOOP_ENABLE to MESA_VK_GRAPHICS_STATE_RENDER_PASS_BIT doesn't work because RENDER_PASS_BIT is "needed" by other stages
<cwabbott> so it won't get filtered out of e.g. pre-rasterization dynamic states
<zmike> DavidHeidelberg[m]: can you try pumping VVL to the commit hash of main on your branch
<zmike> there will be a new tag in a day or two but this should be an easy test to see if it's fixed
<DavidHeidelberg[m]> zmike: VVL?
<zmike> DavidHeidelberg[m]: https://gitlab.freedesktop.org/zmike/mesa/-/snippets/7633 I think should do it
<zmike> basically you're hitting a VVL bug that somehow is only triggering on your branch
<zmike> so the options are either disable VVL or try to uprev
<DavidHeidelberg[m]> zmike: testing uprev :)
camus has joined #dri-devel
<cwabbott> gfxstrand: but adding a whole new state group would seem to require adding a new struct that gets allocated etc. which seems bad for just one small field
kts has joined #dri-devel
<dolphin> airlied, sima: "Would the real drm-intel-fixes please stand up", the PR has been sent with just 1 line shortlog so should be easy tell from the other :)
<sima> dolphin, I think I'm missing some context, was this about a ping from airlied?
fxkamd has joined #dri-devel
<alyssa> nir_lower_shader_calls is ??????
<dolphin> sima: I think mlankhorst accidentally sent drm-misc-fixes as "drm-intel-fixes" titled PR
<dolphin> if you scroll up to what jani said
<dolphin> generating a 1 MiB log
<sima> dolphin, oh lol
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
smiles_ has joined #dri-devel
smilessh has quit [Read error: Connection reset by peer]
fdu has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
cuolarrrrrrrrrrrrrrrrrrrrrrrrr has quit [Remote host closed the connection]
kusma has joined #dri-devel
<kusma> CI appreciation day again! I sent an MR that touched a file in Zink, and I got a grand total of zero needless jobs triggered! Great work everyone!
yuq825 has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
<ccr> :O
tursulin has quit [Quit: Konversation terminated!]
heat has joined #dri-devel
* ccr suddenly starts singing "every CI node is sacred, every CI node is great / if a CI job is wasted, admins get quite irate"
ADS_Sr has joined #dri-devel
ADS_Sr has quit [Remote host closed the connection]
smilessh has joined #dri-devel
smiles_ has quit [Read error: Connection reset by peer]
<DavidHeidelberg[m]> zmike: new version helped, pushing, thanks!
aravind has joined #dri-devel
kzd has joined #dri-devel
<alyssa> kusma: :-D
<DavidHeidelberg[m]> kusma: don't worry, just merging Debian 12 CI uprev, it'll change.....
BenjaminBreeg has quit [Quit: BenjaminBreeg]
* DavidHeidelberg[m] obviously kidding... or not.
pallavim has joined #dri-devel
kts has joined #dri-devel
smilessh has quit [Remote host closed the connection]
smilessh has joined #dri-devel
<kode54> cleaning up my mail accounts
<kode54> I've been listening to a bunch of mailing lists and just skipping inbox and sending them to folders
<kode54> marking 400k unread messages as read...
<kode54> then I need to amend my filters to mark as read as well
<karolherbst> the only way of dealing with mailing lists
<DavidHeidelberg[m]> please do not assign to Marge in next ~ 30 minutes, I'll need to re-assign Marge for the CI upgrade (rootfs rebuild takes too long and it wasn't pre-prepared)
<kode54> ouch, good luck
<karolherbst> kode54: there is a little trick I'm doing to handle that nonsense: just push them all into mailing lists folders _unless_ you are on Cc or To, then they can into your inbox
<kode54> I wish I could do that to gmail filters
<karolherbst> you can
<kode54> oh wait, I can
<karolherbst> I have a "To Me" label in gmail where all mails go which are directly addressing me
alyssa has left #dri-devel [#dri-devel]
gouchi has quit [Remote host closed the connection]
<gfxstrand> cwabbott: Hrm...
fab has quit [Quit: fab]
lemonzest has quit [Quit: WeeChat 3.6]
biju has joined #dri-devel
lemonzest has joined #dri-devel
<doras> karolherbst: I'm trying to package Rusticl without much experience with OpenCL runtimes. I found that compiler/clc requires a few Clang headers at runtime. For example, `opencl-c-base.h` and a few others: https://gitlab.freedesktop.org/mesa/mesa/-/blob/394d592525c2ca80f428355bf8595ae33ed0b93d/src/compiler/clc/clc_helpers.cpp#L869
<karolherbst> correct. Those will be provided by clang
<doras> Since I'd rather avoid packaging unnecessary files as runtime-dependencies, do you know if there's a rule of thumb of exactly which files are needed at runtime?
<karolherbst> all headers clang ships
<doras> karolherbst: no Clang executables or something surprising like this, right?
<karolherbst> right, we only use libclang
<karolherbst> but it has to come with all the header files
<doras> Right. Thanks for the help, I hope this is the last obstacle.
<karolherbst> I think in general it is potentially fine to just ship the opencl-c-base.h header, but I'd rather not trying to be smart and just ship them all and have it be part of libclang packaging or something.. dunno
zzoon has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fxkamd has quit []
<kode54> whee
<kode54> fastmail is useless at filtering that way
pochu has quit [Ping timeout: 480 seconds]
<kode54> it doesn't provide a way to separately match to, cc, or bcc
<cwabbott> gfxstrand: any suggestions?
<jenatali> karolherbst: I still think it'd be useful to provide an option for someone to statically link opencl-c-base.h for running on systems without full Clang installed
<kode54> um, how does one statically link a header file?
<jenatali> Turn it into a byte array
<jenatali> We do it for the code we ship on Windows
<kode54> huh
<jenatali> Much easier than shipping it as a separate file and trying to find that file on disk
<jenatali> alyssa: Would you be able to take a closer look at the nir patches in !23173?
<kode54> is there a halfway decent mail client to use offline?
<kode54> thunderbird is just chugging away spinning a core almost completely just tracking my immense archives folders
<DavidHeidelberg[m]> Merged. It was stable before, hopefully it'll stay that way.
<gfxstrand> cwabbott: My first thought is that having a dynamic state part of the framebuffer shouldn't be a problem.
<gfxstrand> s/framebuffer/render pass/
<gfxstrand> cwabbott: But render pass state is weird because it's all broken into bits.
<cwabbott> yeah, it's the "broken into bits" part that makes this painful
<gfxstrand> cwabbott: So is the concern where to put it in the vk_dynamic_graphics_state struct? Or how to handle it at the pipeline level?
<cwabbott> gfxstrand: the pipeline level
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<gfxstrand> cwabbott: We already have the filtering for those two bits to only populate them as part of the fragment output interface. Or did I flub that somehow?
Leopold has joined #dri-devel
<cwabbott> gfxstrand: yeah, we handle the bits
<cwabbott> it's handling the dynamic state flag that's the problem
<gfxstrand> Why? That should really get handled in vk_dynamic_graphics_state_fill and that should be able to pull any state from anywhere.
<cwabbott> we need to make sure to ignore VK_DYNAMIC_STATE_ATTACHMENT_FEEDBACK_LOOP_ENABLE_EXT for stages except fragment output interface, because on the Vulkan level that's where it is
<cwabbott> that won't work if we make it part of MESA_VK_GRAPHICS_STATE_RENDER_PASS_BIT
<cwabbott> because that's considered needed by the last 3 stages
<gfxstrand> Oh, I see
<gfxstrand> It's get_dynamic_state_groups that doesn't really make sense.
<gfxstrand> Yeah, that's problematic. :-/
<cwabbott> exactly :-/
<cwabbott> that's where I kind-of got stuck
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
<cwabbott> one thing I was thinking about was passing VkGraphicsPipelineLibraryFlagsEXT to get_dynamic_state_groups
<cwabbott> but it seems like the design so far intentionally avoided passing that around
<cwabbott> so, I wanted to know how much you hated that
<gfxstrand> Yeah...
<gfxstrand> Okay, I see the problem.
<gfxstrand> It's all such a mess.
<cwabbott> yup
<gfxstrand> GPL sucks
<gfxstrand> I think we can just special-case the filtering.
<gfxstrand> Do get_dynamic_state_groups to get dynamic_filter and then do
<cwabbott> it's also not great that there are now like 3.5 ways to signal you have a feedback loop
kts has quit []
bgs has joined #dri-devel
<gfxstrand> if (!(lib & FRAGMENT_OUT)) dynamic_filter &= ~FEEDBACK_LOOP
<gfxstrand> With a comment about how annoying this all is
<gfxstrand> cwabbott: Yeah, that's really not great. Stuffing it in a flag was maybe not optimal.
<cwabbott> gfxstrand: I'm not 100% sure but wouldn't that barf in validation?
<gfxstrand> I don't think so.
<kode54> gee
<kode54> someone already doubting the importance of filtering the uAPI changes downstream
<kode54> I guess they didn't know there is 32-bit multilib downstream
<kode54> let's just fix that in the kernel instead
<gfxstrand> All it's doing is effectively discarding VK_DYNAMIC_STATE_ATTACHMENT_FEEDBACK_LOOP_ENABLE whenever you aren't including fragment output, which seems like exactly what we want.
<gfxstrand> That should default it to included which should be safe.
<gfxstrand> To be clear, that special case around filtering assumes that feedback loop is included in render pass state for all other purposes.
<cwabbott> gfxstrand: the other issue is that this doesn't interact that well with my feedback_loop_input_only thing
<cwabbott> first off, feedback loops from the render pass (real or emulated) are independent of the dynamically-enabled feedback loops, so we have to combine them at draw time
<cwabbott> so, the question is, do we merge feedback loops via the pipeline flags with renderpass ones (as we do now) or do we keep them separate and set the dynamic state with them
<MrCooper> DavidHeidelberg[m]: congrats on and thanks for bumping the CI to Debian bookworm!
<cwabbott> I'm doing the first thing, and just setting the dynamic feedback state to 0 when it's statically set
<cwabbott> that keeps existing drivers (anv) the same but leads to some weird code where we always set the dynamic state to 0 in the pipeline
biju has quit [Quit: Page closed]
biju has joined #dri-devel
smilessh has quit [Read error: Connection reset by peer]
smilessh has joined #dri-devel
<gfxstrand> cwabbott: Yeah... That's a bit weird.
<gfxstrand> cwabbott: I'm inclined to say that we should just have 4 logically independent bits: two for textures and two for input attachments.
<gfxstrand> We can patch ANV and RADV to deal with both.
<cwabbott> actually now that I think about it we don't *have* to have separate bits for texture vs. input attachment feedback loop
<cwabbott> that might help
biju123 has joined #dri-devel
<cwabbott> and, of course, input vs. texture is slightly different from renderpass vs. pipeline flags because the renderpass could be an emulated mesa one that uses textures, but unlike the pipeline flags it can be set independently from the dynamic bits
<cwabbott> *sigh*
djbw has joined #dri-devel
<cwabbott> I think if we tried to separate input vs. texture in the pipeline state, then we'd have 3 different feedback loop flags: texture on the pipeline, input attachment on the pipeline, dynamic texture
<cwabbott> and all 3 would need to be or'd together
<cwabbott> yeah, not sure that would be any better
sukrutb_ has joined #dri-devel
<gfxstrand> If you think you can do it with 1, I guess that's okay.
<gfxstrand> My thought about render pass emulation is that, if we ever do actual input attachments from emulated render passes, we'd set the input attachment flags for those.
<gfxstrand> Whatever that looks like.
Guest1299 has quit [Remote host closed the connection]
Leopold has quit []
<DemiMarie> kode54: not much?
<kode54> ?
cmichael has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
gouchi has joined #dri-devel
<mattst88> kode54: wrt gmail filtering, karolherbst is right -- you basically have to skip the inbox on things that aren't To: or Cc: you
<mattst88> https://github.com/mattst88/gmail-gitlab-filtering in "The Problem" section has a bit about doing this. it's pretty easy
<mattst88> the way this screws things up is, you basically never see emails that are bcc'd to you
pzanoni has quit [Quit: Coyote finally caught me]
<mattst88> I occasionally have to search my gmail for 'is:unread has:nouserlabels' to find those
<kode54> I'm attempting to set up notmuch with offlineimap
idr has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
biju has quit [Remote host closed the connection]
jkrzyszt_ has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
smilessh has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
<dcbaker> kode54: I had better luck with isync than with offlineimap, YMMV though
<kode54> ah
<dcbaker> but I gave up (and quit developing alot) after mesa switched to gitlab
sgruszka has quit [Remote host closed the connection]
robmur01 has quit [Remote host closed the connection]
CME_ has quit []
CME has joined #dri-devel
robmur01 has joined #dri-devel
biju123 has quit [Quit: Konversation terminated!]
<DemiMarie> dcbaker: why?
egbert has quit [Ping timeout: 480 seconds]
<dcbaker> Because mesa was the last project I worked on that still used a mailing list, outside of that the amount of email I get is so small it wasn't worth the effort
idr has joined #dri-devel
Haaninjo has joined #dri-devel
egbert has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Kayden has quit [Quit: -> JF]
ddavenport has quit [Quit: Leaving]
<doras> jenatali: it's possibly more convenient for my use case to have the Clang headers embedded. I'll check if it works.
<jenatali> Dor Askayo: Right now the header is embedded if the microsoft-clc project is included in the build. It really should be split into a separate build option
<doras> jenatali: I can open a MR if it ends up working fine for me.
<jenatali> Cool, sounds good
sima has quit [Ping timeout: 480 seconds]
pzanoni has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
gouchi has quit [Remote host closed the connection]
JohnnyonF has joined #dri-devel
fab has quit [Quit: fab]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
sarnex has quit [Ping timeout: 480 seconds]
ultra has joined #dri-devel
sarnex has joined #dri-devel
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
pallavim_ has joined #dri-devel
greenjustin_ has joined #dri-devel
lumag_ has joined #dri-devel
mmenzyns has joined #dri-devel
agd5f has joined #dri-devel
sukrutb__ has joined #dri-devel
Mangix_ has joined #dri-devel
idr has quit [synthon.oftc.net reflection.oftc.net]
sukrutb_ has quit [synthon.oftc.net reflection.oftc.net]
pallavim has quit [synthon.oftc.net reflection.oftc.net]
anarsoul has quit [synthon.oftc.net reflection.oftc.net]
notpeelz has quit [synthon.oftc.net reflection.oftc.net]
schaeffer has quit [synthon.oftc.net reflection.oftc.net]
Piraty has quit [synthon.oftc.net reflection.oftc.net]
vaishali has quit [synthon.oftc.net reflection.oftc.net]
agd5f_ has quit [synthon.oftc.net reflection.oftc.net]
Mangix has quit [synthon.oftc.net reflection.oftc.net]
jhli has quit [synthon.oftc.net reflection.oftc.net]
shankaru has quit [synthon.oftc.net reflection.oftc.net]
flto has quit [synthon.oftc.net reflection.oftc.net]
kisak has quit [synthon.oftc.net reflection.oftc.net]
mmenzyns_ has quit [synthon.oftc.net reflection.oftc.net]
quantum5 has quit [synthon.oftc.net reflection.oftc.net]
rcf has quit [synthon.oftc.net reflection.oftc.net]
eukara has quit [synthon.oftc.net reflection.oftc.net]
ernstp_____ has quit [synthon.oftc.net reflection.oftc.net]
Shibe has quit [synthon.oftc.net reflection.oftc.net]
greenjustin has quit [synthon.oftc.net reflection.oftc.net]
unerlige has quit [synthon.oftc.net reflection.oftc.net]
lumag has quit [synthon.oftc.net reflection.oftc.net]
rsripada_ has quit [synthon.oftc.net reflection.oftc.net]
sumits has quit [synthon.oftc.net reflection.oftc.net]
kisak has joined #dri-devel
jhli has joined #dri-devel
idr has joined #dri-devel
vaishali has joined #dri-devel
notpeelz has joined #dri-devel
flto has joined #dri-devel
ernstp_____ has joined #dri-devel
shankaru has joined #dri-devel
quantum5 has joined #dri-devel
unerlige has joined #dri-devel
rsripada_ has joined #dri-devel
schaeffer has joined #dri-devel
Piraty has joined #dri-devel
anarsoul has joined #dri-devel
rcf has joined #dri-devel
Kayden has joined #dri-devel
Shibe has joined #dri-devel
Kayden has quit [Quit: change networks]
sumits has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
Kayden has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
vliaskov has quit [Remote host closed the connection]
orbea has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
rauji___ has joined #dri-devel
<q66> any hints what to attempt if i get graphical corruption like this? https://matrix.org/_matrix/media/v3/download/matrix.org/UHnidhnXhJsiAHfXWiAxyHeK/IMG_1850.jpeg
<q66> it's gnome-shell, wayland, on ampere altra aarch64, mesa 23.1.0, clang, musl, amdgpu (radeonsi); tested radeon rx 5500xt (navi) and radeon pro wx2100 (polaris) with identical results
<q66> the corruption appears to be application-side as forcing LIBGL_ALWAYS_SOFTWARE=1 makes it go away
<q66> and the corruption scrolls with the content in firefox which also indicates it's application-side
<q66> but not quite sure where to start looking
<q66> tried setting various radeonsi-related env vars without much success
<q66> i originally thought it was kernel, because getting the rx5500xt working on the altra was quite an ordeal (by default it panics the kernel, you gotta disable a bunch of stuff) and then there were still some scary messages in dmesg, but now the output is clean and needs no workarounds, yet i still get graphics corruption on a completely different gpu, so i suspect mesa now :)
<q66> also using zink for firefox also fixes the corruption in firefox, but if i run gnome-shell with it or certain other apps that are affected, the whole screen gets corrupted :)
smilessh has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
smilessh has quit [Read error: Connection reset by peer]
smilessh has joined #dri-devel
airlied has joined #dri-devel