<dj-death>
Kayden: or maybe it was the various layers GDM/DRI, I don't remember exactly :(
<Kayden>
dj-death: I've got a patch that deduplicates screens like freedreno does and eliminates the bufmgr refcounting and resource holding on to screen refcounts, and it still works for manywin at least
danvet has joined #dri-devel
<dj-death>
Kayden: oh you mean reusing the entire iris_screen rather than creating a new one?
<Kayden>
for now that's in the iris winsys, but anholt was suggesting that we might just want to do that in the pipe loader code so all drivers can get this without having to homebrew it badly
<Kayden>
not sure if you read back in the earlier conversation - I ran into an issue with my suballocator series where the screen needs to make a context for some misc. blit type work. but if the screen makes a context...the context makes resources...and the resources reference the screen. so you get circular refcounts and the screen is never freed at all
frieder has joined #dri-devel
<Kayden>
which is why dEQP-EGL multithread tests were blowing up...it was making 1500 screens and contexts and never freeing them
frieder has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
<dj-death>
Kayden: I guess this can work, if we refcount the screen instead of the bufmgr
<dj-death>
odd that the context is taking a ref on the screen
<airlied>
dj-death: resources take a ref
<dj-death>
ah right...
moa has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
rasterman has joined #dri-devel
tursulin has joined #dri-devel
<MrCooper>
Kayden: deduping like that requires keeping track of exported GEM handles per DRM file description (using os_same_file_description), or some things will break (see my corresponding radeonsi amdgpu winsys fixes, let me look up the MRs)
<Kayden>
I will admit that I find those parts of the amdgpu winsys code a bit hard to follow...there are quite a few layers and abstractions there. and it gets a bit hard to tell what's an essential bit of decoupling that solves the fundamental problem vs. just amdgpu/radeonsi having extra layers
<Kayden>
if the freedreno code works, it's quite a bit simpler, IMO
<Kayden>
but maybe it isn't handling some corner cases, too
<Kayden>
it wouldn't surprise me. :(
<MrCooper>
FWIW, example scenario which breaks: 1) Create EGL/GLX context 2) Open DRM file for the same physical device and create GBM device for it
<MrCooper>
1) & 2) use different DRM file descriptions, so GEM handles created for the deduped screen's DRM fd aren't valid for the fd used to create the GBM device
<MrCooper>
similar scenarios apply to more combinations of separate APIs using the same device, e.g. GL & CL/VA-API
<Kayden>
ugh...
<Kayden>
how would you end up with a dedup'd screen in that case? they shouldn't be the same fd
<pq>
empty leases to the rescue so you will never need to do dedup at all? :-)
<MrCooper>
the deduping is based on the device itself, not on file descriptions
anarsoul has quit [Read error: Connection reset by peer]
<MrCooper>
i.e. it will dedupe for different fds pointing to the same device
anarsoul has joined #dri-devel
<Kayden>
hmm...right...
<MrCooper>
different file descriptions even
tobiasjakobi has joined #dri-devel
Ahuj has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
cef has quit [Remote host closed the connection]
gpuman_ has joined #dri-devel
<Kayden>
it looks to me like freedreno is not handling that case. there's only one fd for the device, which is based on deduplication
<MrCooper>
right
gpuman has quit [Ping timeout: 480 seconds]
<Kayden>
I think iris currently is handling that case, as it has the bufmgr (winsys) shared across screens, and has a bufmgr fd and an fd for the screen
<Kayden>
or at least is trying to
<MrCooper>
I can understand wanting to avoid amdgpu's complexity, but there's no free lunch here I'm afraid
<Kayden>
right
<Kayden>
it would definitely be nice to get this into common code because every driver is hand rolling their own solution differently, and it sounds like amdgpu's is the only one that actually works in all cases
<Kayden>
and some of the ones in tree currently may not work at all
<Kayden>
but that sounds like it could be pretty painful if it means fixing up the internals of each driver's winsys/bufmgr to actually handle this stuff correctly
<MrCooper>
yeah
<MrCooper>
actually, for other drivers, just deduping based on DRM file description instead of based on device might work
camus1 has joined #dri-devel
<MrCooper>
amdgpu has to also dedup based on device for various reasons which might not apply to other drivers
<MrCooper>
(mainly that libdrm_amdgpu dedups based on device internally)
<emersion>
or you could also fix the kernel to do the ref'counting
<emersion>
and fix all the pain
<MrCooper>
that wouldn't magically make GEM handles valid for another DRM file description, would it?
<emersion>
that would remove the need for ref'counting in user-space
<MrCooper>
that's not the (main) issue here
<emersion>
and trying to figure out whether two DRM FDs refer to the same file description
<emersion>
well if the FD is different you could just assume the file descriptions are different
<emersion>
and be wrong, but it wouldn't be a big deal
<MrCooper>
you need a valid GEM handle first, no point worrying about ref'counting before that :)
<MrCooper>
k, I see
camus has quit [Ping timeout: 480 seconds]
<MrCooper>
that can only work if all parties use only the new reference counted GEM APIs though
<emersion>
yeah… we're indeed kind of stuck here
<emersion>
i've wondered about having a vendor-neutral gem handle manager in libdrm too
<emersion>
which could be used by EGL/Vulkan/VA-API/etc
<emersion>
but not sure it would help here
gpuman_ has quit []
<MrCooper>
it would need to be used by third party drivers like amdgpu-pro as well
hansg has joined #dri-devel
<emersion>
yeah
<emersion>
but that's already the case no?
<emersion>
amdgpu-pro should be using libdrm-amdgpu already right?
<emersion>
how else can amdgpu-pro interoperate with other APIs?
<MrCooper>
it uses libdrm_amdgpu, just wondering if it might use DRM_IOCTL_GEM_CLOSE separately, or if the current libdrm_amdgpu API has the current GEM handle semantics baked in
<emersion>
libdrm_amdgpu has a handle table baked it
<glennk>
robclark, 1000 hours is getting close to uint32 ms wraparound time?
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
gawin has joined #dri-devel
xexaxo has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
imre has quit [Quit: leaving]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
lemonzest has joined #dri-devel
adjtm_ has quit []
adjtm has joined #dri-devel
lunaaa has joined #dri-devel
lunaaa has left #dri-devel [#dri-devel]
Ahuj_ has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
rpigott has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
rpigott has joined #dri-devel
camus1 has joined #dri-devel
vivijim has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit []
Peste_Bubonica has joined #dri-devel
itoral has quit []
cef has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
camus has joined #dri-devel
rpigott has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
rpigott has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
<dj-death>
I'm suddenly having issues with meson not finding clang
<daniels>
dj-death: if you're on Debian, it might be because llvm-config doesn't exist in $PATH, and you need to steer it to llvm-config-$VER using a native file
<jenatali>
Then it's just a matter of unifying it into the top-level meson.build, which I wanted to do as part of merging more of Clover with the microsoft/clc code, when I eventually get around to it
<jenatali>
I might have time to work on that a bit this weekend
<karolherbst>
cool
<dj-death>
it's just the cmake method doesn't work for me
<dj-death>
not quite sure how to debug it
<karolherbst>
dj-death: do you have the clang cmake files installed as well?
<dj-death>
karolherbst: do you know what package that would be on ubuntu?
<dj-death>
clang-11 apparently
nirmoy has joined #dri-devel
<dj-death>
yeah so that's installed afaict
<karolherbst>
okay...
<karolherbst>
yeah.. weird
<karolherbst>
I wasn't running into issues yet
<dj-death>
the other method of clover is working for me though
<dj-death>
I guess I'll just carry that hack for now
<dj-death>
running the cmake command that meson is spawning appear to work too
<dj-death>
maybe a meson bug :(
<karolherbst>
maybe
rpigott has quit [Ping timeout: 480 seconds]
<karolherbst>
but what's the problem you are seeing?
Guest703 has quit []
imre has joined #dri-devel
slattann has quit []
slattann has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<dj-death>
karolherbst: ../meson.build:311:0: ERROR: Dependency "clang" not found, tried cmake
<jenatali>
dj-death: Have you checked the meson logs?
<dj-death>
karolherbst: logs are not clear, it's probably just fails cmake somehow
<dj-death>
jenatali: yeah, and like I wrote, running that cmake command on my own works
<jenatali>
Weird
<jenatali>
IIRC there's also CMake files laying around from when it tries stuff if you wanted to look at those
rpigott has joined #dri-devel
sdutt has joined #dri-devel
thellstrom has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
thellstrom has quit [Ping timeout: 480 seconds]
sukbeom has joined #dri-devel
vivijim has quit [Remote host closed the connection]
mattrope has joined #dri-devel
<dj-death>
jenatali: I can now tell that you've probably compiled that MR only with a microsoft compiler ;)
<jenatali>
Hm?
vivijim has joined #dri-devel
<jenatali>
dj-death: Which one? What's wrong?
<dj-death>
jenatali: like struct clc_binary is defined only after another struct references it by pointer
<dj-death>
jenatali: I'll share some changes later ;)
<jenatali>
dj-death: Oh, sure thing. I haven't tried building it with Clang, and I'm... not a fan of MinGW personally
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<dj-death>
come on c++
camus1 has joined #dri-devel
<dj-death>
why can't I cast "uint32_t* const" to "const char* const"
<jenatali>
reinterpret_cast can't remove const though
<jenatali>
dj-death: Out of curiosity, did you just notice MSVC-specific stuff or did I break you?
<dj-death>
jenatali: both types are const
<HdkR>
const_cast is for const casting :>
<dj-death>
jenatali: I'm just rebasing my internal branch on top of yours
<jenatali>
uint32_t* isn't const, but const char* is :)
<dj-death>
jenatali: I didn't have any specific issue with your changes, except I didn't compile them
<jenatali>
Fair enough
<jenatali>
I haven't tried to build that code for Linux (yet) just because of all the extra dependencies it needs, but I should do that at some point
rpigott has quit [Ping timeout: 480 seconds]
<Venemo>
Hey guys. Is it a known issue that mesa fails to build when you don't have bison installed? It seems the alternative program generates a header file that fails to compile.
rpigott has joined #dri-devel
mlankhorst has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
dviola has quit [Quit: WeeChat 3.2.1]
rpigott has quit [Ping timeout: 480 seconds]
<Company>
pq: 2 questions about color management:
<Company>
pq: when stuff should happen in a linear colorspace, it's always gonna be srgb linear, people won't start to disagree on whitepoints and such, right?
<Company>
pq: and do you have a meson wrap file for lcms lying around somewhere that I could steal for GTK's CI or do I have to do one myself?
sdutt has quit []
sdutt has joined #dri-devel
<HdkR>
Wonder how many people that use "TrueTone" would complain about whitepoints :D
<Company>
well, the color profiles for output can be whatever, I'm mostly thinking about what's gonna happen in software - in the vec4s in my shaders to be exact
<Company>
and from my bit of research it seems GPUs only do the sRGB <=> sRGB linear conversion automatically
<robclark>
glennk: yeah, it's getting up there.. (but I don't think "it happens one average once per 1000 hrs" == "it happens after 1000 hrs")
<ajax>
Company: if you want to switch between GLX and EGL then you need to drop the GLX context and then bind the EGL one (or vice versa)
<ajax>
if you don't like the added flushing that causes then learn to KHR_context_flush_control
<ajax>
does this make life hard for middleware? it sure does. you can fix this by using only one of the two, and as the glx maintainer, please don't pick glx.
mbrost has joined #dri-devel
thellstrom has joined #dri-devel
rpigott has joined #dri-devel
Duke`` has joined #dri-devel
nchery has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<gawin>
hi, is leoliu pephaps on IRC
<Company>
ajax: I'd have picked EGL alreaady, but until EGL on X claims to do RGBA, I can't really switch unless I do hacks
frieder has quit [Remote host closed the connection]
<Company>
but I can certainly forbid GLX when EGL is in use or vice versa
<ajax>
yes. that's !12819 and i was hoping someone else with an egl opinion would chime in
<ajax>
mmm
<Company>
so the solution is "if any EGL or GLX is in use with any backend, don't use the other"?
<agd5f>
gawin, I don't think so
<ajax>
or: use context-flush-control and unbind the backend context on the way out of the library
* Company
won't wonder what would happen if somebody decided to use EGL and WGL on Windows
<ajax>
Company: unlikely to be a thing, egl didn't have a windows binding until our local microsoft representative checked on in a few days ago
<Company>
ajax: I'm kinda tempted to not do that because of external users (read: GStreamer and friends)
<Company>
I don't think they want to think about this either
<ajax>
you don't want to use the extension that reduces the amount of implicit glFlush you do for absolutely no reason, because you think external users would be un,happy? with it being faster?
<ajax>
*shrug* not my circus, not my monkeys
<Company>
it's more about external users not doing everything properly because they don't think about EGL and GLX being around
Ahuj_ has quit [Ping timeout: 480 seconds]
join_subline has quit [Ping timeout: 480 seconds]
join_subline has joined #dri-devel
<Company>
does GLX work on MacOS or Windows on the off chance that people use X11 there?
<FLHerne>
macOS yes
<Company>
what happens if you mix Apple GL and GLX in the same process?
rpigott has quit [Ping timeout: 480 seconds]
<FLHerne>
Windows used to (for Cygwin) but I have no idea if it still does
<FLHerne>
No idea, sorry
<DrNick>
does GLX still work on Mac OS?
<ajax>
as well as it ever did
<ajax>
what happens with glx is in order to use glx you're linked against mesa's libGL.dylib, and in order to use native you're linked against OpenGL.framework
<Company>
I shall add a static global enum { NONE, WGL, EGL, GLX } gl_version_in_use; and whenever you open a new GdkDisplay, you shall not get GL if it doesn't match
<ajax>
which means: whatever the mach-o resolution rules give you at that point in execution, that's the gl you talk to.
<ajax>
similar argument for cygwin
<ajax>
they'd be completely oblivious of each other, hopefully that's what you want
<HdkR>
"you shall not get GL if it doesn't match" ???
<Company>
well, when I call glSomething(), some function somewhere has to be called
<HdkR>
Oh, new instance of GdkDisplay won't get GL if it doesn't match. okay :)
<FLHerne>
> Mesa’s default builds with the Apple GLX uses Mesa as a front for the hardware-accelerated system OpenGL framework, to provide hardware acceleration to X11 applications on macOS running via XQuartz.
<Company>
HdkR: if you have EGL initialized already and ask about GLX for a GdkDisplay, you'll get "nope, doesn't work"
<FLHerne>
> Mesa’s software rasterizers also work on macOS. To build, set the build options -Dosmesa=true -Dglx=gallium-xlib and select an appropriate Gallium software rasterizer.
<jenatali>
I've seen code in Mesa for handling GLX on Windows, but I haven't tried to use it at all
thaytan has quit [Ping timeout: 480 seconds]
<FLHerne>
tbh that doesn't really make sense to me, alyssa can presumably explain what it means
<FLHerne>
except she's not here
<HdkR>
I'm too used to people assuming EGL == GLES I guess.
<Company>
I think we should all save our brainpower
rpigott has joined #dri-devel
<Company>
because nobody is gonna try that anyway
<Company>
and if they do, they can file a bug against GTK with the error message
<jenatali>
Company: EGL + WGL should mostly work... the only thing I know won't work is trying to use the d3d12 backend and creating an EGL surface for a window where you've already done the WGL SetPixelFormat thing or vice versa
<Company>
our Windows hackers might just try that, but they can submit patches
<jenatali>
Well, the problem is the d3d12 backend tries to use DXGI swapchains whenever it can for efficiency, but you can only have one of those at a time. All the WGL contexts for a window would implicitly share one because there's no framebuffer/surface objects in WGL, but EGL explicit window surfaces would try to use their own
<jenatali>
I guess if you force all the configs to be single-buffered (which prevents DXGI swapchains) then you could do interop and it might actually all just work
<bnieuwenhuizen>
jenatali: wait you can have only one swapchain on a window at a time? I thought lots of wine issues remaining were due to apps using multiple and that apparently working
<jenatali>
bnieuwenhuizen: It's more complicated than that. Old-style swapchains used to just copy contents to the same surface that GDI writes to, which has its own set of problems, but does allow multiple swapchains to target the same window
<bnieuwenhuizen>
ah
<jenatali>
New-style swapchains completely replace the window contents with your swapchain, meaning you don't need to interop with GDI at all, which simplifies things and improves efficiency, and also means you don't have an end-of-frame surface copy
<jenatali>
But yeah, you can only have one of those, and then no GDI or old-style swapchains show up on the window anymore
<jenatali>
And D3D12 only supports the new-style swapchains
<bnieuwenhuizen>
thanks for the explanation!
<jenatali>
I know Windows stuff is off-topic for this channel, but I'm happy to explain whatever if people are curious :P
JohnnyonFlame has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
idr has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
Ahuj_ has joined #dri-devel
<anholt_>
jekstrand: care to touch-test the features/props refactor for anv? I haven't rigged up anv pre-merge ci yet.
<anholt_>
if you're happy, we can marge
<jekstrand>
anholt_: Sure. One moment.
<jekstrand>
I'll just run vulkaninfo before and after
<jekstrand>
Should be good enough
<anholt_>
yep
<jekstrand>
Looks good. Merge it.
<swick>
Company: linear light can be encoded with different color models, color spaces and whitepoints
hansg has quit [Quit: Leaving]
sukbeom has quit [Ping timeout: 480 seconds]
<graphitemaster>
Does anyone know if the NV proprietary driver or any of the Linux graphics stack for that matter deal with interrupting the GPU to keep the general system responsive? I have a compute shader that takes more than 16ms per frame and the ENTIRE system is dragged to the speed of that one shader.
<graphitemaster>
It's kind of ridiculous, this does not happen on Windows.
<jekstrand>
I would expect NV does. AMD maybe if it's running on the ROCM stack.
<jekstrand>
Generally, though, rediculously long compute shaders are painful on Linux.
<graphitemaster>
Compute shader takes 500ms, all of X renders at 2 frames per second.
<HdkR>
Ah yes, the dreaded long running compute task
<graphitemaster>
I'm kind of impressed that this is a problem. Like why isn't this being worked on?
<jekstrand>
graphitemaster: Oh, it very much is being worked on. It's just a REALLY hard problem.
<jekstrand>
Like re-plumb the entire graphics stack kind of hard.
<graphitemaster>
Just thinking about this, but WebGPU has compute shaders and you can just load one in a WebWorker in the browser tab background and completely system lock any Linux from a URL, kind of depressing.
<ajax>
we do understand the impact of the issue, yes.
<agd5f>
graphitemaster, also shaders are shared between gfx and compute
<graphitemaster>
I feel like I'm dreaming. As in I don't expect this to be a real limitation in 2021 on a platform that has some of the most active open graphics development. Am I wrong in expecting better here?
<ajax>
*shrug*
kmn has quit [Quit: Leaving.]
<jekstrand>
If you're wrong, it's in underestimating the scope of the problem.
<ajax>
from where i sit, the fact there's so much development means there's more work to do than labor to apply to it
<ajax>
so... on balance, it seems, nobody's prioritized that
<ajax>
you wanna prioritize that? go wild. we take patches.
<jekstrand>
And, also, some of literally THE BEST people we have are actively tilting at that windmill and making slow progress, at best.
<jekstrand>
And it's not because our best are incompetent compared to Windows either
<graphitemaster>
I'm just surprised. I expected there to be a lot of compute-heavy stuff running on Linux machines and interactive software that is compute-heavy too for workstation purposes. It feels like the thing someone working in VFX house (which all run some form of CentOS or RHEL) would've ran into and poured a ton of resources towards fixing.
<jekstrand>
Windows gets to cheat
<jenatali>
From my Microsoft perspective, this problem is one of the reasons Vista sucked, because we forced all the drivers in the industry to rewrite to a new model
<daniels>
graphitemaster: you're assuming that a ton of resources _aren't_ being poured into fixing this
<ajax>
graphitemaster: maybe read this as: people who want both compute and interactivity are already using nvidia's driver for other reasons
<jekstrand>
And nvidia cheats
<agd5f>
there is a lot of compute going on on Linux, but it usually not mixed with gfx
<graphitemaster>
Okay well I'm on NV's proprietary driver and it's doing the same thing >_>
<jekstrand>
Clearly, they don't cheat enough. :D
<graphitemaster>
daniels, Yes, I'm assuming. Because I'd be pretty upset if I poured a ton of money into this problem previously up to this point and the results are what they are currently, no offense.
<agd5f>
it's also more than just drivers. You need to plumb a lot of stuff through the desktop as well to make this work cleanly (OS level preemption, GPU reset handling, etc.)
<daniels>
graphitemaster: fair enough, what's your suggestion?
<MrCooper>
agd5f: shouldn't AMD GPUs be able to run graphics shaders in parallel with compute shaders though? I guess it doesn't help if the GPU is already fully occupied by long-running compute shaders...
<graphitemaster>
Is there even a design document or roadmap to tackling the problem? I'd start there.
<Sachiel>
daniels: it's plain enough, stop slacking off and fix all the problems
<daniels>
graphitemaster: yes
<bnieuwenhuizen>
MrCooper: also any fences between the two end up messing things up
<agd5f>
MrCooper, yeah, they can run concurrently, but if the CUs are full, you need to wait for them to drain unless you do something like CU masking to limit specific jobs to specific resources
<daniels>
graphitemaster: but I mean, given that you've concluded that it should've been solved by now, you understand the problem and its complexity, which means that you have a pathway to a solution if not a solution yourself, so - I'm all ears
<MrCooper>
bnieuwenhuizen: depending on a fence from such a long-standing compute shader would be kind of asking for it :)
<graphitemaster>
Pardon my ignorance, but shouldn't the kernel just you know, preempt the current GPU work when it needs to schedule other processes? Like presumably you already have the ability to preempt GPU work on account of the fact I can run multiple graphics and compute applications.
<bnieuwenhuizen>
MrCooper: memory management might introduce them unintentionally
<bnieuwenhuizen>
graphitemaster: "Like presumably you already have the ability to preempt GPU" <- not quite
<bnieuwenhuizen>
we currently mostly switch when the commandbuffer of an application is done
<agd5f>
graphitemaster, also who decides what to preempt?
<graphitemaster>
Why can't you be more aggressive / granular with that preemption.
<bnieuwenhuizen>
i.e. preemption at all is the bit that is blocking a lot of stuff and isn't really there yet
<bnieuwenhuizen>
graphitemaster: because prempting mid-commandbuffer is difficult and has implications in core kernel memory management?
ManMower has joined #dri-devel
<graphitemaster>
agd5f, That's simple, the kernel mode driver would have a list of processes that are blocked waiting on GPU work, and it would know the last time the schedule could run them and it could realistically just try to ensure that those processes got to makke forward progress every scheduling quanta (which is 16ms on Windows by default, but can be made as low as 1ms).
<graphitemaster>
bnieuwenhuizen, So it sounds like that's what needs to be worked on before anything can improve on the scheduling side.
<graphitemaster>
bnieuwenhuizen, Though, why is this not a problem for hardware interrupts?
<bnieuwenhuizen>
graphitemaster: hardware interrupts go to the CPU not GPU
<graphitemaster>
I mean't GPU hardware interrupts.
<bnieuwenhuizen>
what GPU hardware interrupts?
gouchi has joined #dri-devel
<daniels>
(DRM does have a scheduler, it does have a notion of dependencies, etc)
ngcortes has joined #dri-devel
<graphitemaster>
Heh, I never put the two and two together, GPUs are truly cooperative and don't have interrupts. I knew that but I never made the connection. Damn that's annoying. I guess all you have is MOESI/MESIF
<halfline>
don't people who rely on compute usually buy dedicated headless compute hardware?
<halfline>
i mean people aren't running tensorflow or whatever on the same graphics card they're running their desktop on right ?
<graphitemaster>
Even if they do, that's not an acceptable answer to this problem :P
<halfline>
maybe not, but i'm just saying the problem may have a more limited scope than it seems if in only affects atypical setups
<milek7>
does these problems apply for graphics shaders too?
<milek7>
I remember hanging up gpu with buggy shader, but I'm not sure if this was driver bug or just the way things work
<HdkR>
Shaders are just another GPU shader stage. You can do the same hangups with graphics stages as well
<graphitemaster>
This isn't an atypical situation, a lot of software that already exists on Windows and macOS cannot actually be ported to Linux with this limitation. Final Cut, Adobe Primer, Houdini, hell even Blender is seriously affected by this (I just checked), most video production and content creation software just straight up would make a Linux unresponsive.
<halfline>
*shrug* some of the biggest animations studios in the industry use linux workstations to make their movies. it can't be a problem affecting everyone
<graphitemaster>
I'm beginning to understand why the big software giants time their sims and slice up the work on demand based on how long it takes to avoid stalling the system. All that extra work which is apparently not necessary on Windows.
<jenatali>
Windows isn't perfect here either. Hardware can have coarse pre-emption granularities, and if your work exceeds a reasonable timeframe before hitting a pre-emption boundary, you can hit the same problem
<jenatali>
It's usually better than an entire command buffer, but pre-empting and resuming takes more time than just processing the command buffer straight through, so it's not a silver bullet on that front either
<milek7>
so VR is affected too? like there's compositor that should be able to preempt game and reproject previous frame if new one is not finished yet
<graphitemaster>
I'm beginning to feel like Linux is due for a new graphics stack rewrite.
<Sachiel>
joss, is that you?
xexaxo has quit [Ping timeout: 480 seconds]
icecream95 was kicked from #dri-devel by ChanServ [CoC violations]
tzimmermann has quit [Quit: Leaving]
<FLHerne>
too coherent
<karolherbst>
sometimes I get the feeling, that people do develop KI bots and let them run against random MLs/channels or something :/
<FLHerne>
I get that with joss, but this criticism makes sense
<anarsoul>
hm, I checked the logs and I don't see icecream95 saying anything in the past few days
<FLHerne>
They're in #panfrost, but it's all buffer allocation
<FLHerne>
I was wondering about that too, I can't think of any time they've said anything particularly non-technical never mind controversial
<FLHerne>
unless they're in some completely different channel
<jekstrand>
zmike: Dang, that was fast. :)
<jstultz>
daniels: hey, did the dmabuf cgroup session tomorrow get bumped?
<zmike>
jekstrand: I see patches I review patches
<jekstrand>
:D
unsolo has joined #dri-devel
<tlwoerner>
jstultz: it looks like 2 sessions were removed (dmabuf and cgroups) and 1 was added (memory model)
<jstultz>
tlwoerner: thanks for the confirmation! (i don't have the old schedule around anywhere, and my memory was foggy but I knew there was some dmabuf/cgroup session I was hoping to attend :)
<gawin>
someone has some time for checking 2 simple MRs? (iris, nir)
<graphitemaster>
Does async compute (as in background running compute shaders) work around my concerns at all?
jewins has joined #dri-devel
slattann has quit []
<unsolo>
Repost from #etnaviv as i have no idea how active that channel is. im trying to get a dual gpu on imx8mm working with etnaviv with the nxp 5.4.47 kernel. im able to enable one of the two (either 2d or 3d GC320 or GC600 iirc) but the kernel crashes if i enable both Either because they reset eachothers clocks or they reset eachothers power domains is my initial thoughts
nchery is now known as Guest798
nchery has joined #dri-devel
Guest798 has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
Ahuj_ has quit [Ping timeout: 480 seconds]
nirmoy has quit []
darkapex2 has joined #dri-devel
darkapex1 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
<daniels>
jstultz: unfortunately yeah, I never got any reply from anyone on the thread :\
<daniels>
jstultz: but if there's actually interest, then I could happily replace the presentation-timing stuff with that?
danvet has quit [Ping timeout: 480 seconds]
<Kayden>
anholt_: so...I've got a patch in MR !12990 to make iris do freedreno's screen deduping behavior. But...I don't know if you saw MrCooper's comments here on IRC last night? He noted several scenarios where the freedreno approach is broken, still. :(
<Kayden>
or probably broken
<Kayden>
manywin still works with that
lynxeye has quit []
JohnnyonFlame has quit [Remote host closed the connection]
<kusma>
graphitemaster: I frequently observe stalls on my Windows PC while running too slow shadertoy.com examples on my laptop. The problem isn't solved there either AFAICT.
mbrost has quit [Ping timeout: 480 seconds]
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
agners has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rbrune has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
<jstultz>
daniels: no one on the thread? hridya replied! i mean, no one really showed up to hridya's talk at the android microconf, so we were planning on trying to do follow up at that graphics session..
<jstultz>
(i thought danvet said he'd be there too)
<jstultz>
daniels: i don't necessarily want to suggest replacing a session, but it might be nice to tuck in there a bit, just so there's some interaction and sense of what the community is looking for
<jstultz>
(and in the above, "no one" isn't right. i did nudge kenny into talking at hridya's session, but other folks who we thought would be there didn't show)
mbrost has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
xexaxo has joined #dri-devel
ryanneph30 has joined #dri-devel
ryanneph30 has left #dri-devel [#dri-devel]
Duke`` has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
dviola has joined #dri-devel
mbrost has quit [Remote host closed the connection]
nchery has joined #dri-devel
jkrzyszt_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
Hi-Angel has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
rasterman has quit [Quit: Gettin' stinky!]
jewins1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<anholt_>
jekstrand: how has intel done vk conformance without dEQP-VK.wsi.display_control.register_device_event working?
<jekstrand>
We run on x/wayland
<jekstrand>
Sadly, conformance + WSI is... uh... ill-defined at best.
<bnieuwenhuizen>
IIRC previously CTS also didn't quite catch it
<jekstrand>
There's no procedure for running on all the WSIs and it's impossible to actually do a single run on all of them because having X up will prevent display because you aren't master.
fxkamd has joined #dri-devel
<anholt_>
anv_RegisterDeviceEventEXT() looks like it'll just return NOT_PRESENT, though, which would fail current cts
<jekstrand>
So I typically build with X11 and Wayland and then run in something with XWayland.
<anholt_>
so manybe it's what bnieuwenhuizen said that it's a newer test and you just didn't hit it before?
<jekstrand>
anholt_: Could be
<Sachiel>
yes, that's a fairly new test
<jekstrand>
anholt_: We also don't run those in CI
<Sachiel>
there's an MR from tpalli up for it
<jekstrand>
It should be fixed
<jekstrand>
Don't get me wrong
<bnieuwenhuizen>
yeah IIRC the "problem" with it is that that it runs even when we don't have master
<jekstrand>
But there are many many reasons why it hasn't been noticed.
<anholt_>
yeah, I mean, hard to properly automated test for sure
<anholt_>
but I was wondering if there was a way we could dodge just like anv, since I think we're down to 1 MR and one bug left in turnip for 1.1 conformance.
<jekstrand>
anholt_: I think tpalli has it implemented. I've just been stalling because I don't know udev
<bnieuwenhuizen>
I'm actually half open for just disabling the ext again
<anholt_>
but cherry-picking to an old enough cts to pass might be hard given how many cts fixes we've needed.
<Sachiel>
you could also unclaim VK_EXT_display_control for conformance
<jekstrand>
anholt_: You won't be able to run with X11/Wayland and display at the same time anyway so shut off display.
<anholt_>
jekstrand: I've looked at the MR, and it would be no better than a stub for us.
<jekstrand>
anholt_: Ah
<anholt_>
bogus device matching stuff
<anholt_>
Sachiel: that seems like a good idea.
<anholt_>
especially since the drm display stuff is pretty bogus without modifiers support
<jekstrand>
Yeah... Someone needs to make modifiers work
<jekstrand>
And then we'll have most of a compositor inside the Vulkan WSI code. (-: