<mareko>
Venemo: this has happened ~5x in the history of the driver
sdutt has joined #dri-devel
<Venemo>
I guess I'm too new here and missed the previous occasions
<mareko>
Venemo: I don't think it breaks anything - I often restart X when I'm bisecting, it's kinda necessary
<Venemo>
I could live with just breaking bisecting, but I'm very concerned about people who run steam or other apps in flatpak
<mareko>
I'm not familiar with that, but they can't mix'n'match drivers
<mareko>
or driver versions
<cwabbott>
well, they do
<cwabbott>
too bad
<cwabbott>
it's open source, you can't control what your biggest users do
<cwabbott>
unless you wanna do the work of switching them over to modifiers
<pq>
Do Flatpak runtimes come with their own copies of mesa which can differ from the system mesa?
<MrCooper>
mareko: if you read the GitLab issue, people explain multiple valid scenarios where different versions of Mesa interacting is expected
<mareko>
if flatpak ships its own Mesa, we can't support it
<MrCooper>
pq: that is indeed one of them
<mareko>
the BO metadata should be enough to ensure compatibility with other versions, investigating why it doesn't work might help with this issue
<cwabbott>
you don't get to decide alone what to support and what not to support
<pq>
MrCooper, I guess that makes zwp_linux_dmabuf_v1 create_immed more risky that expected, too?
<pq>
*than
<MrCooper>
not familiar enough with that yet to say I'm afraid
<pq>
MrCooper, it's the "import dmabuf to compositor and cannot fail" path, used by Mesa because it should always work (the same driver exporting and importing) and cannot fall back to anything if it failed anyway.
mattrope has joined #dri-devel
<mareko>
there is actually a solution for flatpak users: don't update Mesa
<Venemo>
they can't put it off forever
<Venemo>
mareko: I'm afraid I'm not familiar with the topic, but I'd be happy to learn. what can I do to help investigate why the BO metadata doesn't work?
<daniels>
well, the easy option is just for distributions (as well as people generating e.g. Flatpak/Steam runtimes) to patch radeonsi to not do DCC, so then you can only break it if you build it yourself
<Venemo>
I would certainly prefer to achieve a solution upstream
<daniels>
that would seem preferable, yeah
<mareko>
Venemo: I have a fix
<Venemo>
wow, cool :)
<mareko>
not tested
alanc has quit [Remote host closed the connection]
<gawin>
If I follow it correctly, then "empty" TexSrcTarget is causing empty writemask later
<Venemo>
mareko: running a vk sample app on that branch, it seems that the surfaces it uses don't have the imported flag
<gawin>
aah, tbo is part of opengl 3.1(?) so it's not weird that is missing
<Venemo>
mareko: if I just set independent_64B_blocks=1 unconditionally, then the corruption goes away
jessica_24 has joined #dri-devel
<danvet>
seanpaul, [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible <- still on you to land this all?
<danvet>
not sure whom I actually pinged
alyssa has left #dri-devel [#dri-devel]
<Venemo>
mareko: also I now tried running XWayland on the same mesa version as the app, and I still see the corruption
<danvet>
pinchartl, [PATCH] [RESEND] drm/rcar: stop using 'imply' for dependencies <- this is for you
<mareko>
Venemo: the MR describes why it won't work for vulkan
<pinchartl>
danvet: yep, I've seen it
<Venemo>
mareko: I see. So radv will need some work...
<Venemo>
mareko: I think it's not enough that X and the app use the same mesa, the Wayland compositor also has to
<mareko>
of course
unsolo has quit [Ping timeout: 480 seconds]
<ajax>
Venemo: what i was gesturing at with "kinda" was that it's possible to figure some things ou but it's extremely fiddly and you're better off divining whether the thing you want to do will work by means of something other than "what mesa version am i talking to"
<Venemo>
yeah, agreed
<ajax>
DRI3 could probably use something like a DRI3QueryString request so drivers could advertise features like RADEONSI_dcc_for_gfx8 or whatever
<ajax>
anyone feels like hacking on x11 can go right ahead, there
<ajax>
but! larger point here is, flatpak shipping its own libGL is kindacrazy and i feel like better solutions are not only possible but wise
<ajax>
BUT I WANT TO RUN ON CENTOS6 maybe want better things
<Venemo>
Yeah, but until they figure it out, we ought not to break them
<HdkR>
There are games on Steam also shipping their own libGL, not 100% a flatpak problem
<Venemo>
mareko: I also tried with glxgears now, and that is still broken on your branch
<ajax>
i'm aware
<mareko>
Venemo: you said that setting the indep_64B fixes it, why does ac_surface_set_bo_metadata have no effect then?
<HdkR>
Flatpak setting a precedent for shipping your own libGL is...dangerous though
<mareko>
apps shipping their own GPU drivers now? luls
<pq>
Games are too big, no-one notices if they ship a whole OS bundled. I'd like to refer to games in the floppy era where starting it meant booting into it but... I can't quite.
<APic>
Good old Times.
* APic
still remembers the pirated 720KB-Floppy with Nintendo Donkey Kong for the IBM PC Clone
<APic>
Also DIGGER.EXE that directly wrote the Highscore-Table to a Sector used by the FAT Filesystem, so You could not copy any other Games to a DIGGER-Disk 😉
<APic>
Aaaand Night Mission Pinball where You iirc could still select if You had a CGA or a Hercules-Adapter from the Bootmenu
<MrCooper>
mareko: Flatpak runtime, not apps; using the host drivers in the sandbox seems to be tricky, as they may be built against newer versions of e.g. glibc than is available in the sandbox
<jenatali>
That's a bit of a terrifying problem to have... almost makes me happy that we don't have a stable kernel driver interface on Windows so nobody can just bundle a driver into their package and call it a day
mlankhorst has quit [Quit: Konversation terminated!]
<Prf_Jakob>
So what would be the reason for basically any vk command/function writing to a command buffer suddenly take 10 times longer to complete?
<daniels>
ajax: it's not 'I want my game to run on CentOS 6', it's 'I want to build my game once on Ubuntu 18.04 and have it still run on Ubuntu 24.04 years after I've stopped caring'
<mareko>
Venemo: I don't think this is fixable, you would need to use my MR and then also apply it to older Mesa
<mareko>
MrCooper: flatpak needs to update Mesa then
<mareko>
Venemo: the old Mesa is broken and beyond repair
<mareko>
Venemo: with my MR + if RADV gets fixed too, inter-version interop should work after that
* danvet
chants "modifiers, modifiers"
<MrCooper>
mareko: does app using newer Mesa work with Xwayland + Wayland using older Mesa?
<Venemo>
no
<ajax>
daniels: where "stop caring" still means "issue updates with new libGLs embedded"?
<ajax>
curious usage but okay
<MrCooper>
mareko: that's not a workable solution then
<Venemo>
there is a suggestion from JoshuaAshton to revert the part that affects the non-modifier code path there
<HdkR>
daniels: Sadly shipping libGL doesn't solve the problem of wanting their game to work in 24.04 years. Their libGL very likely won't even support the hardware the application is trying to run on at that point :)
<Venemo>
mareko: if I understand the suggestion by JoshuaAshton - this would still allow to get the best performance with an up to date kernel, but would preserve backwards compatibility, right?
<daniels>
ajax: I mean that's why the distribution model doesn't work for games, and you have to do something which isn't that
lemonzest has quit [Quit: WeeChat 3.2]
<daniels>
hence why Steam and Flatpak (neither of which bundle the libGL that happened to be on the developer's machine when the game was made and keep that immutably forever) exist and do the things that they do
<clever>
daniels: ive also run into problems where the libc shipped with the steam "container" wasnt compatible with the host libGL
iive has joined #dri-devel
<ajax>
Thread 13 "WSI swapchain q" received signal SIG32, Real-time event 32.
<ajax>
seriously gdb, do you not know how pthread_cancel is pronounced in linux
lemonzest has joined #dri-devel
<zmike>
that's definitely not going to be annoying at all
<HdkR>
ajax: `handle SIG32 noprint` ?
<ajax>
that makes it not print a silly thing, sure. i was more kvetching that it didn't print an informative thing.
<ajax>
blah blah we can't know what the realtime signals mean because we're pooooooortable
<ajax>
look. you see a glibc, and a linux. what do you think the rt signals mean.
<HdkR>
Doesn't gdb stop on most every signal though?
<HdkR>
Although SIGTRAP is a nightmare
<zmike>
I think he's complaining about it not showing the correct name
<zmike>
stopping is irrelevant
<HdkR>
ah
Ahuj has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
<ajax>
right, was hoping for more like "Thread 32 received pthread_cancel from thread 7"
<ajax>
and yeah any time you see gdb break on sigtrap you should really just close the laptop and go outside
unsolo has joined #dri-devel
alanc has quit [Remote host closed the connection]
nchery has joined #dri-devel
sukbeom has quit [Ping timeout: 480 seconds]
swick has quit [Quit: WeeChat 1.6]
rgallaispou has quit [Read error: Connection reset by peer]
gawin has quit [Ping timeout: 480 seconds]
nchery has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
nchery has joined #dri-devel
<karolherbst>
HdkR: you can disable it
<karolherbst>
"handle SIGTRAP noprint"
<karolherbst>
ahh..
<karolherbst>
you know that already
<karolherbst>
ajax: break signal; commands;p sgig;c;end or something
<karolherbst>
kind of depends on the paramter name and what function is called on a signal
<karolherbst>
or just do handle SIGNAL nostop
<dcbaker>
karolherbst: while you're here... that rust + meson bug you found had to do with rlib "A" linking in rlib "B", then "A" needs to be rebuilt not just relinkined when "B" is rebuilt, right?
<karolherbst>
yes
<dcbaker>
cool
<karolherbst>
if you have a fix for that I would be happy to try it out :D
<dcbaker>
I'm trying to write one, we're going to freeze for 0.60 on the 10th, so I'd like to have it fixed by then :)
<karolherbst>
although if we go for "blockers blocking adding rust prototypes to mesa" we might want to look into this bindgen wrapper thing with forward declared struct situation which is super annoying :( at least that's what's blocking me from submitting the code
<karolherbst>
nice
<ajax>
why does vulkan wsi write its own message queue instead of using pthread_sigqueue
<ajax>
or like... anything else.
<dcbaker>
karolherbst: what's up with bindgen and forward declared structs?
<HdkR>
karolherbst: I do `handle SIGBUS SIGILL SIG63 noprint` every day. I understand the problems :P
<karolherbst>
dcbaker: mixed source and gen files
<karolherbst>
rust doesn't do forward declaration, so if you need to forward declare types yourself you are screwed
<dcbaker>
oh, yeah, I have a solution I think we've agreed on, I just need to write code
<karolherbst>
ahh cool
<dcbaker>
for the mixed gen/static
<karolherbst>
going for the copying or the wrapping?
gawin has joined #dri-devel
<dcbaker>
I think in the long run we'll need both, but the immediate plan is copying
<karolherbst>
okay
<dcbaker>
cython also needs the copying solution
<dcbaker>
and I think zig as well
yogesh_m1 has joined #dri-devel
<karolherbst>
dcbaker: but then we need to declare a list of all needed files, right?
<karolherbst>
I mean.. people should probably do it regardless
<dcbaker>
yes, unfortunately we will need all of the files in that case
yogesh_mohan has quit [Ping timeout: 480 seconds]
* dcbaker
actually wrote running rust code without reading the docs for once
macromorgan has quit [Read error: Connection reset by peer]
Viciouss7 has joined #dri-devel
Viciouss has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
Bennett has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
sdutt has quit []
* jekstrand
builds zink
<HdkR>
Confirmed by jekstrand, Iris is being abandoned for Zink
<jekstrand>
:P
<jekstrand>
You heard it here first, folks!
<jenatali>
Soon to hear it again on Phoronix :P
<jekstrand>
If Phoronix is to believed, Zink is like 50x faster, anyway.
<soreau>
most all shaders work on 32bit wayfire with RV350, aside from water and blur. The shaders only require #version 100 and the driver claims GLSL 1.2.. must be a bug
<soreau>
with blur it misrenders garbage and with water it slows the system as if it's rendering but there is no visible effect
<zmike>
jekstrand: that was weeks ago
<anholt_>
what are people's favorite ways of visually testing yuv eglimage import these days?
<zmike>
it's 100x faster now
<Sachiel>
100x faster return to prompt
<zmike>
there we go
<zmike>
really tho zink is in release mode until after the branch, so It Should Be Stable
<jekstrand>
vulkaninfo works but it doesn't seem to work with x11 or gbm
<jekstrand>
with different failure modes
ngcortes has joined #dri-devel
<zmike>
I don't think I've ever set PIGLIT_PLATFORM
<zmike>
but uhh... other than that seems like what I'd be doing?
<zmike>
ah you might also need
<zmike>
🤔
<zmike>
that Mesa loader driver path var
<zmike>
on phone now and don't have it handy
<daniels>
your phone doesn't run Zink?
<daniels>
@larabel
<zmike>
it does, can't check the references because it keeps crashing
<zmike>
I mean
<zmike>
because it's too fast.
<zmike>
jekstrand: try in gdb and you should be able to see the driver .so it's loading, my guess is you're using distro one
<jekstrand>
zmike: If I run without PIGLIT_PLATFORM=gbm, I get "failed to create dri screen"
<jekstrand>
presumably because it can't talk to X or some such
<zmike>
that's usually just when it can't load the driver
<jekstrand>
hrm...
<zmike>
s'why I said check the .so being loaded
<jekstrand>
I've got /home/jason/projects/mesa/main/_install/lib64/dri/zink_dri.so in my backtrace
<jekstrand>
I threw PIGLIT_PLATFORM=gbm back in
<jekstrand>
Actually, that's without PIGLIT_PLATFORM
<zmike>
🤔
<zmike>
could check breakpoints in the zink screen create functions
<zmike>
the zink startup has no logging to tell you what's failing
<zmike>
I keep hoping I'll get a new contributor who wants to add it
<jekstrand>
:P
<zmike>
hey I made a starter project ticket and this is one of the top items
<zmike>
it's v visible
<jekstrand>
Oh.... It's failing because I don't have ZINK_USE_LAVAPIPE enabled.
<jekstrand>
I think
<zmike>
are you trying to run on lavapipe?
<jekstrand>
yes
<zmike>
oh
<zmike>
should've said so
X-Scale has joined #dri-devel
jessica_24 has joined #dri-devel
<zmike>
you need that var and also GALLIUM_DRIVER=zink
<jekstrand>
Bingo!
<jekstrand>
I can now repro my bug. :D
xexaxo has joined #dri-devel
<zmike>
hooray
X-Scale` has quit [Ping timeout: 480 seconds]
<jekstrand>
Woo! Test passing.
frieder has quit [Remote host closed the connection]
<jenatali>
jekstrand: I realized this morning, when we want to enable generic address space support for Clover/CLOn12, we'll need to patch libclc... there's a few math library functions that are missing overloads for it :(
<jekstrand>
jenatali: Maybe get the patch started now?
<jekstrand>
If it's obvious enough.
<jekstrand>
I hate posting untested code, though.
<jekstrand>
jenatali: Do you support 1.x or 3.0?
<jenatali>
Yeah I was looking at it... Not sure that it's that simple. All of libclc builds as 1.2 right now, so I'll need to add options for how to build it
<jekstrand>
oof
<jekstrand>
jenatali: What functions are missing overloads?
<jenatali>
I believe I have a complete 3.0 API implementation, but I can only support CL C 1.2 still because Clang doesn't have full optionality for some of the features made optional in 3.0
X-Scale` has joined #dri-devel
<jenatali>
I think it's just a few math one with two-param returns, so one is the retval and another is an out pointer
<jenatali>
E.g. fract
<jekstrand>
Right...
<jenatali>
I'd also say the vload/vstore ones, but we don't use those from libclc
<jekstrand>
So someone has to write clang patches...
<jenatali>
I know airlied was working on it, and I believe that Clang 14 might actually have it ready?
<jekstrand>
Oh, that'd be neat
* jekstrand
is so glad the OpenCL people did 3.0
* jekstrand
is annoyed that 3.0 doesn't require SPIR-V
<jenatali>
Yeah, we could totally work around the missing overloads in the lower_libclc nir pass if we really needed to, just create another variant and patch the deref modes
<jenatali>
Heh, yeah... I did add SPIR-V support though
<jenatali>
I hope I get time to get back to CL at some point, I hate leaving it half-finished, but stupid corporate priorities mean I have to do other stuff instead :P
<jekstrand>
Yeah... Corporations... Why do we work for them again? Oh, right, so we can afford to eat.
<jenatali>
:D
X-Scale has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<jekstrand>
Of course the -invalid test fails. It's invalid! It says so right there in the name. :P
<zmike>
I fixed most of them a while ago, iirc the buffer ones are still broken though
<jekstrand>
I broke the image ones
<zmike>
ah good
<jekstrand>
Fixed now, I think.
<jekstrand>
Only one more CI run, I hope.
dviola has quit []
<anarsoul>
is there any way to enforce varying alignment? lima prefers vec3 always to be in xyz and vec2 to be in xy or zw since there's no swizzle on varying load instruction
<jekstrand>
anarsoul: You probably want to disable varying packing
<anarsoul>
it's a problem for texture coordinates since if load texture isn't fed directly from load varying it downgrades coordinates precision to fp16
<jekstrand>
I'm not sure what gallium bit to do that
<anarsoul>
jekstrand: not really, we've got only 13 varyings
<jekstrand>
ugh
<jekstrand>
I don't think there's any way to enable packing and also enforce an alignment, currently.
<anarsoul>
OK, so I guess I need to hack assign_varying_locations()
<jekstrand>
Or nir_compact_varyings
<anarsoul>
thanks! I'll look into it
<jekstrand>
You might have to add a new flag or two to nir_compact_varyings. Not sure what you'd want there. Maybe just nir_pack_varying_aligned or something like that which aligns to the next power-of-two.
<jekstrand>
Might not compact as well but that sounds good enough for your use-case
<anarsoul>
yeah, not compacting as well is my concern, we'll have to decide whether we want sharp textures or ability to compile more shaders
elongbug has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<jekstrand>
anarsoul: If you make it intentionally lay stuff out in order from largest to smallest, that should prevent most compaction problems.
<jekstrand>
Actually... It should prevent all of them.
<jekstrand>
vec4 will always fill a slot. vec3 will always fill a slot and leave one left over. vec2 will fill two-per-slot, and float will fill in the cracks.
ybogdano has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
Emantor has quit [Read error: Connection reset by peer]
Emantor has joined #dri-devel
Stary has quit [Read error: Connection reset by peer]
V_ has joined #dri-devel
haasn` has joined #dri-devel
jernej_ has joined #dri-devel
haasn has quit [Ping timeout: 480 seconds]
V has quit [Ping timeout: 480 seconds]
jernej has quit [Ping timeout: 480 seconds]
Stary has joined #dri-devel
jernej_ is now known as jernej
lynxeye has quit []
ybogdano has joined #dri-devel
<ajax>
am i reading this right that xserver doesn't send a Present event when a window is destroyed?
<ajax>
that seems... bad
<zmike>
ohhhh that explains it
<daniels>
ajax: maintaining GLX was heroic, but stepping up for Present as well is above and beyond tbh
<ajax>
well
<ajax>
wsi's gotta work
<daniels>
make a new winsys, buys you a few years
<ajax>
wsi/x11 seems like it's been touched by a lot of hands that understand neither wsi nor x11
<zmike>
I hear the name Z Windows is available
<ajax>
i especially like the part where we build elaborate async notifications for window geometry changes when... we have xcb... and xcb_get_geometry...
<jenatali>
X12?
<ajax>
just throw the request and make sure the reply is what you expected before you swap, jfc
<ajax>
gives you window destroy notifies for free
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand>
ajax: You can blame me for most of it. But I'll just pass the blame in the general direction of all the non-existant WSI experts who didn't step up and left me trying to learn XCB and present and X11 in general all at the same time while figuring out Vulkan WSI way back in the day.
<ajax>
mea culpa tbqh
<ajax>
not like i didn't know wsi/x11 was a thing, then
<ajax>
just... trying to figure out how to make this work without running screaming into the atlantic
<jekstrand>
Face the pacific. You've got a lot further to run before you get wet that way.
<zmike>
he might get tempted by the great lakes though
<daniels>
jekstrand: sore point with ajax and crossing the Pacific tho …
* jekstrand
feels like he's missing something
<ajax>
i missed an LCA years ago because weather and connections not communication meant i got stranded at jfk
<ajax>
'not communicating' even
<jekstrand>
Ah
<ajax>
which, also my fault for booking the connecting flights through non-allied airlines
<daniels>
luckily your baggage made it to … Tahiti?
<ajax>
pretty sure it got all the way to sydney and back
<ajax>
or that's what i remember the luggage tags saying
<daniels>
at least it had a nice trip
<ajax>
coworkers were very confused when i showed up in the office on monday like nothing was amiss
gouchi has quit [Remote host closed the connection]
linearcannon has quit [Read error: Connection reset by peer]
linearcannon has joined #dri-devel
pushqrdx has joined #dri-devel
<pushqrdx>
i am having real trouble with bad performance on Linux/Intel igpu using modesetting/mesa and i wonder if this is a place i could get some help
unsolo has quit [Ping timeout: 480 seconds]
<HdkR>
Is there a debug flag for any of the Vulkan drivers to know if an application requests a feature and the driver doesn't support it? Found a game using some feature that's unsupported but I don't know which
<bnieuwenhuizen>
maybe compiling in debug mode?
<bnieuwenhuizen>
if it has an annotated error return, otherwise you may need to add a print yourself
<vsyrjala>
doesn't vk have those layer things?
<Sachiel>
validation layers?
<bnieuwenhuizen>
oh maybe validation layers do it too yeah
<jekstrand>
We've got patches in-flight which will make Mesa start logging that stuff.
<FLHerne>
Looks fine to me -- right driver [i965 on Haswell], recent version
xexaxo has quit [Read error: Connection reset by peer]
<FLHerne>
What's the performance issue?
xexaxo has joined #dri-devel
<emersion>
bnieuwenhuizen: force-disabled on intel, but iirc enabled on everything else
<FLHerne>
You could try using the new `crocus` driver instead of i965 by setting the env var MESA_LOADER_DRIVER_OVERRIDE=crocus
<emersion>
bnieuwenhuizen: ping jadahl for details
<FLHerne>
but that's still a bit experimental, and slower in some cases while faster in others
<emersion>
… because intel is just so special
<Kayden>
.... hooray :/
<bnieuwenhuizen>
emersion: thanks, sounds like I have some debugging to do then
<pushqrdx>
FLHerne: all opengl apps except glxgears are running at very low fps, for instance Bespoke Synth doesn't go anything above 30fps.. also Helio Workstation (another opensource opengl music app) runs at 25fps max
<pushqrdx>
FLHerne: i can't try crocus cause for some reason even though i have mesa 21.2.2 on debian unstable, crocus.so isn't available
<Kayden>
pushqrdx: have you tried running those apps with the vblank_mode=0 environment variable set?
<FLHerne>
maybe Debian build without it for some reason
danvet has quit [Ping timeout: 480 seconds]
<Kayden>
(that wouldn't surprise me, I don't think crocus is quite ready for prime time yet)
<FLHerne>
besides what Kayden said, I wonder if it's that issue the Mutter devs were running into
<pushqrdx>
Kayden: just tried vblank_mode=0 still 30fps
<pushqrdx>
FLHerne: i don't use a compositor, just very simple openbox without composition
<jekstrand>
emersion: What's force-disabled?
<pushqrdx>
even with a compositor like picom doesn't change anything
<FLHerne>
where the GPU isn't clocked high enough under light load because the kernel driver gets it wrong
vivijim has quit [Ping timeout: 480 seconds]
<pushqrdx>
FLHerne: i can almost feel something like this is happening have no way of verifying though, is there a way to force max clock speed and test?
<FLHerne>
the symptom of consistently missing alternate frames sounds similar
<Kayden>
pushqrdx: in /sys/class/drm/card0 you can cat gt_{min,max,cur,act}_freq_mhz. min/max are self-explanatory...cur is what the kernel is requesting the hardware to do. act is the actual current frequency of the HW
<FLHerne>
I think there's something in IGT to set the GPU frequency?
<Kayden>
as root, you can also echo 900 > gt_min_freq_mhz to restrict the range that the kernel is allowed to request
<Kayden>
yeah I think there is a tool to do that, I never use it though and just poke at the files directly
<pushqrdx>
act/cur are running at 200 for me now
<Kayden>
wow
<Kayden>
that's not right at all
<pushqrdx>
even while running the app and it's rendering stuff, both act/cur are 200
<pushqrdx>
atleast explains why performance is crap
<Kayden>
yeah
<Kayden>
I bet if you increase gt_min_freq_mhz there it will work better
<Kayden>
but then the question is why it's doing that
<Kayden>
could try different kernel versions too in case that's already fixed, or recently regressed
ybogdano has quit [Ping timeout: 480 seconds]
<pushqrdx>
Kayden: hmm, i set min to 1000 but still i am running at ~30fps
<pushqrdx>
even though cur/act report 1000 now
<Kayden>
in that case, it sounds like you aren't GPU limited. is the CPU maxed somehow? if not, then there's probably some awful synchronization going on between the two, so neither is busy
<pushqrdx>
Kayden: the cpu isn't maxed now, < 3% utilized
<pushqrdx>
no*
<Kayden>
INTEL_DEBUG=perf on the app might be interesting
<pushqrdx>
Kayden: prints alot of "Using a blit copy to avoid stalling on glBufferSubData..."
<Kayden>
that should be fine
<pushqrdx>
and on the app with 30fps doesn't print anything other than SIMD32 shader inefficient
<Kayden>
anholt_, ajax: I'm still so confused how "manywin" is supposed to work on other drivers. I wrote code to do what radeonsi does, which seems to be deduplicate bufmgrs across fstat-equivalent DRM device files, and deduplicate pipe_screens across os_same_file_description(). Nothing is deduplicated for manywin, though. So...
<Kayden>
anholt_, ajax: pipe_resources have a prsc->screen field. Screens are getting freed and then resources are getting freed. prsc->screen is a stale pointer pointing at a screen with refcount 0.
<Kayden>
radeonsi doesn't use u_transfer_helper, which may mean that they aren't using prsc->screen by luck, and not crashing
<Kayden>
iris works by having resources refcount screens (no idea how gallium itself is getting away with having resources outlive screens and not doing reference counting for the core field)
<Kayden>
I'm pretty sure freedreno will just simply crash.
NiksDev has quit [Ping timeout: 480 seconds]
<Kayden>
I thought that Gallium was probably reusing resources across screens...where the screens *should* deduplicate to the same thing. But they don't.
<Kayden>
I guess if you deduplicate *all* screens then it would work
<Kayden>
except that breaks dmabuf exports between multiple opens() of the DRM device file, which amdgpu claims to support, and iris tries to support
<emersion>
please support it, i do it
<Kayden>
emersion: freedreno doesn't AFAICT
<emersion>
haven't seen freedreno crashes so far *crosses fingers*
<robclark>
where is this manywin thing?
<Kayden>
mesa demos
<Kayden>
I take it back, I suspect manywin does work on freedreno, because it deduplicates *all* screens
<Kayden>
which would make compositors like emersion's case break instead
<robclark>
hmm, seems like fedora mesa-demos doesn't include it?
<Kayden>
but if you handle that, then you can't make manywin work
<bnieuwenhuizen>
Kayden: radeonsi/amdgpu dedupes all screens too, no?
<Kayden>
bnieuwenhuizen: it doesn't
<Kayden>
it deduplicates across fstat-equivalent files for the winsys/device, but deduplicates amdgpu_winsys_screen across os_same_file_description() equivalence (i.e. different opens() -> different screens)
<emersion>
hm i think i only dup() the DRM FDs i give to mesa
<bnieuwenhuizen>
oh right, winsys only
<Kayden>
Yeah, dup() is fine.
<Kayden>
We can deduplicate dup()'d fds
<emersion>
an open() when i manually drmPrimeFdToHandle/etc
<emersion>
and*
<robclark>
hmm, mesa-demos still uses autotools.. which made me realize that until now I hadn't even installed autotools on this laptop
<Kayden>
wow :)
<Sachiel>
dcbaker: ^ get to work
<dcbaker>
I had a branch until Jose decided to rewrite it all to glad and just push it
<dcbaker>
err, well, really I wasn't paying attention :)
<robclark>
heh, or automake for that matter
<gawin>
if disabling optimizations is generating more graphical issues, then does it mean that all my piglit's results are invalid?
<dcbaker>
I had a branch that switched to epoxy and meson
<dcbaker>
but i never untangled them
<Kayden>
Yep, if I make iris stop using u_transfer_helper_resource_destroy and just do iris_resource_destroy directly...then it avoids the stale prsc->screen pointer
<Kayden>
and manywin works fine
<Kayden>
so the only reason radeonsi works is that it doesn't use u_transfer_helper, and is getting lucky to not use dead pointers.
<Kayden>
I guess we probably need some test cases for the multiple-open() case that MrCooper cares about
<gawin>
r300 with noopt is missing lights in xonotic...
<FLHerne>
[I still suspect it's a kernel problem rather than Mesa, but the driver devs can figure that out]
<Kayden>
robclark: if you comment out the util_hash_table_get() in freedreno_drm_winsys.c, so you get multiple screens, then you'll run into the same crash I am with manywin, I think.
DPA- has joined #dri-devel
<robclark>
heheh, I suppose there are a lot of things I can comment out to make things crash
<Kayden>
true, but...
DPA has quit [Ping timeout: 480 seconds]
<Kayden>
okay, I guess I just have to make test cases to break everyone's drivers
* robclark
still working thru all the old crufty things I need to install to build mesa-demos
<dcbaker>
What I really should do is finish porting the useful bits of mesa demos
<dcbaker>
I did start building a waffle based gears + info implementation
<robclark>
I'm kinda just happy that I'd gone this long without installing autotools/automake ;-)
pnowack has quit [Quit: pnowack]
<Kayden>
that is pretty awesome
<Kayden>
you technically could use CMake instead I guess
<pushqrdx>
FLHerne: i have multiple linux installs with different kernels, 5.9, 5.11, and 5.10-rt (current) all have the same issue
<FLHerne>
Yeah, but the intel kernel GPU driver has consistently kind of sucked at scheduling and reclocking since forever :p
<FLHerne>
[not that it's alone in that in the kernel]
<anarsoul>
jekstrand: I don't think that it's actually packed by nir_compact_varyings()
<anarsoul>
I commented out nir_compact_varyings() and it's still packed, so looks like it's done by assign_varying_locations()
<pushqrdx>
FLHerne: what should i get to have a decent Linux experience though, my nvidia card sucks on linux, and i though intel should run perfectly everywhere, ironically i had a Hackintosh installed and macOS was running in intel igpu with full acceleration no problems whatsoever
pcercuei has quit [Quit: dodo]
<pushqrdx>
yet on linux it is performing so poorly and i can't pinpoint why
<pushqrdx>
even with macOS crazy animations and blur effect everywhere, the intel igpu never dipped below 60fps
<FLHerne>
pushqrdx: clearly there's a bug, someone needs to fix it, filing a bug report is the best way to go about that
<FLHerne>
Even if someone here can come up with some workaround, it still needs fixing so other people don't hit it
fxkamd has quit []
<pushqrdx>
FLHerne: i don't even know what to report in that, it's just poor performance with modesetting/mesa but all the diagnostics i could do didn't report anything out of ordinary
<pushqrdx>
except that clock speed thing but changing clock speed minimum didn't do anything
<FLHerne>
So, report that you ran applications X and Y on your Haswell GT2 and you got sub-30 fps when you see much better on other platforms
<FLHerne>
the 'New Issue' form has a nice template to help you fill it in usefully
<FLHerne>
ideally find an application you can reproduce it with that's open-source or at least freely available so devs can try to reproduce it more easily
ybogdano has joined #dri-devel
<Kayden>
why do pipe_contexts not hold a reference on pipe_screen?
nchery has quit [Ping timeout: 480 seconds]
iive has quit []
<robclark>
Kayden: probably just that pipe_screen (at the gallium level) isn't refcnt'd? (But I'd be onboard with changing that.. at least a few drivers roll their own screen refcnt'ing)
<haagch>
pushqrdx: perhaps anything interesting in /var/log/Xorg.0.log? Also any particular reason you're using modesetting instead of the intel ddx (xf86-video-intel or xserver-xorg-video-intelhow ubuntu calls it)?
<pushqrdx>
haagch: yeah xf86-video-intel performance is even worse, with occasional stutters
Hi-Angel has quit [Ping timeout: 480 seconds]
<haagch>
very curious. well if nothing is conspicuous in the xorg log that sounds like some bug
<pushqrdx>
haagch: i have had this issue for 5 years, last time i tried to switch to linux was 5 years ago i think kernel was 4.16 or something and performance was pure garbage that i gave up
gawin has quit [Ping timeout: 480 seconds]
<pushqrdx>
and it's still is after all these updates/years, same gpu has no issue running windows or macOS 60fps, even some lightweight games run perfectly fine there
<pushqrdx>
linux though, it's stuttery, and fps is low almost as if the gpu is running 70% slower than it is on other platforms
<pushqrdx>
i even tried wayland for completeness sake and it is the same
nchery has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<Kayden>
alright, new plan
<Kayden>
going to say screw it and stop making an aux_context in the screen like radeonsi does
<Kayden>
I'm just going to create a context on the fly, do the blit, and destroy the context every time dri_query_image starts poking about asking questions about a non PIPE_BIND_SHARED resource
<Kayden>
that's bloody terrible but it ought to work and stops me from having to either rewrite all of EGL DMABUF handling, all of gallium refcounting, or all of the gallium window system code
<Kayden>
hopefully people don't call dmabuf export on buffers that aren't marked SHARED a-priori all that often
<anarsoul>
hm, is there a nir pass that lower vec3(a.x, a.y, a.z) into mov a.xyz?
<anarsoul>
ugh, I suppose it's nir_lower_vec_to_movs