<airlied>
Lynne: hey, doesn't fix it, but I think vulkan requires the 00,00,01 header on the bitstream data
<airlied>
at least the nvidia decoder seems to send it,
<airlied>
also one pps bug, you mix up the weighted_* flags
<DanaG>
I've also been having random GPU hangs on my WX 4100 with a Honeycomb ARM64 board. The last thing before the hang seemed to be: [drm:drm_sched_entity_push_job [gpu_sched]] *ERROR* Trying to push to a killed entity
<DanaG>
It's not the same thing every time, but most hangs seem to be after returning from idle, or upon VT switch (accidental or intentional).
camus has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
sdutt has joined #dri-devel
<DanaG>
I got the crash again with the aspeed. Looks like some things are null that shouldn't be null? fb_args = {width = 1024, height = 768, format = 875713112, handles = {0, 0, 0, 0}, offsets = {0, 0, 0, 0}, strides = {4096, 0, 0, 0}, modifiers = {0, 0, 0, 0}}
<DanaG>
No debug symbols for the upgraded libgbm, though.
<DanaG>
Mar 20 20:04:13 danaserver gnome-shell[400084]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: EGL failed to allocate resources for the requested operation.
sdutt has quit [Ping timeout: 480 seconds]
karolherbst_ has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tzimmermann_ has quit [Ping timeout: 480 seconds]
DanaG has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has joined #dri-devel
DanaG has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
illwieckz has joined #dri-devel
rgallaispou has joined #dri-devel
jkrzyszt has joined #dri-devel
OftenTimeConsuming has quit [resistance.oftc.net charm.oftc.net]
ahajda_ has joined #dri-devel
ahajda_ has quit []
ahajda_ has joined #dri-devel
ahajda_ has quit []
ahajda has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
lynxeye has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<Lynne>
ff_vk_create_buf already aligns to the min host-mappable size if the host_visible bit is set
<Lynne>
apart from that, I didn't have time to test on nvidia during the weekend, and I don't know if I'll have time today
mvlad has joined #dri-devel
jfalempe has joined #dri-devel
rkanwal has joined #dri-devel
<airlied>
Lynne: there are some vulkan video specific alignment requirements for video buffers
<airlied>
Lynne: are you doing something wierd with image allocations and aliasing?
<airlied>
my feeling on the corruption I see now after fixing those few little things, is that tiling is being used where it shouldn't (or the driver has some bugs in that area)
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<Lynne>
no, nothing weird, uses optimal tiling, the right image format as reported by the driver
<Lynne>
the allocation's in vulkan_decode.c
<Lynne>
the flags of the original image all have the 3 required flags set
<kbingham>
dianders, I think I recall you mentioned that you thought the "Add NO_CONNECTOR support" was blocked on Laurent, (Maybe I'm mis-remembering or confusing something there though), I see an RB tag from pinchartl at https://lore.kernel.org/all/YgHA1H2%2FRKcILTYv@pendragon.ideasonboard.com/ ... is there anything else blocking these series ? (Just trying to identify what topics block the SN65DSI86 HPD)
illwieckz has joined #dri-devel
shashanks has joined #dri-devel
bgs has joined #dri-devel
rkanwal1 has joined #dri-devel
rkanwal has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
kts has joined #dri-devel
rasterman has joined #dri-devel
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
nuh^ has joined #dri-devel
mclasen has joined #dri-devel
kts has joined #dri-devel
yogesh_m1 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
yogesh_mohan has quit [Ping timeout: 480 seconds]
camus has quit []
slattann has quit []
shankaru has quit [Quit: Leaving.]
rgallaispou has quit [Read error: Connection reset by peer]
<javierm>
I guess that was fell into the cracks but I'm not an authoritative person to answer I think
<javierm>
*just fell
toolchains has joined #dri-devel
<Lynne>
airlied: any ideas?
rgallaispou has joined #dri-devel
kts has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
dhanuka[m] has joined #dri-devel
macromorgan is now known as Guest2732
macromorgan has joined #dri-devel
rgallaispou has joined #dri-devel
toolchains has quit [Remote host closed the connection]
Guest2732 has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
fxkamd has joined #dri-devel
toolchains has quit [Remote host closed the connection]
karolherbst_ is now known as karolherbst
<karolherbst>
jekstrand: btw.. the CTS and CL are so annoying :( It's frustrating that the client can deadlock the runtime and I have no solution for preventing that from happening :/
mbrost has joined #dri-devel
<karolherbst>
so the client installs a user event as a dep for any new event, calls clFlush and now we have to wait for that user event to get fired (client either sets the status to CL_COMPLETE or an error)
Company has joined #dri-devel
<karolherbst>
I was thinking that we might be able to resolve this in cases the client releases the user event without having to set a status, but that won't fix clients which flush before releasing it
<karolherbst>
ehh
<karolherbst>
"clFinish" I mean, not flush
<jekstrand>
karolherbst: :-/
itoral has quit [Remote host closed the connection]
<karolherbst>
yeah.. I have a CTS test doing that because image operations are failing and it goes like "oh well.. I just abort"
<karolherbst>
and leaves the user events pending
itoral has joined #dri-devel
<karolherbst>
well the spec even says so that this stuff can happen
<jekstrand>
danvet: frankbinns deleted the DRM code from the IMG MR. Is that sufficient for you?
nchery has joined #dri-devel
toolchains has joined #dri-devel
itoral has quit [Remote host closed the connection]
<jekstrand>
I don't know how we're going to do CI without that code in-tree but I guess maybe CI can apply a patch.
<jekstrand>
airlied: ^^
shankaru has joined #dri-devel
toolchains has quit [Remote host closed the connection]
<danvet>
jekstrand, yeah that's maybe a bit much to be useful still, but imo ok
shankaru has quit [Read error: Connection reset by peer]
toolchains has quit [Remote host closed the connection]
<karolherbst>
nir_var_mem_global is 0x8000
<jekstrand>
danvet: what do you mean "a bit much to be useful"?
toolchains has joined #dri-devel
<danvet>
jekstrand, a bit much removal
<danvet>
i.e. the ci problem you point out
<jekstrand>
danvet: What else do you propose?
<danvet>
just nerf the loader
<jekstrand>
I mean, starting with it totally removed means we can punt the problem of dealing with non-upstream kernel interfaces to a different MR.
<danvet>
building is imo fine
<danvet>
but yeah if that works too
<jekstrand>
danvet: This is Vulkan, there is no loader.
<jekstrand>
danvet: Well, they do have a IMAGINATION_I_WANT_A_BROKEN_VULKAN_DRIVER environment variable you have to set.
<danvet>
well whatever the magic is to not have a working driver
imirkin has joined #dri-devel
<daniels>
jekstrand: mm, we upstreamed Panfrost with kbase, and freedreno with kgsl - is this not essentially the same?
<jekstrand>
daniels: Well, they also have a winsys back-end for their Android kernel driver.
<jekstrand>
So that would be the equivalent.
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
sdutt has joined #dri-devel
toolchai_ has joined #dri-devel
<danvet>
daniels, well zero chances kgsl or kbase ever get to upstream, so zero chance for upstream uapi regressions :-)
<jekstrand>
Well, yes.
<jekstrand>
danvet: I'm currently thinking I'll chat w/ airlied when he gets on in ~6 hours and if he's fine with the current state, I'll ACK the MR, ask frankbinns to squash, and we'll land it without any DRM code. Then we can figure out how to make CI work later.
<danvet>
yeah has my ack fwiw
<jekstrand>
Sounds good
toolchains has quit [Ping timeout: 480 seconds]
<danvet>
jekstrand, Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event <- if you're bored, some gpu reset semantics discussion you might care about
<danvet>
daniels, bbrezillon poke on that private drm/sched thread from mbrost
<danvet>
would be good to get your input too
<danvet>
plus anything you need that wasn't discussed yet, like your ctx limit or whatever it was
<daniels>
danvet: yeah, going to take a day or two to get to that
<daniels>
up against deadlines atm
toolchains has joined #dri-devel
nuh^ has quit [Ping timeout: 480 seconds]
toolcha__ has joined #dri-devel
toolchains has quit [Read error: Connection reset by peer]
<mbrost>
daniels: no rush, appreciate any input you have
<dianders>
kbingham: The blocker is that making NO_CONNECTOR work properly means implementing ti_sn_bridge_get_bpp() properly. Sam's series didn't do that. Said another way, patch #5 in his series is broken and patch #6 (the one you want) depends on patch #5.
toolchai_ has quit [Ping timeout: 480 seconds]
<kbingham>
dianders, Thanks for clarifying.
sdutt has quit []
sdutt has joined #dri-devel
<kbingham>
The next question is ... is it something that sravn already plans to work on to complete the series ...
mattrope has joined #dri-devel
toolcha__ has quit [Remote host closed the connection]
<kbingham>
dianders, Of course, I'm sorry - tagging sravn was to ask him not you ;-)
<dianders>
;-)
<zackr>
i was just pushing some vmwgfx fixes to drm-misc-next and dim can't rebuild drm-tip due to to conflicts in drm-intel-next (drivers/gpu/drm/i915/display/intel_bw.c and drivers/gpu/drm/i915/intel_pm.c). am I expected to resolve it or are intel folks aware of it?
<kbingham>
aha - that's where I remembered a 'laurents NAK' from.
khfeng has quit [Ping timeout: 480 seconds]
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
<zackr>
vsyrjala: ^ it's your changes ib drm-intel-next that seems to cause conflicts when rebuilding drm-tip. i'm not sure if i can resolve it properly
<vsyrjala>
i'll fix it up
<zackr>
thank you!
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Remote host closed the connection]
<bbrezillon>
mbrost, danvet: Didn't look much at the mali firmware (CSF) interface though, and the current panfrost driver doesn't need any of the fancy stuff you're trying to support, so I'm not sure my inputs will be super helpful there
<danvet>
bbrezillon, so maybe it's more for daniels to unburry himself
<bbrezillon>
for the second issue you're describing, as Andrey pointed it, using a custom workqueue is probably the cleanest solution
<vsyrjala>
zackr: done
<zackr>
vsyrjala: just noticed. thanks, i appreciate it
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
rgallaispou has quit [Read error: Connection reset by peer]
sdutt_ has joined #dri-devel
Haaninjo has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
fxkamd has quit []
<ajax>
can someone rewrite sse_minmax.c in portable vector builtins please
toolchains has joined #dri-devel
rkanwal1 has quit [Ping timeout: 480 seconds]
<ajax>
i guess a better question is how portable __attribute__((vector_size)) is
toolchains has quit [Ping timeout: 480 seconds]
prahal has joined #dri-devel
toolchains has joined #dri-devel
prahal_ has joined #dri-devel
<Company>
who is running testsuites on different GPUs?
<Company>
like, if there was a bug only reproducable on AMD in the Wayland GL code, would a testsuite catch that?
* MTCoster
Is there a way to generate a dEQP caselist for a previous Vulkan version? GLES has separate lists for different versions, but there's only one for Vulkan and it seems to be for 1.3. Do I just need to grab an old version from the git history?
<MTCoster>
Is there a way to generate a dEQP caselist for a previous Vulkan version? GLES has separate lists for different versions, but there's only one for Vulkan and it seems to be for 1.3. Do I just need to grab an old version from the git history?
jamesjones has joined #dri-devel
<bnieuwenhuizen>
MTCoster: just run the latest. The tests have checks for which vulkan version is supported
prahal has left #dri-devel [#dri-devel]
<MTCoster>
bnieuwenhuizen: Ah perfect, thanks!
<bnieuwenhuizen>
just make sure your driver doesn't expose e.g. 1.3 when it isn't supported yet etc.
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<anholt>
Company: we run deqp and piglit on a variety of gpus pre-merge in Mesa's CI. wayland currently doesn't have coverage in that, just X11.
prahal_ has quit []
<anholt>
MTCoster: you use the current caselist for the testsuite. it doesn't require that you do 1.3, just that if you say you do 1.3, you actually do it.
prahal_ has joined #dri-devel
<Company>
I'm getting a GL_FRAMEBUFFER_UNDEFINED when trying to use high bit depth on some GPUs
<anholt>
Company: UNSUPPORTED, maybe?
<Company>
yeah, either my code fails to setup something properly
<Company>
or the Wayland code does
<MTCoster>
anholt: Thanks! That wasn't clear from the docs, especially the wiki page that talks about dEQP releases being tied to Vulkan versions
<vsyrjala>
swick: yeah. it might be possible to support it, but there was some concern whether earlier hw had enough space in its magic buffer for the hdr metadata. dunno if anyone actually checked that
<swick>
vsyrjala: there also is some lspcon stuff which attaches the property. that's only eDP?
<vsyrjala>
it's only for an onboard DP->HDMI LSPCON chip
<vsyrjala>
hmm. where do we actually write the metadata in that case...
<swick>
hsw_write_infoframe
<swick>
so, eDP has no special handling wrt the hdr infoframe stuff
<vsyrjala>
looks like we do stuff it into the gmp dip. so that kinda implies it has enough space
sdutt has quit [Ping timeout: 480 seconds]
<vsyrjala>
assuming someone actually tested that lspcon code
mvlad has quit [Quit: Leaving]
<swick>
the device supposedly supports HDR with windows
<swick>
but tbh I'm not sure if the panel in the model I have actually does support HDR
<vsyrjala>
edid-decode should be able to tell
<swick>
the EDID has only the base block
<swick>
but I'm also not sure if there is a side channel I'm not aware of, maybe for DisplayID
<vsyrjala>
displayid in theory could be at a different i2c address iirc. but dunno if it would then be legal to also have the edid
<vsyrjala>
iirc all machines i've seen have the displayid in the edid ext block
<swick>
okay, so that's very unlikely then
<swick>
so, the panel probably doesn't support HDR and the driver doesn't support HDR either but maybe could
<vsyrjala>
yeah, we could probably just register the property on earlier hw as well
sdutt has joined #dri-devel
<swick>
vsyrjala: the weird thing is that the EDID doesn't even have a CTA ext
<swick>
is that common for embedded panels? do they have other mechanisms to communicate all of that stuff?
<Lyude>
btw danvet, feel free to let me know if you happen to think of any nice solutions to the encoder issues w/r/t MST we were talking about before, I've been trying to think of some but I honestly haven't been able to figure out any sensible sounding ways of properly tracking encoders that are indirectly being used by fake MST encoders. hopefully I'll come up with something soon, but
<Lyude>
ideas welcome :)
pnowack has quit [Quit: pnowack]
<vsyrjala>
swick: i think unless you have hdr or some high refresh rate panel just having the base blocks is pretty common
<swick>
alright, thanks
<vsyrjala>
Lyude: what you trying to with non-mst encoders?
LexSfX has quit []
sdutt has quit [Ping timeout: 480 seconds]
<Lyude>
vsyrjala: no, it's with MST encoders, ish. Basically in trying to figure out the parallel modesetting issues (e.g. where if a driver tried to do a parallel modeset that ended up say, using the normal encoder on a DP port to try to run a display on a connector that was previously hosting an MST topology, there's a chance we might start the commit before the real video encoder
<Lyude>
previously used by the topology is ready, as a result of us not correctly determining all of the CRTCs that need to be waited on in order to be able to use an encoder again
gouchi has joined #dri-devel
<Lyude>
which mainly happens because things like steal_encoders might not work considering if we have a display on an MST topology, we count it as being connected to a fake encoder - which means different drm_encoder struct, which means the core wouldn't notice that we're actually trying to steal an encoder
LexSfX has joined #dri-devel
<Lyude>
let me know if that doesn't sound like it makes sense, it honestly took me a few tries to understand what danvet was referring to with this
<vsyrjala>
i guess encoder stealing + mst could be borked atm. i915 at least should spot the conflict and report an error. but that would mean no actual stealing
<Lyude>
yeah. I think getting this right would probably help us with solving making sure we're waiting on the right CRTCs after an MST modeset as well, but I'm somewhat at a loss as to how to cleanly fix this atm
<Lyude>
(this is all still for my work with trying to make mst fully atomic so we can finally have proper bandwidth management, jfyi)
<Lyude>
It's a bit painful we have to expose this kinda encoder info to userspace, since it definitely feels like to me that with stuff like this I'm not sure it makes sense for a drm_encoder to be limited to a single CRTC
<vsyrjala>
i guess you add a mgt->encoder that would point back to the sst encoder?
idr has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<Lyude>
vsyrjala: yeah-that's one part, but then we need to figure out how to encorporate that into say - a commit that tries to use the sst connector, and doesn't trigger anything which would itself pull in the MST state. One thing I'm wondering if maybe ->best_encoder could possibly be used for something like that…
<Lyude>
I also considered potentially making it so that maybe we could teach the DRM core to understand that DRM connectors can have best_encoder without a CRTC in certain scenarios, but that seems like a potentially risky and involved change
<vsyrjala>
hmm. well could stick the parent encoder pointer into the mst encoders maybe. but that would then require the mst encoders are tied to that specific parent encoder/mgr
<vsyrjala>
which is how i915 behaves atm. dunno if that's how other drivers work
LexSfX has quit []
<vsyrjala>
though i must admit to foretting how the encoder stealing code actually works atm
danvet has joined #dri-devel
cphealy has quit [Read error: Connection reset by peer]
cphealy has joined #dri-devel
LexSfX has joined #dri-devel
<Lyude>
yeah, nouveau doesn't have mst encoders tied to hw encoders (mainly because then we end up creating way too many encoders), but we could potentially maybe fix that with private objects to keep track of the fake mst encoder->real encoder mappings or something - not entirely sure
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
danvet has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
<airlied>
Lynne: removed a tiling thing from the driver, I can now see the basics of the jellyfish test video
<Lyude>
vsyrjala: hm, have a sort of idea that I'm not sure yet how well it'll work: adding new fields to drm_connector_state to mark a connector as "reserved", use conn_state->best_encoder to indicate which SST connector is being used, and add conn_state->reserved_crtcs to indicate which CRTCs are reserved by a connector but aren't being directly used by it (to make sure that we can
<Lyude>
always go over the CRTCs that depend on a MST topology, even if the topology private object isn't yet in the atomic state)
lstrano has joined #dri-devel
<Lyude>
sorry, *indicate which SST encoder being used, not SST connector
<Lynne>
we argued over for a while about the weighted bipred flag over at #ffmpeg-devel, and it seems we were wrong
<airlied>
but doing that trips an assert
<airlied>
and I think that's ffmpeg code fault
<Lynne>
what do you mean?
<Lynne>
I don't remember a requirement to make decoder images linear
<Lynne>
afaik they were required to be tiled optimal
<airlied>
Lynne: yes but currently optimal tiling for the radv hw is linear aligned
<airlied>
I'm however not sure if that is an actual hw limitation or just lazy driver code I took from the vaapi driver
mbrost has quit [Ping timeout: 480 seconds]
<airlied>
I'll be back in 1.5hrs or so to dig in further
<Lynne>
ktnx
Haaninjo has quit [Quit: Ex-Chat]
<Lyude>
vsyrjala: yeah - not 100% sure until I actually have some code written, but I -think- this might be on the right track *crosses fingers*
DanaG has joined #dri-devel
DanaG has quit [Remote host closed the connection]
<jekstrand>
airlied: frankbinns deleted the DRM code from the IMG MR. Is that enough for you to not be worried about uAPI breakage for now?
<jekstrand>
airlied: Trying to get enough consensus that I feel comfortable acking something so they can land and start working upstream.
maxzor has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
maxzor has quit []
gouchi has quit [Remote host closed the connection]
DanaG has joined #dri-devel
bgs has quit [Remote host closed the connection]
bgs has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
rkanwal has quit []
<Lynne>
airlied: removing the compute queue layout change and doing it in the decode queue fixed artifacts quite a bit
<Lynne>
decoding an all-intra image has the same artifacts, so I don't think p/b frames have anything to do with it
<Lynne>
every 4 images, the decoded image does look right, except for a single strip of corrupt blocks
<Lynne>
ah, that's per plane
<Lynne>
so every 4 images, each plane looks correct, except for 2 strips of corrupt blocks
<Lynne>
but when a plane looks correct, the other planes do not, so it never matches up
<Lynne>
this sounds to me like some sort of synchronization issue
<Lynne>
hmm, when the u plane is correct, the v plane is also correct, this does sound like some sort of a sync issue
OftenTimeConsuming is now known as Guest2758
OftenTimeConsuming has joined #dri-devel
Guest2758 has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: so I think the radv patch is right, it needs to be allocated as linear internally
<airlied>
the question is why ffmpeg code isn't allocate the correct memory size in that case
<airlied>
since it should be using vkGetImageMemoryRequirements
<Lynne>
how does that communicate to the driver the allocation must be linear?
<Lynne>
memorybits?
<airlied>
Lynne: the driver shouldn't care
<airlied>
sorry the app shouldn't care
<airlied>
the app just creates an image asking for optimal tiled, it gets back the memory requirements which has the size needed
<airlied>
everything else should be internal to the driver
<airlied>
except in this case the size the app gets back isn't being used everywhere
<airlied>
might be something to do with external memory there
<Lynne>
ah, I see
<Lynne>
keep in mind that by default currently (not in the video_decode branch), we allocate all images with DRM tiling, to allow for interoperability with other APIs
<Lynne>
not sure if that'll matter once everything's working
<airlied>
Lynne: at that point modifiers should be used I think
<airlied>
like if it worked with vaapi it should work here, since the vaapi driver also does linear
<Lynne>
that sounds fine then
macromorgan is now known as Guest2762
macromorgan has joined #dri-devel
alatiera has quit [Quit: Ping timeout (120 seconds)]
<Lynne>
as for the image corruption, got any ideas? I checked the sps/pps parts, and to my best knowledge, they're accurate now
alatiera has joined #dri-devel
Guest2762 has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
<airlied>
Lynne: nope not yet, but it might be a sync issue alright, the decode queues are messy to sync on
oneforall2 has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
<Lynne>
yeah, I bet so
<Lynne>
some hwaccels have issues with seeking, where they decode the luma planes first, so players present the correct luma on seek but with the old frame's chroma
ybogdano has quit [Ping timeout: 480 seconds]
<Lynne>
I forget where that happened, I think it might've been VAAPI on AMD with 10bit hevc
khfeng has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
oneforall2 has joined #dri-devel
pcercuei has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]