<javierm>
I posted a panel MIPI DSI driver that was using a custom macro, that didn't include the command in the payload when calling mipi_dsi_dcs_write_buffer()
<javierm>
and sravn_ asked me to use mipi_dsi_dcs_write_seq() instead. The driver still worked but I'm confused how it could if the data sent over MIPI DSI is not the same...
<javierm>
and now I see that MIPI DBI is also not including it... it looks fishy
ybogdano has joined #dri-devel
<pinchartl>
struct mipid_dbi.command takes the command and data as separate fields
<pinchartl>
look at mipi_dbi_typec3_command() and mipi_dbi_typec1_command() which are the two possible implementations of .command() over SPI
<pinchartl>
I assume there's a reason why the command and data need to be transferred separately
<javierm>
pinchartl: yes, I actually meant that the mipi_dsi_dcs_write_seq() was the one that looked off
<pinchartl>
the command has to be transferred somehow :-)
<pinchartl>
for DSI it seems to be packaged in the buffer with the data
<pinchartl>
looking at the DSI spec, that makes sense
<pinchartl>
for instance, in DSI v1.00a, section 8.8.8.3 states
<pinchartl>
"The packet consists of the DI byte, a two-byte WC, an ECC byte, followed by the DCS Command Byte, a payload of length WC minus one bytes, and a two-byte checksum."
<pinchartl>
so the command byte is part of the payload
<javierm>
pinchartl: ahh, I see. Thanks for the clarification, makes sense
<javierm>
and now I looked again at the downstream driver and they had "#define dsi_dcs_write_seq(dsi, seq...)" while the mainline helper is "#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)"
<javierm>
pinchartl: sorry for the silly question, all clear now :)
<pinchartl>
:-)
<javierm>
hmm, lots of panel drivers in mainline also have the same macro... wonder that's a lot of copy&paste there
<javierm>
will probably do a cleanup while being there
Company has joined #dri-devel
* Lynne
has finished typing
<Lynne>
airlied: updated my repo
<Lynne>
should create a fully conformant h264 stream for any container
<Lynne>
even aligns the buffer offset to the required value with h264 filler units
<Lynne>
is there some area I can help with the drivers? preferably something with a low-ish chance of crashing my GPU, I'm working on my desktop
* airlied
is still typing, at the moment it's still at the kill the card every time mode :-P
<Lynne>
if it's any consolation, nvidia's self-proclaimed fully compliant driver also locks the GPU up when running it
<Lynne>
just takes a few dozen segfaults to permanently mess up the driver state and require a reboot
jkrzyszt has quit [Ping timeout: 480 seconds]
cyrozap has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: what's a temporal layer and do I care?
<airlied>
the vaapi driver has a bunch of stuff for them
<Lynne>
I believe that's B-frame layer stuff, you can leave it for now
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
freemint has joined #dri-devel
<Lynne>
the query system is the most awkward piece of API I've used
<Lynne>
each query may produce multiple results
<Lynne>
additionally, each query may produce a single status
<Lynne>
unless VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR is used, then each query produces a single status and no results
<Lynne>
and it's all dumped in a single array that may or may not be 32 bits per element
* airlied
really doesn't like how they used queries, at least the hw doesn't really suit it
agd5f has joined #dri-devel
<Lynne>
yeah, me neither
<Lynne>
what does the hardware suit?
<Lynne>
queries are async, and so is the hardware, so I'm guessing that's fine
<airlied>
the status stuff doesn't map directly to what the hw writes
<airlied>
so you have to remap things, same with the encoder stuff
<airlied>
I've no idea how to use vkCmdCopyQueryPoolResults without writing a compute shader
<airlied>
which I'm not sure makes sense to do on the queue
<airlied>
remapping for GetQueryResults isn't too bad, but for the GPU side stuff it's a pita
<bnieuwenhuizen>
vkCmdCopyQueryPoolResults being a pain into 2023? Who'd have thought
<Lynne>
I'm not sure why that funtion exists, is it because of the weird semantics of query flags like WAIT?
<airlied>
Lynne: it allows you do the query gpu side without cpu interaction
<airlied>
so some subsequent gpu action could be based on it
<bnieuwenhuizen>
or just to "save" the results before submitting the same cmdbuffer again
<Lynne>
it's especially cludgy for video encoding
<Lynne>
if you'd like to know the status and not just the result, you have to query with the VK_QUERY_RESULT_WITH_STATUS_BIT_KHR set, which adds one more status to your 2 results
<Lynne>
because GetQueryPoolResults only returns the query status and not the result of the operation afaik
<airlied>
Lynne: getting pSetupReferenceSlot being NULL again
<Lynne>
yeah, the spec says it can be null
<airlied>
but what does it mean if it's NULL?
<airlied>
I don't have a DPB?
<airlied>
which I suppose for a single frame might make sense
* airlied
isn't sure how happy the hw will be though
<Lynne>
the frame has no references, so it's pointless to have a DPB
<Lynne>
if it's unhappy, you can remove the #if 0 code to create the dpb pool, and remove the is_reference checks during frame_init and issue
<Lynne>
the spec can be changed
lemonzest has quit [Quit: WeeChat 3.6]
* airlied
starts by hoping the hw does sane things, only have vaapi driver isn't that enlightening
<Lynne>
vaapi is kinda weird for using bit-sized buffers rather than bytes
<Lynne>
that threw me off, I was wondering why my h264 nal math was off by a factor of 8
<Lynne>
I'm going to implement 64-bit query results support while I'm redoing my query wrapping
<Lynne>
that way I can point to enemy drivers and yell "INCOMPLIANT!"
<airlied>
I think these exts probably need a team of at least 5 ppl writing CTS for them
agd5f has quit [Ping timeout: 480 seconds]
<Lynne>
I wanted to test amdgpu-pro, because AMD's new drivers have support for the decode extension
<Lynne>
but it was released a few days before the windows version, so I didn't even bother
<airlied>
I don't think their Linux version has decode
<Lynne>
and I'm not installing windows on my 600kbps (really) connection
<Lynne>
besides, I'm sure they only tested nvidia's samples, where half the time implementing it was just building the thing
<Lynne>
iirc khronos require 2 implementations for each extension, right?
ngcortes has quit [Ping timeout: 480 seconds]
<Lynne>
does a radv implementation count?
<airlied>
yes radv counts
<airlied>
but windows amd also counts
<airlied>
it's also possible they will do a pro build not from amdvlk sources with video for Linux I suppose
<ishitatsuyuki>
the GPU-side query result manipulation commands feel like a sinking ship, with all the implicit sync headaches
<ishitatsuyuki>
good thing is with host query reset we can mostly avoid relying on them
<airlied>
Lynne: I think I'm at the finished typing stage, now for the wtf debug stage
<Lynne>
radv_enc_nalu_aud
<Lynne>
you're emitting AUDs before each slice, right?
<Lynne>
that was one of my notes for the spec, you can't control AUD behavior for slices, they're optional, but recommended
rcf has quit [Ping timeout: 480 seconds]
<airlied>
at the moment I'm just trying to spot the difference between cmd streams
<airlied>
to make sure I'm encoding the cmds correctly
rcf has joined #dri-devel
<Lynne>
yup, fair enough
Danct12 has joined #dri-devel
lemonzest has joined #dri-devel
freemint has quit [Read error: Connection reset by peer]
freemint has joined #dri-devel
rmckeever has joined #dri-devel
<Lynne>
airlied: updated my branch, rewrote queries
<Lynne>
now it should be correct
<Lynne>
each query for encoding should produce 2 results, the first one is the buffer offset given when submitting, the second one is the number of bytes written to the buffer
<Lynne>
and additionally, since I always set VK_QUERY_RESULT_WITH_STATUS_BIT_KHR, the status of encoding following right after the 2
heat has quit [Ping timeout: 480 seconds]
genpaku has quit [Remote host closed the connection]
<kurufu>
dj-death Ah, it appears the issue was actually that intel doesnt expose gpu metrics in any unprivileged way. Only perf metrics are available. Someone had actually already implemented shelling out to intel_gpu_top with setcaps... i am reminded of the "joy" of netlink stats.
genpaku has joined #dri-devel
bmodem has joined #dri-devel
<Lynne>
airlied: made a few more changes for conformance, now all values are properly set for intra-only decoding
YuGiOhJCJ has joined #dri-devel
<airlied>
Lynne: okay wierdness, I'm seeing an EndCommandBuffer on an encoding command buffer but no begin
<airlied>
Lynne: maybe nvidia exposes all the bits on the same queue but radv doesn't
<Lynne>
all bits on the same queue?
<Lynne>
as in decode+encode?
<Lynne>
(it doesn't, it has separate qfs)
<airlied>
okay not that then
<airlied>
then I'm just getting a command buffer being end/submit on the wrong queue
aeotdsp^ has quit [Remote host closed the connection]
kts has joined #dri-devel
<Lynne>
queue index or queue family?
<Lynne>
wait, is that even possible? submission is an atomic operation, you can't begin and end on different queues if you only submit once
<airlied>
yeah I've no idea why it's happening
<airlied>
but I'm getting and End on a encode qf cmd_buffer without seeing a start
<airlied>
and the contents of the cmd buffer look like gfx or compute
agd5f has joined #dri-devel
<Lynne>
what kind of an end? vkCmdEndVideoCodingKHR or vkEndCommandBuffer?
<airlied>
actually wierd, didn't happen now, maybe gdb is confusing me
<airlied>
Lynne: yeah ignore me, seems to be a debugger distraction
Danct12 has quit [Quit: Quitting]
<airlied>
okay cmd buffer doesn't seem to have much junk in it now, still hangs, but definitely getting closer :-P
<Lynne>
do you think the hardware needs a dpb buffer even for intra-only?
<Lynne>
nvidia seems to always provide it
jewins has quit [Ping timeout: 480 seconds]
<Lynne>
airlied: always enabled DPBs for images in my branch, your branch doesn't mind allocating frames with that usage
<Lynne>
layered dpb will work, but... ugh, it would sure be a big downer if at least navi21 or 23 doesn't support dynamic DPBs like with decoding
Danct12 has joined #dri-devel
<airlied>
Lynne: I'm not sure I already turned on that path for intra-only and it didn't fix the hangs
<airlied>
Lynne: but no sign of any dynamic DPB support for encode engine, but since I've got no programming info it might be possible, but the encode engine is nothing like the decode engine at all
<airlied>
IP blocks from two very different sources
<Lynne>
how odd, I thought they did everything in-house (except vp9/av1 decoders, for those I'm pretty sure they just copied the official verilog code)
<airlied>
Lynne: maybe but it looks like two different teams did dec/enc
<airlied>
the hw programming models are completely different
<Lynne>
I'm looking at some AMF API code and there's an example on ref frame allocation and injection
<Lynne>
I'm not sure that's possible without that, unless the closed source driver wraps it around
<Lynne>
got an insider to ask for some hw info?
<airlied>
Lynne: kinda, but they are all on holidays :-P
srslypascal is now known as Guest600
srslypascal has joined #dri-devel
Guest600 has quit [Ping timeout: 480 seconds]
<Lynne>
it'll reduce parallelism by a fairly large margin, but it'll work
<Lynne>
1337 h4ck3rz need no holidayz :P
<Lynne>
there's a patch to enable sync operation for vaapi
<Lynne>
that'll flip on ffmpeg's vaapi async submit mode
<Lynne>
it's probably going to be broken, but oh well
junaid has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<airlied>
Lynne: hey so the API has pictureType I and IDR
<airlied>
should a single frame decode be IDR?
<airlied>
just in some places the vaapi driver programs the hw different dependning on that
<airlied>
though it is probably based of the idr_pic_flag
Duke`` has joined #dri-devel
<Lynne>
they're different
<Lynne>
IDR frames are proper keyframes
<Lynne>
I-frames are for open gops, where B-frames from a previous gop can reference an I-frame in a following gop
<Lynne>
for now, it should be IDR, we'll get open gop fixed later
rasterman has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
<airlied>
Lynne: okay I'm done for today, going to have to start digging a bit deeper tomorrow, I think I'm encoding all the commands just like vaapi is
<airlied>
but the engine isn't throwing any vm faults, it's just locking up
<airlied>
so I'll have to dig and check exactly what is going into the ring and see what might be screwing it up
<Lynne>
alignments, maybe?
<Lynne>
we do align the bitstream
kts has quit [Quit: Leaving]
<Lynne>
but as for images, no
<Lynne>
should try a nice video which is mod 16 or larger in both dimensions
<airlied>
things seem aligned right, I'll start looking at that sort of thing tomorrow
<Lynne>
yeah, it's about time for me to get some sleep too
ppascher has quit [Quit: Gateway shutdown]
kts has joined #dri-devel
lplc has joined #dri-devel
maxzor has joined #dri-devel
bgs has joined #dri-devel
kts has quit [Quit: Leaving]
mvlad has joined #dri-devel
jkrzyszt has joined #dri-devel
luckyxxl has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
Johnny has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
luckyxxl has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
anholt: "Connecting to 10.42.0.1:8888... failed: Connection refused." on gk20a jobs
<anholt>
we just got power back this morning. kid is home, won't be able to debug anything for a while.
bmodem has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
anholt: that's from now :(
<DavidHeidelberg[m]>
I'll disable your farm for now, if you won't object
mbrost has joined #dri-devel
kts has quit [Quit: Leaving]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
<CounterPillow>
Mis012[m]: the former
<Mis012[m]>
I'd expect Mesa to have that next to the envs to override GL/GLSL version
jewins has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<Lynne>
anyone know of any drivers or devices where image layout conversions are not noops?
camus has quit [Remote host closed the connection]
KungFuJesus has joined #dri-devel
camus has joined #dri-devel
jkrzyszt has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
gouchi has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
<DavidHeidelberg[m]>
enunes: more Wayland enablement, nice :) If you are testing, please rebase on top of the current git. Otherwise, you'll have slower CI due 2 to stoney runners missing (12 jobs on ten physical runners)
<DavidHeidelberg[m]>
I meant also rebase because of then it's hard to run anything because you use 12/10 jobs :D so if you use 10/10 jobs, when they finish the CI is free :P
<enunes>
I'd do it locally but it's tricky to replicate the cross compilation setup
<DavidHeidelberg[m]>
I saw the MR, but weston docs is so nicely non-existing.
<DavidHeidelberg[m]>
ok, time to look into weston git code to verify ....
ngcortes has joined #dri-devel
<DavidHeidelberg[m]>
enunes: I think your MR description is better doc than what Weston has.
<enunes>
DavidHeidelberg[m]: I checked by running clients against weston headless and if they print the GL vendor, it will just print llvmpipe when weston doesn't use the gl backend
warpme_____ has quit []
<enunes>
or by checking with WAYLAND_DEBUG=1 some globals are missing, notably the dmabuf one which is what I think makes it fallback to that
<DavidHeidelberg[m]>
enunes: imho if it doesn't break anything currently running, I think it will hardly cause troubles
<enunes>
I think it shouldn't for now, but then again many builds are missing the wayland platform (the other thing I've been working now) so I guess we'll see later
Surkow|laptop has joined #dri-devel
Haaninjo has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
freemint has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<airlied>
yay page faults
Lyude has quit [Ping timeout: 480 seconds]
<Lynne>
no freezes?
<DavidHeidelberg[m]>
enunes: I think you can merge with daniel R-b :) !20391
Lyude has joined #dri-devel
<airlied>
Lynne: got something to execute without apparantly dying, but I think it might be dying on the inside :-P
<airlied>
I need to dig into the feedback query a bit more
<Lynne>
if the query code is broken but the rest isn't, for a quick test, you can just delete the ff_vk_get_exec_ctx_query_results call in vulkan_encode_output and hardcode some plausibly large packet size
Thaodan has left #dri-devel [Using Circe, the loveliest of all IRC clients]
<Lynne>
decoder doesn't really care about padding, and neither do fansubbers who want files with "nice" checksums
ngcortes has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ngcortes has joined #dri-devel
<airlied>
Lynne: so the vmfaults were from not having a dpb, will need to dig into if there's a way to dodge that
<Lynne>
had a hunch it was
<Lynne>
btw how many layers can a dpb for encoding have at most? the max dpb value signalled by the caps?
Gue___________________________ has joined #dri-devel
Gue___________________________ has quit [Remote host closed the connection]
<airlied>
yeah I assume so
jasonnfls has joined #dri-devel
jasonnfls has quit []
Duke`` has quit [Ping timeout: 480 seconds]
jasonnfls has joined #dri-devel
<airlied>
Lynne: ff_vk_get_exec_ctx_query_results is inconsistent in handling res vs err for 32 vs 64-bit results
* airlied
also isn't sure that handling makes sense
<airlied>
ah I don't handle WITH_STATUS for that, does WITH_AVAILABILITY not work?
<Lynne>
you can remove WITH_STATUS, just remove the loops to check the status at the end
lemonzest has quit [Quit: WeeChat 3.6]
<airlied>
Lynne: my branch has some non-hangy stuff that produces a bitstream that is broken
<Lynne>
that's a start!
<Lynne>
I'll check it out in a few mins to see what kind of broken it is
<airlied>
well it produces some all grey stuff
<airlied>
but you might be able to tell if the bitstream makes any sense
<airlied>
playing back the ts gives top block unavailable for requested intra mode
mvlad has quit [Quit: Leaving]
<Lynne>
use mkv for now
<Lynne>
I'm not confident in my h264 bitstream code
jasonnfls has quit []
<Lynne>
GetQueryPoolResults errors out despite removing the WITH_RESULTS flag
<Lynne>
maybe it's my fault
<Lynne>
"Received a packet, 3712 bytes large (0 off, 3712 data), status = 0"
<airlied>
Lynne: that was mkv :-)
<Lynne>
that's wrong, I write a few tens of bytes of stuff before the offset value
<airlied>
the offset you give isn't contained in the returned offset
<airlied>
"The offset into the bitstream buffer range used by the video encoding operation where the bitstream data was written. This offset is an additional offset from the start of the range specified by the application."
<airlied>
at least that is how I read that
gouchi has quit [Remote host closed the connection]
<airlied>
Lynne: you have a bug in the err -> ref
<airlied>
err->res typo
<airlied>
in the query results I mentioned it above!
<Lynne>
yup, I fixed that already (locally)
<Lynne>
"specified by the application", I read that as "the offset you give in encodeinfi
<airlied>
yes so you give encode info dstBitstreamBufferOffset
<airlied>
of 0x100 or so
<airlied>
you shouldn't expect to get that back in the status packet
* airlied
also has no idea where the hw might stash an offset :-P
jasonnfls has joined #dri-devel
<Lynne>
can't mesa stash it somewhere? it's 32 bits
<airlied>
why though? the api says you don't get the value back
<Lynne>
what does "offset" contain then?
<airlied>
it must be some hw specific thing?
<Lynne>
it says it's specified by the application
<Lynne>
you don't specify any other offset than the bitstream buffer offset
<airlied>
no it says it's an additional offset from the start
<airlied>
which to me implies some hw alignment offset or something wierd
jasonnfls has quit [Ping timeout: 480 seconds]
<Lynne>
the spec should do its job better!
<Lynne>
we can't handle an additional offset below 6 bytes
<Lynne>
otherwise we can't insert an h264 filler element to create a valid bitstream
<Lynne>
and the intention is that the encoder ought to produce a valid bitstream
* airlied
would just assert on it not being 0 :-
<Lynne>
so does the encoder write to the correct offset currently?
<airlied>
d3d12 doesn't give back an offset in it's output metadata
<airlied>
Lynne: I assume so, but I'm just programming the hw
<airlied>
I should look at buffer content before/after
<Lynne>
I think it is
<Lynne>
btw, you can use "./ffmpeg_g -i test.mkv -c:v copy -bsf:v trace_headers -f null -" to inspect a file
<Lynne>
prints all headers and all values
<Lynne>
and all units
mbrost has quit [Ping timeout: 480 seconds]
<Lynne>
I'm seeing my filler data, and after it, an AUD and an SPS, which I didn't put in
<Lynne>
so it's the encoder's doing
<airlied>
yes it fill something in
<airlied>
though you have these three words 0x010000000x000010090x4d670100 and so does it
<Lynne>
the encoder should only put SPS and PPS on VkVideoEncodeH264EmitPictureParametersInfoEXT, not on VkVideoEncodeH264VclFrameInfoEXT,
<Lynne>
the SPS unit it writes is also invalid, rbsp_stop_one_bit is 0
<airlied>
okay will dig a bit into that later
<Lynne>
overriding that broken bit, what follows is a PPS
<Lynne>
and what follows next is a slice header!
<airlied>
Lynne: win! I'm going AFK for an hour or so will dig in further when I return!
<Lynne>
the cabac header is similarly broken to SPSs, cabac_alignment_one_bit is 0
<Lynne>
I'm thinking the encoder aligns the bitstream too early
<Lynne>
a big difference between vaapi and vulkan is that vaapi's bitstream buffers are entirely in bits
anholt has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
<Lynne>
the SPS, PPS and slice header values are wrong though
<Lynne>
idr_pic_id = 0
<Lynne>
pic_init_qp_minus26 = 0 rather than what I put in the session params
<Lynne>
it feels like the hardware just does whatever it wants
<Lynne>
all this typing, code, and thought, and this is how it shows respect?!?
rasterman has quit [Quit: Gettin' stinky!]
<Lynne>
I've pushed the query and offset fixes to my branch
<Lynne>
a bit quiet because I'm doing an exec_ctx to queue back to exec_ctx refactoring
<Lynne>
have to make it threadsafe because decoding