everfree has quit [Remote host closed the connection]
<emersion>
vulkan doesn't have packed 16-bit formats?
<emersion>
it seems like no vulkan format matches the DRM 16-bit fourccs?
everfree has joined #dri-devel
<airlied>
Lynne: that I'm not sure about, I think radv is fine with just one image view
<airlied>
as long as the slot index is fine, the spec seems a bit vague there
<emersion>
nevermind, i got confused about LE/BE again
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
gawin has joined #dri-devel
<Lynne>
airlied: I'm guessing the same imageview of refs is passed to VkVideoPictureResourceInfoKHR for all refs, but with a different base layer == the dpb slot #
<airlied>
yeah baseLayer = dpb slot seems right
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
rmckeever has quit [Quit: Leaving]
yuq825 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
guru_ has joined #dri-devel
bluebugs has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
mhenning has joined #dri-devel
camus has joined #dri-devel
<Lynne>
airlied: well, no
<Lynne>
"The Vulkan spec states: If viewType is VK_IMAGE_VIEW_TYPE_1D, VK_IMAGE_VIEW_TYPE_2D, or VK_IMAGE_VIEW_TYPE_3D; and subresourceRange.layerCount is VK_REMAINING_ARRAY_LAYERS, then the remaining number of layers must be 1"
<Lynne>
implicitly using layerCount = 17 results in the same error, only one layer per imageview is permitted
<Lynne>
bit disappointed, have to delete a lot of code
<airlied>
ah does viewtype have to be 2D
<airlied>
though you could have a 2D_ARRAY viewtype
<airlied>
but I think for it to make sense it probably needs an image view per layer anyways
<airlied>
since you would have an image view per DPB anyways
<Lynne>
I'm *really* not seeing how this abstraction helps
<Lynne>
the driver is very free to allocate all video images as it pleases, no reason to expose it
heat has joined #dri-devel
<Lynne>
could be a separate memorytype with enough memory for the maximum number of supported frame references
heat_ has quit [Read error: Connection reset by peer]
<airlied>
at one point I think it was some magic image type called opaque
<airlied>
but really vulkan is all about being explicit here
<Lynne>
what for, alien hardware with cheaper build quality than ours?
<airlied>
I can only assume someone will build worse hw, video decode engines seem to be the less cared for parts of gpu
<Lynne>
it works!!1
<Lynne>
everything's decoded fine
<Lynne>
ah, or not
<Lynne>
still desyncs, but it takes longer
<airlied>
at long as we are in the same place as before distinct or close enough
<airlied>
I'm really not sure why we get a desync at frame 3, I'm trying to compare the vaapi decode, and it's mostly feeding the hw the same thing
alyssa has left #dri-devel [#dri-devel]
<Lynne>
oh damn and blast, it was just uninitialized memory making it look better, I think, back to the same spot as before
<Lynne>
updated my branch, now has layered support, you can remove that piece of code you were talking about erlier
Akari has quit [Quit: segmentation fault (core dumped)]
<Lynne>
had the wrong layer selected, fixed
<Lynne>
(still not sure if pic->pic_id is the right layer index)
<Lynne>
the fact that changing the ref indices hardly changes the output is very suspicious
<Lynne>
like they're not even being respected
lanodan_ has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
* airlied
is still getting all bad decodes with head of both branches, I'll hunt it down
lanodan has joined #dri-devel
cef has quit [Quit: Zoom!]
<Lynne>
I'll go over all the SPS/PPS changes, maybe I made a mistake updating for the newest headers
<Lynne>
...where the previously-hardly-readable SPS/PPS struct names became downright passwords
<airlied>
Lynne: I've compared the vaapi params being passed in the hw h264 msg and they look the same
<Lynne>
including SPS and PPS structs?
<Lynne>
or just the indices
<airlied>
the values we pull out of them
<airlied>
there is a function called get_h264_msg in radv_video.c that extracts all the hw packet
<Lynne>
odd
<Lynne>
I found 1 typo in the PPS ID, but it didn't change anything, updated repo
* airlied
is seeing similiar problems to something not being tiled as yesterday
<airlied>
but I forget what that was
<Lynne>
different modifier picked for DPBs?
<airlied>
I think missing image usage flagss
<airlied>
don't see DECODE being set
<Lynne>
IT WAS!
<Lynne>
...not, uninitialized memory made it look good for a moment
<Lynne>
but it was a good catch, the output images should have DECODE_DST set even for out-of-place decoding
<Lynne>
branch updated
<Lynne>
could it be a race condition?
<Lynne>
where the previous frame hasn't been decoded yet to be used as a ref?
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost has quit []
lemonzest has quit [Quit: WeeChat 3.6]
<airlied>
Lynne: yeah that might be possible I'm not really sure how the hw syncs
<airlied>
Lynne: yay same as yesterday jellyfish are back
<airlied>
Lynne: is is possible this is a B frame looking for a future frame we hadn't decoded yet and reading the frame back too soon?
ahajda has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
<airlied>
Lynne: though that question might just show I've no idea about h264 :-P
junaid has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
fab has joined #dri-devel
rasterman has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
tursulin has joined #dri-devel
junaid has joined #dri-devel
vliaskov has joined #dri-devel
linusw has joined #dri-devel
jkrzyszt has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
gio has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
dcz_ has joined #dri-devel
rgallaispou has joined #dri-devel
lynxeye has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
<javierm>
danvet: while reviewing mripard's kunit for vc4 series, I wondered about EXPORT_SYMBOL() vs EXPORT_SYMBOL_GPL(). What's the policy in DRM to decide what symbols should be exported with the later?
<danvet>
toss a coin
<danvet>
like, this is kinda a bikeshed I don't really want to get into ...
<javierm>
fair :)
<javierm>
danvet: Ok
<danvet>
what we probably shouldn't do is do a minimal wrapper to get rid of _GPL
<danvet>
and maybe if everything else in that area is _GPL, follow suit
<danvet>
kinda like with coding style
<danvet>
beyond that it goes from 90% bikeshed to 100% bikeshed imo
<javierm>
danvet: gotcha
<danvet>
there's some core kernel stuff where this becomes the rule (i.e. no wrapper to drop the _GPL)
kxkamil has quit []
<danvet>
like if you'd make drm_mmu_notifier which aren't _GPL so that nvidia.ko blob can use it :-)
<javierm>
danvet: yeah, the no wrapper to drop _GPL I understand, and I remember some companies did that
<danvet>
that would piss off a pile of core kernel maintainers
<javierm>
danvet: this was mostly about the kunit helpers for DRM, do we want to restrict that to only GPL drivers or also allow out-of-tree drivers to use it
<javierm>
but yeah, no need to bikeshed then
JohnnyonF has joined #dri-devel
<danvet>
javierm, well _GPL still allows out-of-tree
<danvet>
it's only about the license
lynxeye has joined #dri-devel
<danvet>
so you can mark _GPL very liberally if you feel like
<danvet>
or not, if you don't feel like
lynxeye has quit [Remote host closed the connection]
<javierm>
danvet: yes, I meant s/out-of-tree/proprietary really
<danvet>
also with nvidia moving I don't think we actually have any blob driver left
<danvet>
for gpus at least
<mriesch>
what connector/encoder type should a driver for a 16/18/24bit rgb output have? is LVDS suitable? or DPI?
<danvet>
mriesch, toss a coin
* danvet
founda favorite new answer
<danvet>
userspace treats both as "integrated panel" so there's no difference really
<javierm>
danvet: haha, I like that answer
<mriesch>
danvet: my preferred answer :-) so it does not matter too much
lynxeye has joined #dri-devel
<mriesch>
(it is the existing rockchip_rgb driver and i was wondering why it was set to LVDS)
<mriesch>
thanks
<danvet>
oh if it's existing, then it's uapi and better not change it
<danvet>
since people can hardcode their display config
<danvet>
and often use connector names for that
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<mriesch>
danvet: ack!
pcercuei has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<mripard>
mriesch: That would be DPI I guess, but yeah, you can't change it
<mriesch>
mripard: c'est la vie! thanks anyway
kxkamil has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
<mripard>
danvet: javierm: I guess we'll have to change it then, drm_kunit_helper_alloc_device is basically allocating a device using platform_device functions, and those are using EXPORT_SYMBOL_GPL
<javierm>
mripard: yeah, that was my thinking as well. But didn't want to bikesheed because danvet said that want to have this discussion :)
<javierm>
*didn't want to
itoral__ has joined #dri-devel
<mripard>
not pissing off anyone and avoiding any flamewar over this is the less bikesheddy option I think :)
JohnnyonFlame has joined #dri-devel
<javierm>
mripard: agree :)
<mripard>
especially since I don't care, really
<mripard>
thanks for pointing that out
JohnnyonF has quit [Ping timeout: 480 seconds]
itoral_ has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<javierm>
mripard: I think that reviewed now all the patches from the series that were missing a r-b. I didn't review the ones that mairacanal already did
<javierm>
if you think that there's something missing, please let me know
<javierm>
mripard: it really is an amazing patch-set IMO :)
YuGiOhJCJ has joined #dri-devel
<mripard>
thanks :)
apinheiro has joined #dri-devel
<mripard>
I'm not super happy with the device allocation stuff and am feeling a bit uncomfortable merging this without gkh acked-by
<javierm>
mripard: I think is much better now without the wait queue
dschuermann_ has quit []
dschuermann has joined #dri-devel
Akari has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
jkrzyszt has joined #dri-devel
<kusma>
Hmm, I'm getting a complaint about interp_deref_at_sample being an unimplemented intrinsic from ACO, but RADV reports the sampleRateShading feature...
<kusma>
Seems like RADV doesn't call nir_lower_interpolation(), how is things supposed to work at all? And does the CTS not test these things?
<kusma>
Or is that not the right lowering pass? I can't tell :P
junaid has joined #dri-devel
<karolherbst>
airlied: is there something like a prefered workgroup size multiple in llvmpipe? Like for this CPU we want 16/32/48 or 32/64/92 threads?
itoral__ has quit []
junaid has quit [Ping timeout: 480 seconds]
cef has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
paulk-bis has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
gawin has joined #dri-devel
<gawin>
apinheiro: dj-death: on shader-db repo system of rebasing commits (to add ab/rb) still works?
<apinheiro>
gawin, do you mean adding the ab/rb labels to the commits?
<gawin>
yeah
<apinheiro>
yes, I think so
<apinheiro>
some mesa drivers are not requiring that anymore
<apinheiro>
but not sure about shader-db
jkrzyszt has joined #dri-devel
<apinheiro>
I think that until it is discussed specifically for shader-db
<apinheiro>
it is better to continue with the policy
YuGiOhJCJ has quit [Remote host closed the connection]
<apinheiro>
but I guess that's not a big deal if they are not added
YuGiOhJCJ has joined #dri-devel
<apinheiro>
will let others give their opinion (and after all, I personally only contributed to shader-db with some patches now and then)
<gawin>
done
<gawin>
asking now, because I always end with forgotten MRs
<dj-death>
not sure what we should do with shader-db
paulk-bis has quit []
paulk has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
paulk has joined #dri-devel
rgallaispou has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<pendingchaos>
kusma: nir_lower_io() lowers that
<pendingchaos>
nir_lower_interpolation() seems to be something different
<kusma>
Seems like maybe not always?
<kusma>
Or, in my case at least
<pendingchaos>
should be always
<pendingchaos>
maybe you're inserting the instruction after the lowering pass
<kusma>
The shader (from zink) contains the spirv instruction.
<kusma>
It's just not getting lowered.
<kusma>
I'll debug it tomorrow
<kusma>
Thanks for the pointer
jkrzyszt has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
djbw has quit [Read error: Connection reset by peer]
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
<daniels>
any objections to adding sergi as a developer to Mesa? he's one of our CI people (who's mostly been working on other repos e.g. virglrenderer/gfx-ci/etc), and would be good to have them there so he can do LAVA maintenance things as appropriate
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
thaytan has quit [Ping timeout: 480 seconds]
<MrCooper>
no objections from me
orbea has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<Lynne>
airlied: no, this happens on simple P-frames too
Net147 has quit [Ping timeout: 480 seconds]
<Lynne>
counter-question, is it possible the hardware somehow assumes all refs are available and uses them?
<Lynne>
rather than just the number signalled?
yuq825 has left #dri-devel [#dri-devel]
thaytan has joined #dri-devel
fxkamd has joined #dri-devel
camus has quit [Remote host closed the connection]
Guest376 is now known as DemiMarie
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<mareko>
does zink work without a native GL driver?
<MrCooper>
yes
<MrCooper>
why wouldn't it?
<MrCooper>
it doesn't get used automatically yet in that case though, nobody's figured out how to do that without breaking the fallback to swrast in some cases
lina_ has joined #dri-devel
lina has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yogesh_mohan has joined #dri-devel
Company has joined #dri-devel
<mareko>
so I just have to export MESA_LOADER_DRIVER_OVERRIDE globally?
<mareko>
danvet: FYI, if a GPU reset happens and a GL context is not robust, mesa/radeonsi calls exit(1) to kill the app. That's because our contexts are not recoverable from the driver. Apps must enable robustness and recreate the context and resources themselves.
shashanks has joined #dri-devel
fxkamd has quit []
<danvet>
mareko, and that happens for everything when you have vram_lost?
<danvet>
*every gpu ctx
kts has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<mareko>
danvet: actually we only do that if a CS ioctl is rejected and isn't re-tried, not for a GPU reset, but that is planned to be added
<mareko>
-ENOMEM is retried, but anything else will kill the app if the context is not robust
Net147 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
<mareko>
danvet: the VRAM lost thing doesn't matter; even when VRAM is not lost, it's not recoverable
<MrCooper>
mareko: yep, MESA_LOADER_DRIVER_OVERRIDE=zink should do the trick
<mareko>
MrCooper: thanks
<MrCooper>
np
kts has quit [Quit: Leaving]
kts has joined #dri-devel
Duke`` has joined #dri-devel
frieder has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<danvet>
mareko, what goes boom? I mean aside from all the intermediate rendering, so depending upon app there'll be corruption
<mareko>
danvet: memory-based synchronization right now, GPU-generated work in the future
<mareko>
also if we upload shaders via a copy engine, skipping that copy can go boom
<danvet>
hm right, and yeah the more complex gpu the less this is really an option
<danvet>
compositors just need to enable arb robustness or vk
<mareko>
there is a memory-based synchronization between task and mesh shaders right now, GPU-generated work will be similar
<mareko>
draw indirect is another one - if the vertex count is not written by the GPU, it can be random and drawing UINT_MAX vertices will certainly look like a hang
<mareko>
and the list goes on
MajorBiscuit has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
yogesh_mohan has quit [Quit: WeeChat 2.3]
jkrzyszt has quit [Ping timeout: 480 seconds]
cheako has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<mareko>
MrCooper: doesn't the X server need some changes to make zink work? not using Xwayland
fab has joined #dri-devel
djbw has joined #dri-devel
ybogdano has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
dwlsalmeida has joined #dri-devel
kts has quit [Quit: Leaving]
mhenning has joined #dri-devel
<daniels>
am aware of a lot of CI timeouts today and have an MR in flight to fix
tursulin has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
jfalempe_ has joined #dri-devel
jfalempe__ has quit [Read error: Connection reset by peer]
<airlied>
Lynne: i always tell the hw max refs, but it should have them all in the dpb
<airlied>
since i ignore the image view
apinheiro has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: not really sure it matters, is it equiv to grid or block?
<karolherbst>
airlied: block
<karolherbst>
by default I'll use the subgroup size anyway
<airlied>
subgroup is fine
OftenTimeConsuming has quit [Remote host closed the connection]
<airlied>
with avx2 we have 8 lanes
<karolherbst>
this only gets weird for hardware having different SIMD sizes, like AMD or Intel do
OftenTimeConsuming has joined #dri-devel
<jekstrand>
Venemo: Were you going to look at the last couple patches in !20067?
<karolherbst>
airlied: anyway, it's for !19855
<Venemo>
jekstrand: I was going to, but I saw they already have reviews so I think I'm fine with that
<Venemo>
I trust the people who already reviewed them
nchery_ has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
nchery is now known as Guest469
nchery_ is now known as nchery
<airlied>
karolherbst: just use subgroup default
<karolherbst>
yeah.. I was wondering to do that for all drivers and remove the new flag after all, but mostly wanted to have some feedback first
<eric_engestrom>
it's the only thing blocking the release right now, and since there hasn't been any activity that I can see, I'm inclined to think waiting probably won't help
apinheiro has joined #dri-devel
<Lynne>
airlied: each ref has a flag to indicate whether it's enabled or not
<Lynne>
I presume it's there in case of missed refs
<Lynne>
maybe it's not being relayed properly?
<Lynne>
we set the flag to always present, since ffmpeg will create a blank ref if there's one missing
<airlied>
Lynne: btw i tried not reporting any ref poc and stuff to the hw and got the same results
pcercuei has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: WeeChat 3.6]
<airlied>
which is strange
pcercuei has joined #dri-devel
Guest469 has quit [Ping timeout: 480 seconds]
<Lynne>
I messed around with the ref indices and it got worse, so I'm confident they're correct
<Lynne>
but IIRC turning them off didn't make it worse?
<Lynne>
which is indeed very strange
<Lynne>
maybe the hardware simply doesn't write anything in to the DPB refs?
Akari has joined #dri-devel
Guest470 has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: i think im at the try and dump all the buffers stage
junaid has quit [Remote host closed the connection]
gitautas has joined #dri-devel
gitautas has left #dri-devel [#dri-devel]
gitautas has joined #dri-devel
<gitautas>
Hey everyone. I was wondering if there was an example of how to get access to a DRM framebuffer from userspace? I want to map the framebuffer to an OpenGL texture and pass it to a hardware encoder, is there any way to do this using normal kernel APIs? Thanks!
<daniels>
gitautas: the answer to that question is usually to take a step back and figure out how to do proper capture from whatever app you're using that's driving DRM
<gitautas>
Well. I want to specifically access the framebuffer to avoid copying from VRAM. I know there are vendor specific SDKs but I was hoping to utilize kernel APIs.
<gitautas>
There is a way to do this on NV GPUs using FBC and AMD seems to have a similar feature in AMF, but since I intend to support both vendors I'd like to have the most general approach I can get without sacrificing any additional latency. This is a very latency sensitive use case.
<gitautas>
And I really just want to capture the output of the X/Wayland session entirely.
<daniels>
that will get the output from the compositor you're using, which can do it in an equally efficient zerocopy way
<dwlsalmeida>
airlied Lynne Hi there :) I am trying to fix a couple of things with the VA state tracker. I noticed that vaQuerySurfaceStatus is unimplemented for decode basically and that vaSyncSurface does not block as VA-API says it should. I wonder if there's anything I can block on on the AMD side of things to signal completion?
<gitautas>
daniels: Would that truly be as efficient as directly reading the framebuffer? I remember looking into this when doing R&D on this personal project and it seemed to be a pretty abstracted way to go about this.
gio has joined #dri-devel
<dwlsalmeida>
airlied Lynne on Intel they eventually call DRM_IOCTL_I915_GEM_WAIT, but I am new in gfx so just want to make sure this is also possible on amdgpu, for instance
<anholt>
gitautas: protocols to do this exist because of all the complexities you're not considering when you talk about "the framebuffer" is if that means one hunk of memory you could go look at and see what's on the screen.
<daniels>
yeah, and the compositor _is_ the thing which produces 'the framebuffer', and it can hand it off to you in a way which allows everyone to consume it the most efficient way, also without artifacts or tearing
<daniels>
I understand the attraction of going for KMS as the lowest-level thing, but it's really not what you want
<gitautas>
So I wouldn't be able to reduce latency in the system if I was going directly to libdrm then? I'll look into the xdg-portal again, I remember putting it off for one reason or another.
<anholt>
dwlsalmeida: if you're inside the va state tracker in Mesa, then you're going to want to generate a fence after whatever rendering you might want to wait on, and then wait on that fence in your blocking function.
<daniels>
nope, compared to the portal you'd only increase latency, and you'd make a bunch of other things strictly worse
<daniels>
dwlsalmeida: yep, when you do a CS for your decode batch, you want the kernel to return you a fence/syncobj that you can then wait for completion on
<gitautas>
Interesting. I'll set up some benchmarks between xdg-portal and the vendor SDKs and compare then.
<airlied>
dwlsalmeida: yeah I think you can just wait on idle for the queue
<airlied>
or use fences
OftenTimeConsuming has quit [Remote host closed the connection]
<airlied>
the video decode queues can't do userspace fences due to how limitations
OftenTimeConsuming has joined #dri-devel
<dwlsalmeida>
hmm..I see that in radeon_vcn_dec.c:flush(), dec->ws->cs_flush() optionally takes a fence, so I think that's what you guys are referring to? -> Pointer to a fence. If non-NULL, a fence is inserted after the CS and is returned through this parameter.
<dwlsalmeida>
so on vaSyncSurface, I'd have to wait on this fence I would pass in cs_flush()
<dwlsalmeida>
and on vaQuerySurfaceState I'd have to check whether this fence was signaled?
<airlied>
dwlsalmeida: yes you'd need to pass that fence around properly
<airlied>
you probably have to stash is somewhere appropriatel
<airlied>
like either a last fence or a fence per frame
<dwlsalmeida>
I noticed that this struct exists -> struct rvcn_dec_feedback_header_s
<dwlsalmeida>
there's this field inside -> unsigned int status;
gouchi has joined #dri-devel
<dwlsalmeida>
this hasn't been mentioned now, so I assume I can ignore this and instead use the fence approach you've just suggested?
<airlied>
if you just want to know something is finished yes
<airlied>
if you want a status value from the hw then you need to read that somehow
<dwlsalmeida>
ok that's more than enough to get started
<dwlsalmeida>
thanks a lot!
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<daniels>
dwlsalmeida: yep, the fence you get back is like a completion object in the kernel - it will signal when the work itself becomes complete, rather than having to poll on the status field
<dwlsalmeida>
one more thing, this async business -> PIPE_FLUSH_ASYNC = (1 << 3),
<dwlsalmeida>
should I worry about that?
<anholt>
dwlsalmeida: if your fence wait will only happen from the same pipe_context as the drawing did, then use PIPE_FLUSH_DEFERRED
<Lynne>
airlied: dump 'em, worst case, we discover GPUs have become self-aware and are allergic to vulkan
lynxeye has quit [Quit: Leaving.]
JohnnyonF has joined #dri-devel
CounterPillow has quit [Quit: Bye.]
Jeremy_Rand_Talos_ has joined #dri-devel
CounterPillow has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
CounterPillow has quit [Read error: Connection reset by peer]
Leopold_ has joined #dri-devel
Leopold_ has quit []
CounterPillow has joined #dri-devel
<ajax>
mareko: if xserver is using the dri loader(s), zink is not expected to work
junaid has joined #dri-devel
<ajax>
mareko: if xserver is using the egl loader, and egl is set up to pick zink, that should work at least for Xwayland iirc
<ajax>
idk if the egl loader patches to Xorg would also make that work
apinheiro has quit [Ping timeout: 480 seconds]
<jekstrand>
Is marge down?
<jekstrand>
Nah, still doing things as of 20m ago
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
nchery has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
<ajax>
correction to that first statement: zink will work _on the client side_ in such a setup. but you can't use it as the (dri) driver xserver uses to set up glx
nchery has joined #dri-devel
<airlied>
ajax: that would be a good thing to fix
* airlied
also wonders about a future where we have a named driver that is just zink under the hood, so zink isn't a fallback
<ajax>
yes, everything should move to the egl loader.
dcz_ has quit [Ping timeout: 480 seconds]
<airlied>
so if we have a platform where zink is definitely the only option, we can call that out
<airlied>
ajax: ah I misread which statement you corrected :-P
Leopold_ has joined #dri-devel
junaid has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
h0tc0d3 has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
junaid has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
h0tc0d3 has quit []
gitautas has quit [Quit: Page closed]
ybogdano has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
gouchi has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
ybogdano has quit [Quit: Ping timeout (120 seconds)]
ybogdano has joined #dri-devel
Leopold_ has quit []
Duke`` has quit [Ping timeout: 480 seconds]
<glehmann>
something is wrong with the amd stoney CI, jobs take so long to start that marge times out almost always
<DavidHeidelberg[m]>
glehmann: there is in Marge queue daniels fix (rebalancing of jobs)
<DavidHeidelberg[m]>
and mine fix for disablong timeouting Alpine, but still seems there is few MRs to merge before these, it's shame we can prioritize them (well we can by just deassigning marge, but that feels rude)
<anholt>
if marge is failing, then just manage the assignments. it's not rude.
<DavidHeidelberg[m]>
Ok, I just left computer and lying in bed, can someone off & on Marge on all other commits expect mine and daniels?
<DavidHeidelberg[m]>
(and maybe expect the currently running one if it's close to succeding)
<DavidHeidelberg[m]>
*except
ahajda_ has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
ahajda_ has quit []
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
<airlied>
Lynne: might have found it, can you see if patch on my branch helps you
* airlied
will have to clean it up
<airlied>
Lynne: okay pushed a cleaned up version, it appears to work fine now
<airlied>
but would be good to have some confirmation!