<ccr>
meh. lynne's ffmpeg vulkan branch wants libvulkan 1.3.238 and Debian testing has only .236.
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<HdkR>
bleeding edge video extensions need bleeding edge things :P
<HdkR>
Waiting for the bloody edge of Snapdragon Vulkan Video
<ccr>
:)
<airlied>
ccr: just comment out the bit in the configure file
<airlied>
it doesn't actually need it really
<airlied>
since the loader can handle ext it doesn't know about
<ccr>
ahh.
Company has quit [Quit: Leaving]
Zopolis4 has joined #dri-devel
<ccr>
fails with undeclared constants/enums/something ( VK_KHR_VIDEO_DECODE_H264_EXTENSION_NAME ) .. which seem to be defined in libvulkan headers v1.3.239 available in unstable. in some cases transplanting packages from unstable may work, perhaps I'll try that later.
<airlied>
ah you need updated headers, not an updated runtime
<airlied>
yeah headers should be fine to transplant
<airlied>
ccr: cool, I hadn't had a chance to test hasvk yet
aravind has joined #dri-devel
<ccr>
np. I have few haswell machines, so thought to test :)
<airlied>
ccr: one minute I'll push a fix
<ccr>
airlied, ok :)
rahul_janga has joined #dri-devel
<airlied>
ccr: okay possible fix pushed to the branch
<ccr>
checking.
<ccr>
[AVHWDeviceContext @ 0x555ddb730340] Validation Error: [ VUID-vkCmdBeginQuery-commandBuffer-cmdpool ] Object 0: handle = 0x7f1bfc0784b0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x8dadbdcc | vkCmdBeginQuery(): Called in command buffer VkCommandBuffer 0x7f1bfc0784b0[] which was allocated from the command pool VkCommandPool 0x70000000007[] which was created with queueFamilyIndex 1 which doesn't
<ccr>
#0 0x00007ffff4527764 in anv_h264_decode_video (cmd_buffer=0x7fffd4078670, frame_info=0x7fffebffda00) at ../src/intel/vulkan_hasvk/genX_video.c:130
<ccr>
#1 0x00007ffff291fd86 in DispatchCmdDecodeVideoKHR (commandBuffer=0x7fffd4078670, pDecodeInfo=<optimized out>) at ./layers/generated/layer_chassis_dispatch.cpp:5685
<ccr>
#2 0x00007ffff28914e0 in vulkan_layer_chassis::CmdDecodeVideoKHR (commandBuffer=0x7fffd4078670, pDecodeInfo=0x7fffd41e6d18) at ./layers/generated/chassis.cpp:6534
<airlied>
ccr: ahd drop the debug=1
<ccr>
pardon the spam, I can paste these elsewhere if so desired
<airlied>
not sure the validation layers are up to much here
<ccr>
segfaults without debug=1
<ccr>
(gdb) bt
<ccr>
#0 0x00007ffff4527764 in anv_h264_decode_video (cmd_buffer=0x7fffd8074830, frame_info=0x7fffd81bba58) at ../src/intel/vulkan_hasvk/genX_video.c:130
<ccr>
#1 0x000055555640133f in ?? ()
<airlied>
okay guess I better kick a test video
<ccr>
heh. if you need anything, just holler. I'll probably be around.
fxkamd has quit []
<Lynne>
the validation layer is sadly currently pretty useless
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
rahul_janga has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
loki_val has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
<ccr>
airlied, ooh .. it works now :)
itoral has joined #dri-devel
<airlied>
ccr: I'm still seeing the odd hang with more frames
<airlied>
but it's a lot better
* ccr
cheers at airlied and Lynne
tzimmermann has joined #dri-devel
rahul_janga has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
rahul_janga has quit [Ping timeout: 480 seconds]
<Lynne>
vulkan video is happening, soon I'll be able to watch videos without crashing because the recent radeonsi *fix* actually broke stuff
Leopold___ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
fab has quit [Quit: fab]
kts has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sergi has left #dri-devel [#dri-devel]
sergi has joined #dri-devel
junaid has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
frieder has joined #dri-devel
<Lynne>
why do descriptor set templates require a pipeline layout?
<Lynne>
they already have the descriptor layout, what possible use can they have for a pipeline layout other than make my/everyone's life more miserable?
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<airlied>
Lynne: push constants has something to do with it
<airlied>
sorry push descriptors
<airlied>
at least in radv it's the place I see it being used
heat has quit [Ping timeout: 480 seconds]
<Lynne>
you mean internally on a very low level or?
nchery has joined #dri-devel
<airlied>
yeah, radv_CreateDescriptorUpdateTemplate has a comment about it
nchery has quit [Read error: Connection reset by peer]
<airlied>
also "
<airlied>
pipelineLayout is a VkPipelineLayout object used to program the bindings. This parameter is ignored if templateType is not VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR
<airlied>
"
<airlied>
so you might not need to supply it
rahul_janga has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has joined #dri-devel
rahul_janga has quit [Remote host closed the connection]
rahul_janga has joined #dri-devel
<Lynne>
I'm using update templates, so I do
<Lynne>
oh, nevermind
danvet has joined #dri-devel
<Lynne>
why would you want to update push descriptors via a template anyway?
<Lynne>
I like the low-level DIY layout of the regular pushconst updates
tursulin has joined #dri-devel
Lyude has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
ice99 has joined #dri-devel
Lyude has joined #dri-devel
mvlad has joined #dri-devel
ahajda_ has joined #dri-devel
rasterman has joined #dri-devel
MajorBiscuit has joined #dri-devel
lynxeye has joined #dri-devel
bgs has joined #dri-devel
vliaskov has joined #dri-devel
rahul_janga has quit [Ping timeout: 480 seconds]
dviola has left #dri-devel [#dri-devel]
dviola has joined #dri-devel
djbw has quit [Remote host closed the connection]
ice99 has quit [Remote host closed the connection]
jluthra has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
jluthra has joined #dri-devel
rahul_janga has joined #dri-devel
rahul_janga has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
Zopolis4 has quit []
ice9 has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest4150
jdavies_ has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
lplc has left #dri-devel [#dri-devel]
Guest4150 has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
lplc has quit []
nxf25336 has joined #dri-devel
nxf25336 has quit []
rahul_janga has joined #dri-devel
lplc has joined #dri-devel
devilhorns has joined #dri-devel
lplc has quit []
lplc has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
agd5f has joined #dri-devel
rahul_janga has quit [Read error: Connection reset by peer]
Leopold_ has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
Dylanger has left #dri-devel [#dri-devel]
Leopold_ has quit [Remote host closed the connection]
<Lynne>
"The descriptor buffer API effectively removes VkDescriptorPool and VkDescriptorSet"
<Lynne>
I hate descriptor sets, this is looking good
<emersion>
yup, same here :P
<jenatali>
That'll be a fun one to implement in Dozen :)
jkrzyszt has joined #dri-devel
<dj-death>
you don't get to do away with the layouts though
<zmike>
if you've only gotta juggle layouts (and not pools+sets additionally) then they're not so bad
<Lynne>
my issue is that I want to support multiple submissions to multiple queues
<Lynne>
which meant I needed one descriptor set per each queue (you can't reuse them), and a template updator
<zmike>
hm
<zmike>
don't remember if there's a restriction against submitting descriptor buffers repeatedly
<dj-death>
there is a restriction you don't modify entries used by one queue
<dj-death>
but yeah with descriptor indexing you can modify after recording
<dj-death>
and also modify stuff that is not accessed while the GPU is reading the descriptor set
itoral has quit []
<zmike>
🙏 descriptor 🙏 indexing 🙏
<jenatali>
Aka my current bane
<dj-death>
jenatali: do you have to support that?
<jenatali>
Yeah, I think so. Apps we care about require it
<dj-death>
everybody will indeed
<zmike>
I can hear airlied crying over a pint now
<zmike>
lavapipe descriptor indexing remains a extreme challenge
<dj-death>
a pint 🤤
<jenatali>
WARP mostly handles it, UBO indexing is busted though
<jenatali>
My problem is that we have restrictions in place on descriptor heaps which give us limits way lower than what VK needs. Thanks to NVK though I have a viable path forward
<zmike>
the limits are the hard part
paulk has quit [Quit: WeeChat 3.0]
<jenatali>
Yeah. 500,000 samplers in a set when some hardware has 12-bit sampler indices...
paulk has joined #dri-devel
<dj-death>
it's kind of ridiculous that up to dg2 you could have more samplers than surface descriptors on intel gpus ;)
<jenatali>
But then I saw that you only need to have up to 4000 unique samplers alive at a time. Except D3D's limit in a heap is 2048...
<dj-death>
technically it's still more (since it's 32bytes vs 64bytes both in a 4Gb heap)
<Lynne>
is it really a good idea to represent descriptors as vkbuffers?
<Lynne>
what if the driver doesn't flag coherent memory, then you need to flush after copying
<dj-death>
I'm looking forward to every app shooting itself in the foot
<jenatali>
For future-looking hardware? I'd say yes. For current hardware, I'd say no
<dj-death>
Lynne: there are synchronization bits you need to put in your barriers
<dj-death>
I think there is still no validation for all that right?
<Lynne>
"If you’re updating descriptors from the CPU, you get the implicit host -> device synchronization on vkQueueSubmit."
<Lynne>
that's so un-vulkan, you'd get a citation from the house of un-vulkan activities for that
ced117 has joined #dri-devel
<Lynne>
I do like that you can modify descriptors from the GPU itself
<Lynne>
with that, along with the NV extension for gpu command buffers, you could realistically abandon vendor-specific compute suites
<ccr>
"are you, or have you ever been updating descriptors from the CPU .."
<Lynne>
so you don't allocate descriptors at all with descriptor buffers?
<Lynne>
ah, I see, so you allocate them, bind them, and then look them up?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<dj-death>
Lynne: you allocate buffers yourself, bind them as descriptor buffers in the command buffers
<dj-death>
Lynne: you do all the writing in them yourself
<Lynne>
that's so much simpler!
Danct12 has joined #dri-devel
<Lynne>
this also removes the need for having sets of descriptors, doesn't it? since you can now choose to update whichever one you want at any time
Daanct12 has quit [Ping timeout: 480 seconds]
devilhorns has quit []
<zmike>
that's architectural and depends how you're using them
yuq825 has left #dri-devel [#dri-devel]
<Lynne>
are there any advantages left for "layout (set = %i" other than 0?
<emersion>
i use multiple sets
<emersion>
ah
<emersion>
okay, that was a question related to the ext, sorry for the noise
<zmike>
it can be easier for managing buffer sizing
<zmike>
but it's architectural
<Lynne>
hmm, what about push consts/descriptors?
<Lynne>
internally, are they just the same as regular descriptors, so it's pointless to use them if using descriptor buffers?
kts has quit [Quit: Leaving]
jkrzyszt has quit [Remote host closed the connection]
<zmike>
again that comes down to architecture
<zmike>
either you need them or you don't
<Lynne>
I don't know if I need them or don't need them, but not needing them would save me work from not having to abstract them, so I'd like to not need them, if possible :)
<Lynne>
push consts are afaik generally cheap, but are they cheap enough to still beat descriptor buffers?
<zmike>
implementation dependent
<Lynne>
fair enough
jewins has joined #dri-devel
heat has joined #dri-devel
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Company has joined #dri-devel
<zmike>
eric_engestrom: what's the git cherry-pick --option I'm supposed to use again?
<zmike>
hm maybe -x
<DPA>
Apparently, my monitor supports HDR. I don't think X11 can do that yet, but DRM/KMS can, right?
<DPA>
Are there any demos to see what that looks like?
kts has joined #dri-devel
<heat>
DPA, *if* (I'm not sure, I'm no expert in HDR) it requires explicit X11 support, X11 will never be able to do HDR
<heat>
due to it being in maintenance mode
fxkamd has joined #dri-devel
<emersion>
DPA: simplest is probably mpv or kodi
<emersion>
running directly with their KMS backends
<DPA>
It doesn't need to be X. I'm OK with something that just directly talks to /dev/dri/. I just want an example to see what it would look like.
<DPA>
I think I'll just build that pr myself. It'll be good enough to get an idea of what HDR looks like.
JohnnyonFlame has joined #dri-devel
fdu has quit [Remote host closed the connection]
jdavies_ has quit [Remote host closed the connection]
jdavies has joined #dri-devel
jdavies is now known as Guest4184
alyssa has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
fab has quit [Quit: fab]
<eric_engestrom>
zmike: yup, -x :)
<zmike>
ok then I got it
alyssa has left #dri-devel [#dri-devel]
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
jewins has joined #dri-devel
<eric_engestrom>
zmike: ah, I see that you pushed directly on the staging branches; thanks for the custom backport :)
<zmike>
I remembered -x this time!
<eric_engestrom>
I see :D
<ajax>
heat: enh. if anyone really wanted to wire it up for Xwayland it's pretty trivial. i wouldn't expect it to ever work for Xorg though
vliaskov has quit [Remote host closed the connection]
fab has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
<ajax>
or at least. it's pretty trivial for Xwayland to expose Visuals for arbitrary depths, since they map directly to wayland image formats and the compositor is the one responsible for making them display correctly
kzd has joined #dri-devel
<emersion>
HDR is much more than just high-bit depth buffers
<ajax>
getting the hdr metadata plumbed through is then a typing exercise, but then you'd need to go update every x11-supporting media engine
<ajax>
yes, i'm aware
<ajax>
so like. you could make Xwayland do it, but at that point why are you still using X for this
mohamedAdhamc has joined #dri-devel
junaid has joined #dri-devel
djbw has joined #dri-devel
aravind has joined #dri-devel
ahajda_ has quit []
frieder has quit [Ping timeout: 480 seconds]
sarnex_ has quit []
sarnex has joined #dri-devel
pallavim has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
tursulin has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
nchery is now known as Guest4197
nchery has joined #dri-devel
Guest4197 has quit [Ping timeout: 480 seconds]
ahajda_ has joined #dri-devel
ahajda_ has quit [Remote host closed the connection]
<danvet>
mairacanal, I didn't get around to replying, but debugfs vs accel is essentially a case of "landed together"
<danvet>
might be good to chat with ogabbay on this and make sure we don't accidentally diverge further :-)
mohamedAdhamc has quit []
<mairacanal>
danvet, do you have any thoughts on the generalization of the debugfs api?
<dcbaker>
PSA: if you're going to merge things to the stable branch, please ping me on IRC
<dcbaker>
I've force pushed over things that I didn't know were merged to the branch twice this week
<kisak>
mareko ^
<dcbaker>
fortunately I later saw them and got them back
<DavidHeidelberg[m]>
mattst88: Hey! As we been looking into the SSE2 linking issues, could you give me some basic feedback on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21180 ? One thing I believe that "-msse2" should be applied to both C and C++ code, since it's linked together, another bit I would like to see what you think about sharing also `-fpmath=sse` and `-mstackrealign`
<mattst88>
sure thing! thanks DavidHeidelberg[m]~
<ogabbay>
mairacanal: I haven't yet gotten to read the email thread to understand the change, but I can already say that I don't see any reason accel won't align to drm code in this issue
glennk has quit [Remote host closed the connection]
<ogabbay>
We have just one driver in (iVPU) and we are now working internally to change the habanalabs driver to use accel, so this is a good point in time to do this alignment
glennk has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
jeeeun8413 has joined #dri-devel
pallavim has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
kts has quit [Quit: Leaving]
<danvet>
mairacanal, replied, but maybe be extra cautious because my brain is not in well working order at thinking stuff through properly right now :-)
<danvet>
zackr not around?
pallavim has joined #dri-devel
<bl4ckb0ne>
is there a way to choose a GPU when using eglGetPlatformDisplay with EGL_PLATFORM_SURFACELESS_MESA and EGL_DEFAULT_DISPLAY ?
djbw has quit [Read error: Connection reset by peer]
<Sachiel>
eric_engestrom: I failed to tag 58ababdee6cd6b1e08604033602e4a5f9d5ab7a3 for stable and it'd be nice to have it in 22.3, what do you want me to do about it?
junaid has quit [Read error: No route to host]
junaid has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<zmike>
is there a way to trim an apitrace to a select group of frames? gltrim can do a single frame, but I want to start at e.g., frame 1000 and keep 50 frames
<zmike>
do we have that technology
Guest4184 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<airlied>
zmike: do trim not take a range?
<zmike>
the help claims it takes a single frame
<airlied>
apitrace trim takes a range
<zamundaaa[m]>
<ajax> "or at least. it's pretty trivial..." <- On Xorg, some apps severely misbehave or even crash when it's set to 10 bpc. I guess that's caused by Xorg then *only* supporting 10bpc, and wouldn't affect Xwayland?
<zmike>
oh this is different from gltrim
<zmike>
baffling
iive has joined #dri-devel
ngcortes has joined #dri-devel
<zmike>
hmm I tried passing 1000-1050 as a frame range and it generated something that doesn't seem to play back correctly
<airlied>
yeah that seems about right for trimming :-P
<zmike>
ah
<airlied>
dj-death: sorry about that, thought not sure we'd have found that bug if I'd left the env var in place, though I think we should just have set v_count to 0 and use the queue overrides instead of reintroducing a variable
<airlied>
dj-death: where did it show up? intel mesa CI? I'd like to try and fix the queue picking, looks like anv is totally missing any blit queue picker
<zmike>
oh ok gltrim takes a range
<dj-death>
airlied: yeah, I think it might not be ready to enable by default just yet ;)
<dj-death>
airlied: I just ran gfxbench
<dj-death>
airlied: tbh it looks like a wsi issue
<dj-death>
airlied: it shouldn't even try to use a video queue family for blits
agd5f_ has quit []
<dj-death>
airlied: I've also seen a CTS issue, but I don't have the latest
agd5f has joined #dri-devel
<dj-death>
airlied: I guess you need to run this on a secondary GPU
<dj-death>
airlied: it'll force a blit to linear shared buffer with compositor
<airlied>
dj-death: so you were using DRI_PRIME=1 setup?
<dj-death>
no
<dj-death>
just VK_ICD_FILENAME=intel_icd
<dj-death>
my primary gpu is an amd card
<airlied>
ah okay
<dj-death>
but yeah that should repro as well
<airlied>
I'll go re-enable my integrated gpu, I think it's a blit queue picking callback, but I'll chase it down
Haaninjo has joined #dri-devel
<Kayden>
anv-transfer-queue in my tree has a blit queue if you need one
<Kayden>
but only for dg2+
<airlied>
Kayden: you seem to be missing the wsi callback though
<airlied>
though I only glanced at the MR
<Kayden>
ah, thanks!
djbw has joined #dri-devel
<eric_engestrom>
Sachiel: cherry-picked, it will be in tonight's release
<Sachiel>
thanks!
junaid has quit [Remote host closed the connection]
Zopolis4 has joined #dri-devel
<airlied>
though presenting from the video queue should be fine, it's just makint it not blit
ngcortes has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
<ajax>
bl4ckb0ne: there's DRI_PRIME= and such, but at that point maybe use platform_device instead of platform_surfaceles
<bl4ckb0ne>
yeah, i figured i was better off with a platform_device
gouchi has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
X512 has joined #dri-devel
<X512>
It is possible to do EGL window rendering with platform_device other than EGLStreams?
<emersion>
i don't believe so
<emersion>
not unless you reimplement the whole WSI
<emersion>
s/not//
<X512>
It may be a good idea to implement EGLStreams in Haiku...
<DPA>
Is there a way to check if HDR is being used or not? I downloaded some HDR test videos and pictures, but don't see any difference between the mpv with HDR patch and the one without.
<emersion>
i wouldn't recommend that
<emersion>
everyone is trying to get rid of EGLStreams
<emersion>
DPA: drm_info should tell
<X512>
I don't understand why EGLStreams is not welcomed in Linux.
<emersion>
x512: it has many shortcomings
<X512>
It seems a good idea.
<X512>
Not being able to select EGL device by API is A BIG shortconing.
<emersion>
that isn't unfixable
<emersion>
create an EGL-Registry issue to discuss, if you care about this
<anholt_>
airlied: hsw runner should be back now, I'll update crocus baseline state. and I'm also kicking off a "how bad would some hasvk coverage be?" branch.
kts has quit [Quit: Leaving]
leo60228- has joined #dri-devel
leo60228 has quit [Read error: Connection reset by peer]