lumag_ has quit [Remote host closed the connection]
lumag_ has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
Duke`` has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
hch12907 has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
hch12907 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<dolphin>
airlied: Just sent the new -fixes PR with the fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45
hch12907_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
hch12907__ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
hch12907_ has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
mbrost_ has quit []
bmodem has joined #dri-devel
aravind has joined #dri-devel
ahajda__ has joined #dri-devel
frankbinns has joined #dri-devel
<pq>
jekstrand, you could also just put the command and all the common arguments in a meson variable and use that to reduce open-coding.
bmodem has quit []
<pq>
feaneron, if you built Mesa yourself, maybe you have some kind of inconsistent build or installation of it? Or maybe your app is just scribbling over random memory? Those problems sound really weird.
tursulin has joined #dri-devel
rasterman has joined #dri-devel
hch12907 has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
coke has left #dri-devel [#dri-devel]
hch12907__ has quit [Ping timeout: 480 seconds]
flacks_ has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
<dj-death>
is there a way to validate the block dominance?
<dj-death>
looks like I run into something that invalidates it but I don't how what :)
pcercuei has joined #dri-devel
<dj-death>
arg
<dj-death>
lower_io doesn't seem to update the metadata right
<dj-death>
same with lower_subgroup
whald has joined #dri-devel
luc has joined #dri-devel
mvlad has joined #dri-devel
mvlad has quit [Ping timeout: 480 seconds]
nchery is now known as Guest991
Guest991 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
<dj-death>
danylo: am I reading the turnip code right that you're not copying u_trace tracepoints from secondary into primary command buffers?
mvlad has joined #dri-devel
enunes has quit [Read error: Connection reset by peer]
<kusma>
Is the Lima CI down right now?
enunes has joined #dri-devel
<danylo>
dj-death: Right, we don't. I wanted to say that nothing interesting happens in them, but there could be dispatches and blits, so we probably should either steal or copy the chunks depending on reusability.
<dj-death>
danylo: yep
<dj-death>
danylo: a colleague was like wtf when looking at our perfetto traces
<danylo>
=)
<dj-death>
there is work going on in the HW counters
<dj-death>
and the trace is a like a long cmd_buffer with nothing in it
<dj-death>
obviously missing bits
mszyprow has joined #dri-devel
<danylo>
dj-death: copy is easy, I think that api misses the stealing of chunks
aravind has quit [Read error: Connection reset by peer]
<tjaalton>
dcbaker: hi, looks like mesa 22.0.4 tag is missing?
rkanwal has joined #dri-devel
mclasen has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
devilhorns has joined #dri-devel
flacks_ has quit [Quit: Quitter]
flacks has joined #dri-devel
alanc has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
alanc has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
apinheiro has joined #dri-devel
hansg has joined #dri-devel
<feaneron>
pq: i did not build mesa myself, and as far as i can see, EGL operates normally when using any platform other than DRM
<feaneron>
is it expected that EGL + GBM uses kms_swrast_dri.so?
<pq>
that's the same as asking "do I expect to use llvmpipe"
<pq>
so if you expect swrast then yes, if not, no.
<feaneron>
ah so kms_swrast_dri is in fact llvmpipe? okay, that makes sense
<pq>
it has "swrast" in its name, so it must be something with software rendering
<feaneron>
thanks, i didn't know that
<pq>
since it has "kms" in its name, it probably contains some KMS spefics
<pq>
*specifics
<pq>
IOW, the name tells me that this file enables using KMS with a software rasterizer (llvmpipe, softpipe, ...)
<feaneron>
i did notice, though, that the behavior is different when opening /dev/dri/card0 and /dev/dri/renderD128. the former crashes in the glDrawArrays() calls, the latter doesn't crash but every EGL call fails.
<pq>
if your machine has a GPU with working FOSS drivers, and you don't force swrast, then I wouldn't expect kms_swrast to be used.
<pq>
feaneron, have you ran your app Valgrind yet, or similar?
<feaneron>
this is an intel kaby lake igpu, and its using the iris driver
<pq>
ok, so it very much should work
<pq>
I guess
<pq>
so, is your application a KMS client or does it connect to an actual window system?
<feaneron>
it's not a kms client (i think?), it's a video / multimedia library. what i'm trying to do with it is make it render into an offscreen surface, and export this surface through dma-buf for UIs to show a preview.
<pq>
ok. So forget about opening card0 and concentrate on using the render node.
<feaneron>
okay. i did not implement device selection yet, so i'm just hardcoding the device path for now.
<pq>
sure
luc has quit [Remote host closed the connection]
<feaneron>
i think i didn't mention, but after trying to initialize egl with the drm platform, qt kicks in and initializes another egl context for the wayland platform. this second one succeeds
<pq>
can you comment out Qt so it doesn't do that?
<pq>
just test your own code
<pq>
theoretically that shouldn't be a problem, unless the program gets confused about which context has been eglMakeCurrent()'d
<pq>
and it also doesn't affect getting lvvmpipe instead of iris
<pq>
*llvmpipe
<pq>
particularly if Qt kicks in after you already got llvmpipe
<feaneron>
yeah i mean, i can just breakpoint before qt is loaded, but all these oddities happen way before that (i'm mostly sure qt doesn't interfere with that)
<pq>
right, so Qt is likely irrelevant
<pq>
maybe write a small stand-alone test program that does exactly what you want to do in the lib and see how that behaves?
<pq>
I mean, I'm blind here, of course, and not much time to look into anything
<feaneron>
i did! yesterday i did that, and it does end up using iris_dri.so
<pq>
ok, then you have two things to compare :-)
lumag_ has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
Ntemis has joined #dri-devel
itoral has quit []
Lucretia-backup has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
bmodem has joined #dri-devel
Lucretia has quit [Ping timeout: 480 seconds]
<pq>
Why would I see stuff like "mesa: for the --simplifycfg-sink-common option: may only occur zero or one times!" printed when running Weston on AMD?
<pq>
is it safe to ignore?
<pepp>
pq: yes it's safe to ignore. And !16587 should remove these warnings.
<pq>
thanks
minecrell has quit [Read error: Connection reset by peer]
minecrell has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
eletrotupi has quit [Ping timeout: 480 seconds]
whald has quit [Remote host closed the connection]
Ntemis has quit [Read error: Connection reset by peer]
eletrotupi has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<feaneron>
interesting. the pathological case that falls back to llvmpipe doesn't link against libglapi.so.0, so the dlsym("libglapi.so.0") in dri_open_driver() (gbm_dri.c) loads it right there
<feaneron>
in addition to that, in gbm_dri.c, dri_device_create() fails the dri_screen_create() call, which falls back to dri_screen_create_sw()
<feaneron>
so it turns out that kms_swrast_dri is selected by gbm_create_device(), and not eglGetDisplay() or even eglInitialize() as i originally thought
<idr>
It looks like ir3 has the right stuff to do that lowering in NIR, but ir2 does not.
<feaneron>
aha. so, here's the odd point of failure: in gbm_dri.c, dri_screen_create_dri2() for iris_dri.so; it reaches dri_bind_extensions(), which returns true; bug inexplicably, gdb tells me dri_screen_create_dri2() returns -1 after that!
<feaneron>
so many typos in one sentence
<feaneron>
let me try again
<feaneron>
aha. so, here's the odd point of failure: in gbm_dri.c, dri_screen_create_dri2() is called for iris_dri.so; it reaches dri_bind_extensions(), which returns true; but inexplicably, gdb tells me dri_screen_create_dri2() returns -1 after that!
<HdkR>
idr: ir3, ir2 is only for a2xx
<idr>
Okay.
<idr>
HdkR: I also just noticed src/freedreno/ir3/ir3_a6xx.c. :)
<HdkR>
:)
<cwabbott>
idr: ir3 is named after a3xx, ir2 is a2xx and ir3 is a3xx and up
<idr>
I know there's a way to get at the actual output from the failing test in CI... but I can never remember the right incantation.
<idr>
Where does that output live?
<idr>
Hm... that same test also fails on zink. That's puzzling.
<idr>
pepp: I did. It's been long enough that I don't remember many of the details. Most of that stuff... I just beat on with a hammer until the tests passed.
<idr>
There was another issue opened somewhere that some of the orderings may be incorrect.
<idr>
I only have a half day today, so I'll have to dig into it on Monday.
<idr>
(And you might have to remind me.) :)
<pepp>
ok :)
<idr>
zmike: Yeah... I can reproduce it with the hack to force zink to always enable sparse.
<idr>
I'm very confused that this is a segfault in GLSL IR code. What the heck?
<zmike>
yeah baffling
<idr>
And it's in glsl_to_nir too.
<idr>
I'm doubly surprised that iris doesn't hit this.
<zmike>
you have to run zink if you want the good crashes
<zmike>
that's just a fact
<idr>
Lol
<idr>
Here's some irony... jekstrand just removed some assert(this != NULL) because the compiler says that's impossible, but this crash is, literally, this == NULL.
<zmike>
I was getting annoying compiler warns about that lately too
<idr>
(It's possible those cases were virtual functions where this == NULL should be impossible.)
<daniels>
C++: not even once
rgallaispou has quit [Read error: Connection reset by peer]
<idr>
Hm... it seems the offsets array is not marked as constant here.
<idr>
FFS
<jekstrand>
idr: Oh, the irony!
<jekstrand>
idr: I knew hit was hittable in real life
<jekstrand>
idr: If you want to figure how how to revert that and keep GCC12 happy, I'm all for it.
<idr>
Naw. A sig11 as soon as you do anything is pretty much the same as an assertion.
<jekstrand>
:)
<jekstrand>
That's kinda what I thought
kts has quit [Quit: Konversation terminated!]
hch12907_ has joined #dri-devel
<jekstrand>
bnieuwenhuizen: I kinda want to tell venus "use common framework or stop using WSI". :-/
<bnieuwenhuizen>
jekstrand: yeah ...
<bnieuwenhuizen>
in any case it makes sense for venus to set a flag "I'
<bnieuwenhuizen>
I'm special" rather than all other drivers doing stuff
<idr>
zmike: Something derpy is happening. The test definitely declares the offsets array as 'const ivec2[] offsets = ...'
<zmike>
idr: does sound derpy indeed
<jekstrand>
bnieuwenhuizen: Yeah. Let's go with that for now. Being able to use vk_sync is so much cleaner than piles of callbacks.
<bnieuwenhuizen>
yeah
<bnieuwenhuizen>
it'll safe us some work in the present case as well, as exporting a sync file from a fence resets the fence ...
<bnieuwenhuizen>
(while it doesn't for the vk_sync)
<idr>
It gets into glsl_to_nir as a variable dereference, so perhaps glsl_to_nir is (implicitly) depending on some copy or constant propagation having happened.
<daniels>
jekstrand: context?
<idr>
Which some drivers happen to do and others don't. :(
<jekstrand>
bnieuwenhuizen: Hrm... I hadn't thought of just re-using the fence! I don't need to add that semaphore. Woohoo!
<jekstrand>
Meh. Adding the semaphore is no big deal, I guess.
hch12907 has quit [Ping timeout: 480 seconds]
<daniels>
jekstrand: hmm there is some WIP work I've seen that should make that possible
lumag_ has joined #dri-devel
<jekstrand>
bnieuwenhuizen: Actually, I've got one better. Venus can just never pass the semaphores into ANI
<bnieuwenhuizen>
for the ANI case yes. I'd imagine that gets harder for present
<bnieuwenhuizen>
though I guess the code we're discussing is only ANI yet
<jekstrand>
bnieuwenhuizen: Present will handle itself because the first thing we check for is vk_sync support for exporting sync_file
<jekstrand>
Or, at any rate, I can check for vk_sync support and bail if we don't have it
<dcbaker>
tjaalton: yup, it didn't get pushed (me has been tweaking the release scripts) it's pushed now, thanks!
<feaneron>
there's something i don't fully understand here. when calling gbm_create_device(), dri_screen_create_dri2() checks "if (dri->dri2 == NULL) return -1;". however, there only seem to have 2 places where dri->dri2 is set are by EGL's dri2_initialize_drm(), and src/glx/dri2_glx.c, none of which could possibly have been called at this point
tursulin has quit [Ping timeout: 480 seconds]
<idr>
zmike: I've updated the bug with my findings. I've only got a couple hours left today, so you might have to take over. ;)
<zmike>
idr: I'm actually about to clock out for the week once I queue up another cts run and flush my patch queue, so we might have to leave it for next week
<idr>
Boo. Okay.
<zmike>
yeah...
kts has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
Duke`` has joined #dri-devel
devilhorns has quit []
hch12907__ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<HdkR>
Is there a known depdendency tracking issue in the broadcom generated file `cle/v3d_packet_v41_pack.h`?
<HdkR>
Had a build failure on 22.1 which seemed like a race.
<jekstrand>
bnieuwenhuizen: Ok, updated. I now check vk_physical_device::supported_sync_types in the ANI calls.
<jekstrand>
bnieuwenhuizen: For the QueuePresent case, things are a bit more layery. That seemed easier than asserting I'm doing all the right things manually.
* feaneron
gives up, this is not meant to work apparently
hch12907_ has quit [Ping timeout: 480 seconds]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
hch12907__ has quit [Ping timeout: 480 seconds]
hch12907__ has joined #dri-devel
<tjaalton>
dcbaker: thanks!
<tjaalton>
dcbaker: or is it, I still can't see it :)
<dcbaker>
tjaalton: it is now. I pushed it to my repo instead of upstream 🤦
<tjaalton>
hah
<tjaalton>
yep, works now
mbrost has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
Terman has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
I feel really silly asking, but with util/list.h, is there a nice way to get the previous element if it exists?
<feaneron>
i spent 2 days to figure out 2 characters, i'm an idiot
mszyprow has quit [Ping timeout: 480 seconds]
hch12907_ has joined #dri-devel
Lyude has quit [Quit: WeeChat 3.4]
hch12907__ has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
iive has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
ds` has quit [Quit: ...]
ds` has joined #dri-devel
idr has quit [Quit: Leaving]
bbrezillon has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
linearcannon has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
hch12907__ has joined #dri-devel
linearcannon has joined #dri-devel
hch12907_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
oneforall2 has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<jekstrand>
dj-death: I'd like your review on !4037 (WSI with dma-buf import/export) as well before I tell danvet and/or König to merge the kernel patches
<jekstrand>
And bnieuwenhuizen
camus has joined #dri-devel
<dj-death>
jekstrand: okay, will do
lumag_ has quit [Remote host closed the connection]
lumag_ has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Lyude has joined #dri-devel
mclasen has joined #dri-devel
hch12907__ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Read error: Connection reset by peer]
agd5f_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Read error: Connection reset by peer]
agd5f_ has joined #dri-devel
<jekstrand>
bnieuwenhuizen: What's up with radv_meta_restore_subpass?
<jekstrand>
It seems like it's an attempt at a lighter-weight subpass save
<jekstrand>
Not sure it actually is in practice
<jekstrand>
Seems pretty intertwined with mark_noncoherent_fb
<jekstrand>
rb, rather
<jekstrand>
Yeah, I'm going to need a RADV guide if I'm going to mess with this. :-/
<jekstrand>
Hrm... mark_noncoherent_fb seems like something that needs to be called after rendering. Ok, I can do that, I think.
<bnieuwenhuizen>
jekstrand: yeah, restore_subpass is purely for including that extra function, not for really restoring something that was saved
mclasen has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
goal of the noncoherent_fb stuff is to mark stuff that is rendered to that isn't L2 coherent
<bnieuwenhuizen>
could do it in a barrier, except too many people use barriers without specifying the images/buffers
<jekstrand>
bnieuwenhuizen: RIght
<jekstrand>
bnieuwenhuizen: I'd like to get rid of restore_subpass if possible. It doesn't really make sense in a dynamic rendering world.
<jekstrand>
Not sure what to replace set_subpass with. 🤔
<jekstrand>
Really, it should all be Begin/EndRendering
technopoirot has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
I think we need the ability to suspend and resume the renderpass (which we have with dynamic rendering, but the trick is saving the command arguments)
<jekstrand>
That's not hard. I've got a radv_rendering_state struct you can just copy by value into the meta state
<bnieuwenhuizen>
ok, so what is the issue?
<bnieuwenhuizen>
set_subpass would just be BeginRendering (+ EndRendering if needed)
<jekstrand>
I'm trying to understand why the current light-weight thing exists so I don't break the univers when I replace it. 😂
<bnieuwenhuizen>
lightweight thing exists so we don't need to deal with extra attachment arrays
<jekstrand>
I'm gonna go with that and see if I break the universe. :)
<bnieuwenhuizen>
since all the attachments are already in there
<bnieuwenhuizen>
nothing else
Lyude has quit [Read error: Connection reset by peer]
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
Lyude has joined #dri-devel
<bnieuwenhuizen>
(you'll note set_subpass does basically no transition stuff, it only sets the subpass ptr that is used for other commands, most importantly emitting the framebuffer state to the HW
<bnieuwenhuizen>
might be less of a need now since with dynamic rendering renderpasses are very bounded in the number of attachments they can reference
ahajda__ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
<jekstrand>
Yeah, Begin/EndRendering is a bit more verbose but fine, I think.
<jekstrand>
bnieuwenhuizen: Is it just me or does the RADV resolve code ignore the render area?
<jekstrand>
That seems wrong
<bnieuwenhuizen>
looks like it
rasterman has joined #dri-devel
ahajda__ has joined #dri-devel
rkanwal1 has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
rkanwal has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<jekstrand>
Ugh... stupid render class resolve attachment clears. Good thing that's fixed in the new code. Gotta keep it working, though.
e|oon has joined #dri-devel
mszyprow has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
jeeeun84 has quit []
jeeeun84 has joined #dri-devel
unerlige1 has quit [Read error: Connection reset by peer]
unerlige2 has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
icecream95 has joined #dri-devel
mszyprow has joined #dri-devel
lumag_ has quit [Remote host closed the connection]
mvlad has quit [Quit: Leaving]
lumag_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
technopoirot has joined #dri-devel
ahajda__ has quit []
Haaninjo has quit [Quit: Ex-Chat]
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
icecream95 has quit [Quit: rcirc on GNU Emacs 28.1]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]