<airlied>
I can see a frame with data in it, not sure it's correct, but looks close to what it should
<airlied>
and no complaints from the parser
<Lynne>
slice_qp_delta is wayy off, 26
<Lynne>
is this the encoder's doing?
columbarius has joined #dri-devel
<airlied>
that field I think the encoder does
<airlied>
but not sure what directs it
<Lynne>
ah, you probably haven't plumbed qp from VkVideoEncodeH264RateControlLayerInfoEXT
<airlied>
no I haven't I hardcoded some values I found lying around vaapi
co1umbarius has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: will fixup the vcl frame info thing now
<Lynne>
I belive radv_enc_rc_per_pic is where you set the qp
<airlied>
Lynne: do you include the EmitPictureParameters yet?
<Lynne>
nope, and I don't intend to either, we can write our own headers
<Lynne>
changing the min qp does indeed improve the quality
<Lynne>
so it's definitely working
* airlied
assumes the ability to write headers would be for streaming the output from VRAM
<airlied>
rather than having the CPU write it to VRAM
<Lynne>
meh, we write first without even flushing and then let the encoder encode
<Lynne>
it's 317 bytes uploaded asynchronously
<Lynne>
*256, it's the alignment value
* airlied
will fix the rate control first then
<Lynne>
yeah, rate control, freeze when exiting and finding out how to ask the encoder nicely to not write SPS and PPS
<Lynne>
the thing is that you can't directly output from vram right now
<Lynne>
because of the offset -_-
<Lynne>
the spec should definitely either get rid of the offset or make it equal to the buffer offset
<airlied>
Lynne: oh I can just not output sps/pps that's easy
<airlied>
the driver pretty much fills them out
<Lynne>
good, I almost had a scare and thought the offset was designed to allow for users to delete sps/pps fields made by overeager encoders
Leopold_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: okay rate control parsing is hacked in
<airlied>
one annoying thing is I need the level idc earlier than I have the sps
<airlied>
I wonder could we change the api to add level idc to the profile or would that be bad
<Lynne>
in VkVideoEncodeH264ProfileInfoEXT?
<Lynne>
structs can't be bumped because it would break the ABI, right?
<Lynne>
there's a pNext field, a VkVideoEncodeH264LevelInfoEXT could be added
<Lynne>
oh, it's encode, so it's still unstable
<Lynne>
yeah, it can be changed
<Lynne>
...just as long as the profile requirement is dropped for frame creation
<Lynne>
I'm not creating hundreds of profiles+levels+codec combinations just to allocate an image because I don't know what it's going to be consumed by
<Lynne>
btw, I think you can just set the level to 6.2
<Lynne>
we set all the cap flags in the pps ourselves, which are based on level
<Lynne>
6.2 is the maximum level and leaves the user to make sure the level isn't exceeded (bitrate and #refs, mainly)
<airlied>
Lynne: uggh thought I could avoid sps/pps, but it appears to still emit them :(
<airlied>
might be some other bit controlling that I don't know about
<Lynne>
2 choices, either we have to emit SPSs and PPSs with a different ID and hope the encoder respects the SPS/PPS ids we're giving, and let the encoder-inserted sps/pps fields be noops
<Lynne>
or use the offset to trim them out
<airlied>
well I can ask the AMD hw team eventually if I can avoid it
<Lynne>
"You want to do WHAT?"
<Lynne>
I think having detailed docs would go a long way in hooking all the hardware's got
<airlied>
yeah I doubt they exist :-P
<Lynne>
they must, in some locale-encoded .doc file with proprietary/confidential watermarks
<airlied>
Lynne: I've added a workaround to my branch with a define to control it
<airlied>
removing SPS_PPS_WORKAROUND goes to the default behaviour which seems to emit badly formed things
<Lynne>
that just pipes the user-given IDs for the picture, right?
<Lynne>
the encoder still emits the fields
<airlied>
Lynne: it programs all the encoder fields manually
<airlied>
rather than letting the encoder do it which is what seems to happen in the normal case
<airlied>
I thought not manually programming them would make nothing happen, I was wron
<airlied>
wrong
<Lynne>
btw do you know why the freeze happens at the end of encoding?
<airlied>
not sure what is happening there
<airlied>
some fence not getting emitted or something?
<airlied>
wierd seem like we emit a syncobj 7 and wait on it but it doesn't signal
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<airlied>
Lynne: I suspect the hang will involve kernel debugging
<Lynne>
ah, difficult
<Lynne>
but hey, I know the linux kernel drm maintainer
<Lynne>
are you going to be around tomorrow or do you go offline? I should be about done with my rewrite
<airlied>
I'll be around but with kids to look after, so not as engaged
<airlied>
Lynne: where do we go next? more frame types?
<Lynne>
I thought about clean-ups and hooking more stuff up, but sure, why not, since we're encoding, we can make an easy scenario with only in-order P-frames and 1 ref
<Lynne>
I'll copy the vaapi code to build RefPicList0
<Lynne>
RefPicList1 is for B-frames, you can skip that
bmodem has joined #dri-devel
rmckeever has joined #dri-devel
cphealy has joined #dri-devel
cphealy_ has quit [Read error: No route to host]
ybogdano has quit [Ping timeout: 480 seconds]
anholt has joined #dri-devel
<airlied>
Lynne: not sure it's useful, but I wired up the tuning mode
<airlied>
and some basic encoder caps
bmodem1 has joined #dri-devel
lemonzest has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
* Lynne
still typing
<airlied>
oops something I did broke :-P
<airlied>
Lynne: oh you don't wire up VkVideoEncodeH264RateControlInfoEXT?
<airlied>
ah luckily it was some local changes mostly
<Lynne>
nope, not intending to wire it up either, going to wire up my own RC system instead
Leopold__ has joined #dri-devel
* Lynne
regrets doing all that automatic ref/object managment her vulkan utils code
<airlied>
it's just how I find out how many temporal layers you want
<airlied>
granted that info is also meant to match VkVideoEncodeRateControlInfoKHR->layerCount but the spec does seem to mention it
Leopold_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<Lynne>
just a single one, rate control temporal layers are meant for multi-stream encoding of different bitrates
<airlied>
Lynne: it appears you reset the syncobj that we subsequently wait on
<airlied>
so something submits it for signalling, then it gets reset later, then we wait on it
<Lynne>
we wait and reset the fence in ff_vk_wait_on_exec_ctx() called just before querying the results
<airlied>
so you do that, then you wait on that fence again
<Lynne>
I've burned every frame of park_joy and tractor in my mind
<airlied>
I think I'm pretty much done for today, I'll have some time tomorrow hopefully, but I think we've done pretty well!
paulk has quit [Ping timeout: 480 seconds]
<Lynne>
it's only 8am, too early for me to give up
paulk has joined #dri-devel
<Lynne>
I'll persevere for an hour to finish my threadsafe rewrite
<airlied>
Lynne: you should throw it at nvidia again :-P
<airlied>
I do wonder if they requires the pictureinfo struct or the rate control one
<Lynne>
I've tried and tried again last night, didn't work
<Lynne>
went as far as memory poisoning
<Lynne>
segfaults at 0x0, unless I put the slice header struct in pNext, not its dedicated field
<Lynne>
then it segfaults at 0x2
srslypascal is now known as Guest692
srslypascal has joined #dri-devel
<airlied>
ouch, I hate closed source
<Lynne>
my thoughts are: implement P-frames to one-up them, then they'll have to pay attention
<airlied>
we shall see what tomorrow brings!
<Lynne>
that, or an awkward talk with their boss "so how long did you spend working on your toy example and how long did it take for someone to beat it?"
<airlied>
I just threw out a blogpost to see!
<Lynne>
yup, it's decent
Guest692 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
junaid has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
bgs has joined #dri-devel
Johnny_ has joined #dri-devel
Johnny_ has quit []
lplc has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
Johnny has quit [Ping timeout: 480 seconds]
<Lynne>
exec system rewrite finished, just need to convert the decoder and encoder
lplc has joined #dri-devel
<kode54>
anyone else have any luck getting intel-clc and RT working? games with RT just tend to hang on a black screen here
Duke`` has joined #dri-devel
kts has quit [Quit: Leaving]
freemint has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
rasterman has joined #dri-devel
ahajda has joined #dri-devel
jkrzyszt has joined #dri-devel
mvlad has joined #dri-devel
elongbug has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
freemint has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
freemint has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<elongbug>
airlied: do you have any plan for merging Linux 6.2 rc1 to drm-next this week?
<elongbug>
There are patches that will be merged into drm-intel-gt-next, and they are dependent on Linux 6.2 rc1.
<elongbug>
(I heard that in order to merge Linux 6.2 rc1 into drm-intel-gt-next, it must be merged into drm-next first.)