ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Company has quit [Quit: Leaving]
<kindergarden>
https://oregonoutdoorfamily.com/bee-stings-allergy-infection/ same thing, but i was dosed with oral ones and played table tennis with blood poisoning and line was clearer, there was no pain i was under though, but it was known to everyone except me it was blood poisoning my coach knew that
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<kindergarden>
you want to tell me more of poetry how powerful and functional you are as supreme CHARL fucker cunt, who can not even cope with another man walking on sand ? be allone tolerate lethal amounts or combinations of meds, you are crazy
<kindergarden>
you can not even succeed in your first degree murder in 100attempts
<kindergarden>
i put you off instantly with one similar dose or attempt
amarsh04 has joined #dri-devel
pcercuei has quit [Quit: dodo]
amarsh04 has quit []
kindergarden was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
amarsh04 has joined #dri-devel
zxrom has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
flynnjiang has joined #dri-devel
RAOF_ has joined #dri-devel
RAOF has quit [Ping timeout: 480 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
yyds has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
hypermodesatbest has joined #dri-devel
<hypermodesatbest>
and btw. especially my dad and some other gangster monster fraudsters, they jam you with one second using sound waves released, something that makes you sick so bad that you hang yourself, along the lines of why do not you work out your belly, they still scam that stuff , just amazing when i have maximum amount of antipsychiotics and everyone knows that its not possible to lose weight, even if you play 5 tournaments during
<hypermodesatbest>
half a year, and more importantly every time i quit i am back to normal range. You are same genetic garbage , yes i am sensitive to endless absurd and projections released by abortion leftovers who talk they are big deals. So once again, i am not anymore interested in the girl who delt sexuallly with wrong people, i aint deal with such person who humiliated me 2.5 years it's not the person i need in my life, endless cheatings
<hypermodesatbest>
endless trash people she deals with, let her cure her aids and ado her abortions in her own locations, you have no writes to relate me with such idiots. Since you did, i expect you get knocked down quite soon probably if you did, the island people, are all soon reported dead.
Jeremy_Rand_Talos was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
hypermodesatbest was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<airlied>
oops sorry got tab completed badly
<HdkR>
Oh no, Jeremy Rand!
sukuna has quit [Remote host closed the connection]
sincerelynotyours has joined #dri-devel
<Lynne>
airlied: I'm looking into porting av1's decoding to use reference frame names instead of frame_ids that we generate ourselves
<Lynne>
and I don't get it
<Lynne>
the spec says that every frame's slotIndex must be unique and must be found in the list of active references (referenceNameSlotIndices)
<Lynne>
*every reference
sincerelynotyours has quit [Remote host closed the connection]
<Lynne>
but at the same time, our current code assumes that the slotIndex will never change, while a reference's slot index will
<Lynne>
how does CTS even work?
<airlied>
why would a references slot index change?
<airlied>
it has to stay where it's put until it not used anymore
<airlied>
I don't think you can use av1 reference names here
<airlied>
assuming you mean LAST/ALTREF etc
<airlied>
ref_frame_idx maps from the 7 names to a list of references for that frame (up to 8)
<airlied>
but you can have more than 8 slots because a frame might not actively use a reference, but the next one might
sincerelynotyours has joined #dri-devel
<Lynne>
airlied: the spec does say that referenceNameSlotIndices must be LAST/ALTREF/GOLDEN, etc
<Lynne>
since there's just 8 types (counting 0, the current decoded frame's name), I don't think that should work at all with more than 8 slots
<Lynne>
the slots do change frame to frame too, the 0th frame (current) becomes LAST on the next frame
<airlied>
Lynne: yeah so that maps the 0..7 through ref_frame_idx into slotIndexes
sincerelynotyours has quit [Remote host closed the connection]
<airlied>
so you should end up with a slot index for each reference frame name
tabulanebula has joined #dri-devel
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<Lynne>
does the order of references matter in the way they're given to the decoder?
<Lynne>
currently I get crahes on all vendors
<airlied>
Lynne: in the map?
<airlied>
yes
<Lynne>
no, in the pointers themselves
<Lynne>
for reference frames that don't exist, I still provide a reference that increments the number of refernces (so I always give 7 refs in total to the decoder, but any disabled ones, I use slotIndex = -1 with a null resource as the spec requires)
<airlied>
you shouldn't do that
<airlied>
the -1 should go in the map
<airlied>
you just provide referenceslots for the actual things in the DPB
<airlied>
so if you have say just an INTRA_FRAME and LAST_FRAME and no LAST2_FRAME LAST3_FRAME etc, then the map would be [slot_index_a, slot_index_b, -1, -1, -1, -1, -1]
<airlied>
then provide 2 reference slots if a/b are different
<airlied>
with the slots into the DPB that are per frame
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<Lynne>
if I don't, radv asserts
<Lynne>
btw, does a map of all zeroes make sense? it should, it just means the frame gets splat'd across all refs, right?
tabulanebula has quit [Remote host closed the connection]
<airlied>
Lynne: yes all 7 refs would point to slot 0, happens a lot in 2nd/3rd frames
Omax has quit [Ping timeout: 480 seconds]
tabulanebula has joined #dri-devel
tabulanebula has quit [Remote host closed the connection]
<Lynne>
so does the assert make sense or?
tabulanebula has joined #dri-devel
<Lynne>
as far as I read it, it requires that all references are always present
Omax has joined #dri-devel
<Lynne>
and my reading of the spec does also follow that
<zzoon[m]>
that's my understanding too.
<airlied>
present where?
<airlied>
referenceNameSlotIndices is an array of seven (VK_MAX_VIDEO_AV1_REFERENCES_PER_FRAME_KHR, which is equal to the Video Std definition STD_VIDEO_AV1_REFS_PER_FRAME) signed integer values specifying the index of the DPB slot or a negative integer value for each AV1 reference name used for inter coding.
<airlied>
though maybe that means they all have to point at 0
<airlied>
though I think they come from the av1 file, we don't control that
tabulanebula has quit [Remote host closed the connection]
<airlied>
I think it turns out all 7 are always there after the first frame anyways
<Lynne>
yes, but I'm talking about the list of references, not the map
<airlied>
so you think we should provide all active references whether referenced or not for each frame?
<airlied>
tchar: would have to clarify, but I think he said previously here that was rejected
<airlied>
"tchar: airlied: isn't that currently the case? the complete dpb state being the current frame and all its unique dependent frames. The idea of putting the whole "VBI" in the API was rejected "
<airlied>
Lynne: so the current working code doesn't hit the assert? so what do you do different (or are you hitting it now?)
tabulanebula has joined #dri-devel
tabulanebula has quit []
heat has quit [Ping timeout: 480 seconds]
tabulanebula has joined #dri-devel
<tabulanebula>
tabulanebula>Lynne: there is no point in talking to this aids shithead, he is not only retarded. but you might find kapo to be at work at saving you from the explosives they blast. tabulanebula> https://www.nobelprize.org/prizes/medicine/2022/paabo/lecture/ mad world, so once again what a set of monkeys complete vomit and abuse was honored with 7million dollars, those trashes design shape changes with estonian and finnish doctors t
<dwfreed>
ugh
tabulanebula was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<dwfreed>
banning him isn't helpful; if you see me say something after him, I've "handled" it
<Lynne>
airlied: I'm not hitting it
<Lynne>
with the current working code, but if I skip -1 refs, I do
<airlied>
dwfreed: can you actually block him effectively, his persistence is admirable
<airlied>
dwfreed: add a ? in there :-)
<airlied>
Lynne: what does skipping -1 refs look like in code?
<airlied>
like I'm filling in -1 refs now?
<dwfreed>
airlied: I've done a few things that should help
<Lynne>
airlied: if (ref is missing) { continue } else { fill_pict, nb_refs++ }
truckwithlights has joined #dri-devel
<truckwithlights>
Lynne: there is no point in talking to this aids shithead, he is not only retarded. but you might find kapo to be at work at saving you from the explosives they blast. https://www.nobelprize.org/prizes/medicine/2022/paabo/lecture/ mad world, so once again what a set of monkeys complete vomit and abuse was honored with 7million dollars, those trashes design shape changes with estonian and finnish doctors to estonian kids to suffer under
<dwfreed>
ugh
<HdkR>
:)
bmodem has joined #dri-devel
<airlied>
Lynne: isn't that what it does now? if the ref frame is none, it continues, otherwise fills in the info
<airlied>
after deduplicating
<Lynne>
actually yeah...
<Lynne>
but what *does* that assert do?
<airlied>
the assert is because the amd fw is messed up
<airlied>
so we have to lie to it
<airlied>
it can either mean the API usage is wrong or the internal attempt to fix the fw is wrong
<Lynne>
to my understanding, this is what the spec expects
<Lynne>
I don't trigger the assert, but I do crash on both implementations
<Lynne>
with or without a continue in if (s->ref[i].f->pict_type == AV_PICTURE_TYPE_NONE)
<Lynne>
could you look at it and see if it makes sense?
aravind has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
truckwithlights has quit [Remote host closed the connection]
<airlied>
Lynne: no that doesn't make sense
<airlied>
the current code makes sense afaik
bmodem has joined #dri-devel
<airlied>
you have to manage the DPB slots not the reference indexes
<airlied>
so if you decode a reference frame, you have to use that slot index in all future decodes referencing that slot
<airlied>
not the AV1 referenecs
<airlied>
so you can't just use slot 0 for the current frame decode
<Lynne>
but the vulkan spec says referenceNameSlotIndices must contain LAST/GOLD, etc, and also says that each frame's slotIndex must be contained in referenceNameSlotIndices
<airlied>
no referenceNameSlotIndices is a mapping *to* LAST/GOLD etc
<Lynne>
did we mess up bigtime?
<airlied>
from slot
<Lynne>
err, really?
<airlied>
so referenceNameSlotIndices[LAST] = slotIdx
<airlied>
(or -1) if not used
<Lynne>
so by index to a reference frame they really mean an index in the last... N decoded frames I guess, not a named reference?
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
<Lynne>
so *that's* why the decoder checks 32 indices for the id_alloc_mask
<Lynne>
still, 32 is rather arbitrary
<Lynne>
why not 64 or 16?
<airlied>
32 is probably a bit large
<airlied>
that was just an easy uint32_t choice
<airlied>
it's just the DPB index
<airlied>
I think we advertise max 16 dpb slots there
<airlied>
you have to allocate those slots to images for as long as they live
* airlied
isn't sure I've seen it go over 9 or 10
<airlied>
if the ffmpeg code was like the h264 code we'd just use the index of the DPB reference
oldbelmondo has joined #dri-devel
oldbelmondo has quit [Remote host closed the connection]
<Lynne>
would you mind replying to jkqxz on the ffmpeg ml? maybe we could change the decoder while it still hasn't grown large
<Company>
the only flag I don't have in GL is DEVICE_LOCAL, but I don't even understand what happens if I go for DEVICE_LOCAL | HOST_CACHED
<Company>
also, I tested it a bit and it seemd to make Vulkan slower
<MrCooper>
that combination isn't available with AMD GPUs, is it?
<Company>
good question - I don't have my AMD booted so can't check
<MrCooper>
it's more of a rhetorical question :)
<MrCooper>
also, if there are CPU reads, DEVICE_LOCAL is bad
<Company>
there usually aren't - but the benchmark does indeed use them
sgruszka has joined #dri-devel
<Company>
I guess I should check with DEVICE_LOCAL and a different benchmark
<Company>
still, the GL usage is the same, and GL is faster
<Company>
and apparently DEVICE_LOCAL | HOST_CACHED is indeed not a thing
<Company>
that's good for my sanity
<Company>
i guess for vertex buffers, we should ultimately be using DEVICE_LOCAL and write-only
<Company>
or is that bad when we write the data in chunks?
heat has joined #dri-devel
<MrCooper>
should be fine as long as the writes fill the write-combine buffers
<Company>
I don't know where this stuff should go, because it's written once in 20-50 byte chunks when creating the instructions and then it's read in the same chunks I guess when the GPU processes the instructions
<MrCooper>
though note that the gain from DEVICE_LOCAL vs. uncacheable system memory is minor, doing something sub-optimal with DEVICE_LOCAL will likely hurt more than that
<MrCooper>
well, that's for streaming data, anyway; if the GPU uses the data multiple times, the balance shifts in favour of DEVICE_LOCAL
<Company>
right
<Company>
at some point I need to learn how memory actually works instead of just having the mental model I made up via experience
<Company>
and all this work just so that people can smoothly scroll a fullscreen gnome-terminal with a tiny font size at 144Hz...
<MrCooper>
Company: someone who's more of a Vulkan expert than me might notice things GTK could do better
yyds has quit [Remote host closed the connection]
zxrom has joined #dri-devel
<Company>
MrCooper: (and everyone else) that reminds me: We plan to switch GTK development to Vulkan by default after the Gnome/Fedora releases are out and people settle back into development
<Company>
which should lead to people finding lots of Vulkan bugs
<MrCooper>
cool
<Company>
I hope that works fine but I know Vulkan is less vetted than GL
<Company>
like Intel's YUV
bmodem has joined #dri-devel
guludo has joined #dri-devel
warpme has joined #dri-devel
pcercuei has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
warpme has quit []
kts has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
kts has quit [Quit: Konversation terminated!]
aravind has joined #dri-devel
mlankhorst has joined #dri-devel
ManMower has joined #dri-devel
newstrategy has joined #dri-devel
jsa has joined #dri-devel
davispuh has joined #dri-devel
newstrategy has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
<mripard>
pq, emersion: for display interfaces that can support multiple formats (like HDMI with RGB and its YUV variants), do you know if it's preferrable to lower bpc and try to use RGB always, or if it's best to try to match the bpc as much as possible at the expense of selecting another format?
<emersion>
i have no idea
<emersion>
maybe vsyrjala knows
<emersion>
ideally user-space would be able to select…
<pq>
match bpc to what? you mean use highest possible?
<swick[m]>
we don't have any other bpc
<swick[m]>
(from user space)
newstrategy has joined #dri-devel
<emersion>
i understood the question as "is it better to lower the bpc or switch to YUV?"
<swick[m]>
the answer is that user space should be in control, but isn't, so do whatever you want
<swick[m]>
someone will not be happy
<pq>
so it's a trade-off between per-sample color precision and per-pixel sampling (spatial precision). I suspect which one is preferable depends on the use case.
<mripard>
emersion: yeah, that's what I meant, and it started from a discussion with vsyrjala indeed :)
<pq>
I'm assuming YUV also implies chroma sub-sampling.
<mripard>
yep, we're discussing YUV422
<pq>
I really have no experience to give any generic rule of thumb.
<emersion>
right, so RGB would be better for text content, and YUV for video content?
newstrategy has quit [Remote host closed the connection]
<emersion>
i suppose it's not possible to switch between RGB and YUV without a modeset?
<swick[m]>
no
<pq>
If your content is video or photos, I think high bpc YUV would be better than lower bpc RGB. If your context is GUI graphics and text, then the opposite.
<zamundaaa[m]>
mripard: I would expect most desktop PC users to rather have lower bpc instead of chroma subsampling
<swick[m]>
except if you have enough resolution, then chroma subsampling doesn't matter
<swick[m]>
GUIs often have gradients where the bitdepth can be relevant
<emersion>
you mean HiDPI?
<swick[m]>
but yes, I also tend to prefer RGB, but that's my person preference
<mripard>
zamundaaa[m]: so, generally speaking, we could consider YUV as a fallback-only solution, but try to use RGB at all (bpc) cost prior, right?
<emersion>
maybe the screen is high res (4k), but maybe the screen is very large
<mripard>
(until we have a proper uAPI to expose the formats that is)
<pq>
would you agree that whatever is picked, should not be made conditional based on e.g. CRTC size (resolution)?
<swick[m]>
yes
<zamundaaa[m]>
mripard: like swick said, only down to some bpc
babyfaceold has joined #dri-devel
babyfaceold was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<pq>
niiice
<swick[m]>
really, this is all a bit pointless because it should be in control of user space
<pq>
right
<emersion>
if RGB/YUV could be switched without a modeset, would be interesting to decide based on "content type" prop
<swick[m]>
please don't
<emersion>
i mean, does it matter?
<mripard>
emersion: I'm pretty sure you'd need a modeset for most if not all drivers
<pq>
so what's the choice of least surprise? I would claim "RGB even if it means lower bpc"
<swick[m]>
same
<emersion>
if a modeset is needed, i think generic compositors will almost always want to unconditionally pick RGB
<pq>
and once userspace actually can choose between RGB and YUV, that will fix those use cases that are unhappy with this default.
<mripard>
ack, so it looks we have a consensus here :)
<zamundaaa[m]>
I would maybe change that decision when it comes to HDR though
<swick[m]>
please for the love of god, no
<zamundaaa[m]>
Going below 8bpc with PQ would not be good
karolherbst_ has joined #dri-devel
<swick[m]>
let's not make all the legacy stuff not even more complicated
karolherbst_ is now known as some_bot
<mripard>
yeah, I agree, we should stick to something simple that can be easily documented
<swick[m]>
if user space needs a specific bit depth it should be able to tell the kernel
<zamundaaa[m]>
swick: that "legacy" stuff is what people are using right now. It must at the very least not be made worse vs the status quo.
<zamundaaa[m]>
Idk what that status quo is though
<emersion>
driver-specific
<mripard>
yep, that's what I'm trying to improve
<emersion>
AMD will pick YUV in some cases, pretty sure
<emersion>
(cc hwentlan_ ^)
<mripard>
i915 uses YUV420 when required, RGB otherwise
<swick[m]>
the legacy stuff is also completely broken
<zamundaaa[m]>
I know that amdgpu picks subsampling over reducing the bpc with my TV, and changing that would almost certainly cause banding on it with HDR
<swick[m]>
if it works, it's by accident, not because the documented behavior can give you working hddr
<mripard>
dw-hdmi uses YUV420 when required, and then will favor YUV422 and YUV444 before RGB for each bpc, but I'm pretty sure that the logic is broken and they will always end up using RGB 8bpc
<swick[m]>
zamundaaa: too bad, fix up the uapi
<swick[m]>
this mindset of "the kernel must magically do all the things I want" really not helpful
<emersion>
swick[m]: sounds like you volunteer? :D
<swick[m]>
I am trying to do this
some_bot has left #dri-devel [#dri-devel]
<zamundaaa[m]>
You shouldn't break the old behavior before uAPI is fixed... The order of things is important there
<emersion>
please also avoid asking people to "just" "fix up the uapi"
<emersion>
it's a huge chunk of work
<swick[m]>
that's part of the the color pipeline API allows us to do
<swick[m]>
I'm well aware
<swick[m]>
I'm just saying people shouldn't make the current situation worse to fix
<pq>
mripard, what are you doing that made you ask this question in the first place?
<emersion>
wording such as "we should fix the uapi" is better than "you, fix the uapi"
<pq>
is this still about sharing the HDMI setup code between all drivers?
<mripard>
pq: yes
<pq>
hmm
<pq>
and drivers naturally disagree
<mripard>
like emersion was saying, it's all a big mess right now and I'm trying to put that logic in a common place to avoid drivers screwing up and coming with yet another variant
<mripard>
there's not much of a disagreement, just that it's not clear what the best behaviour is
<mripard>
but it looks like there's a consensus, which is also aligned with i915 so it looks like it's also the most conservative option
<pq>
but then, *our opinions* are kinda irrelevant, too, because kernel regressions are the thing you need to avoid as much as possible. So I think you need to choose a consensus algorithm from the existing driver behavior, and *if* there are ties, then use our opinions to solve them. And hope no-one screams "regression".
<mripard>
I think it's very much relevant, but also because it kind of depends on what regression means here. Given that it's all a big mess right now, we won't be able to come up with something that doesn't change the current format selection for anyone. So we should still strive to get something decent.
<pq>
right
ghishadow has quit []
<mripard>
so if regression means "my screen is black now" then yeah, it's bad. if it means "I used to have YUV but now I get RGB with a lower bpc", I'm not sure we should consider it one
<mripard>
and since it's opt-in, we can still revert the commit for that one particular driver if someone complains
<vsyrjala>
in i915 we go as far as offloading the rgb->ycbcr 4:2:0 conversion to an external dp dongle if possible. outputting rgb avoids having to play annoying tricks with gamma/csc/scalers/etc. on certain classes of hardware
<pq>
mripard, yeah, I never know where the line is for what's a kernel regression and what's not. Happy to leave that to sub-sys maintainers.
<pq>
I just presume the worst from kernel developer perspective.
ghishadow has joined #dri-devel
severeillies has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
dorcaslitunya has joined #dri-devel
mvlad has joined #dri-devel
frieder has joined #dri-devel
guludo has quit [Quit: WeeChat 4.2.1]
ghishadow has quit [Remote host closed the connection]
<grillo_0>
melissawen, mairacanal: About the bg color TODO, so maybe would be good to remove it?
<emersion>
grillo_0, melissawen, mairacanal: i wanted to type uAPI but then realized it was more tricky than it seems
<emersion>
namely, if i want to draw a solid color, i would need to try first the solid color prop, and then fallback to buffer if the driver rejects that
<emersion>
that doesn't really work like the rest of the props (if i can't use a plane, i will composite it with GL/Vulkan)
jackspublictoilet has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
ninjaaaaa has quit [Ping timeout: 480 seconds]
ninjaaaaa has joined #dri-devel
simondnnsn has joined #dri-devel
<zamundaaa[m]>
What would the use case for the crtc background color be btw? I can't think of anything that isn't a really specific edge case
<emersion>
some people configure swaybg with a solid color, for instance
<emersion>
a terminal emulator or text editor or web browser could take advantage of it, maybe
jackspublictoilet has quit [Remote host closed the connection]
jackspublictoilet has joined #dri-devel
frieder has joined #dri-devel
jackspublictoilet has quit [Remote host closed the connection]
amarsh04 has joined #dri-devel
<Company>
MrCooper: fun fact: zink is faster than my Vulkan renderer, so I must be doing *something* wrong :)
<ccr>
~ zink magic ~
<Company>
I like zink, because whenever it's faster than either my GL or my Vulkan code, I know something is going wrong somewhere
<Company>
I much prefer it to be faster than the GL code, because that's usually a drvier bug and not my fault
<pq>
zamundaaa[m], the preferred background for watching scale-preserved fullscreen photos is probably not black but dim. Perhaps for movies as well.
dorcaslitunya has quit [Remote host closed the connection]
<zamundaaa[m]>
thanks, those make sense
eocwzdenn^ has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
ghishadow has joined #dri-devel
itoral has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
Company: not sure what "zink is faster than the GL code" means, faster than a non-zink GL driver?
<Company>
I've had zink be faster than the regular driver on my benchmarks once or twice
<Company>
usually that means that Mesa's vulkan driver is better than the GL driver at something
<Company>
for now I'm just confused, I even made sure they use the same memory type - maybe it's something else that's breaking here
<MrCooper>
Company: then it still using your GL code though, so not "faster than it"
<MrCooper>
just faster than the other GL driver
<Company>
yeah
<Company>
though technically it could hit different codepaths in my GL code, too
<mripard>
sima: assuming we would access drm_connector.state outside of the modesetting path (debugfs), which locks does one need to take? drm_mode_config.connection_mutex only or is there something else?
simondnnsn has quit [Ping timeout: 480 seconds]
ninjaaaaa has quit [Ping timeout: 480 seconds]
ninjaaaaa has joined #dri-devel
<sima>
mripard, if you call the drm_get*_state functions they'll take the right locks
simondnnsn has joined #dri-devel
<sima>
but yeah for just reading that one is the right one, and the various GET* ioctl we also open code that so should be fine for debugfs
<Company>
pq: do you want 1 1D LUT or 2 1D LUTs (one at the start, one at the end)?
<Company>
because that paper kinda feels like the 1D LUT is just to (de)gamma the pixels
<pq>
Company, it's three 1D LUT and then one 3D LUT.
<pinchartl>
narmstrong: you've sent tags for "[PATCH] drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep" and "[PATCH 2/2] drm/panel: ilitek-ili9881c: Add Startek KD050HDFIA020-C020A support". do you plan to merge them at some point ?
<Company>
pq: 3 LUTs because one per channel, or?
frieder has joined #dri-devel
<pq>
the point of the 1D LUTs is to reshape the space into another one that is better suited for the uniform sampling of the 3D LUT, so that the 3D LUT can achieve the required precision with a feasible size.
<pq>
yes, per channel
<narmstrong>
pinchartl: yes
<pinchartl>
thanks. no urgency, I know you're busy with a revert :-)
<pq>
Company, note that "linearization" is not going to optical space in this case. Instead, "linear" is defined as "good for the uniform sampling in the 3D LUT".
<Company>
pq: yeah, I got that part - I was just wondering how much that is about linearization only, at which case it's not the 1D LUT that matters but the (de)gammaing, and as long as the 3D LUT lives in a linear space, it'll work out
smaeul has quit [Ping timeout: 480 seconds]
<Company>
pq: because the paper doesn't talk about that, it just compares with a 3D LUT from linear to sRGB
<pq>
the point is not "linear to sRGB" but from one space to a very differently curved another space
ninjaaaaa has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
<Company>
yeah, but the paper doesn't do that - the paper just does linear to sRGB
<pq>
that's irrelevant
ninjaaaaa has joined #dri-devel
<mripard>
sima: great, thanks :)
<pq>
an interesting case to evaluate would be sRGB <-> BT.2020/PQ RGB transformation
<pq>
particularly interesting would be to see how much tone and gamut mapping will cause problems there
<Company>
dunno how irrelevant that is - I'd just have liked a comparison with 3D LUT into linear sRGB + gamma
<Company>
that a 17 point 3D LUT can't deal with gamma isn't too surprising to me
<pq>
by linear sRGB + gamma you mean a matrix and gamma?
<Company>
yeah
<Company>
3D LUT and gamma
<Company>
the paper goes from camera raw, which is linear
<Company>
otherwise I'd have expected it wants a degamma step before the 3D LUT, too
<pq>
is it?
<Company>
it says so
<Company>
"the apparent gamma of this space is about 1.0"
<pq>
it says "apparent gamma is about 1.0", it's "apparent gamma" and approximate
<pq>
you're right, that it may be a deliberately "easy" case, though
<Company>
I read that as "good enough"
<mairacanal>
grillo_0, i don't think we should remove it, as it is something that we want, but we are still discussing the implementation and use-case
<pq>
AFAIU, a matrix can be represented as a 3D LUT of two taps per dimension with zero error, as long as you stay inside the "cube".
<Company>
I also have no idea what can go wrong once you start going to/from oklab or such
frieder has quit [Ping timeout: 480 seconds]
<pq>
Company, you wouldn't go to oklab. It's intended for RGB to RGB.
kzd has joined #dri-devel
<Company>
but for the RGB spaces, I would have expected degamma => 3D LUT in linear space => gamma to be good enough
<pq>
it's camera RAW though
frieder has joined #dri-devel
<pq>
camera RAW (RGB) does not have a neat analythical representation I think, it's a sample cloud if you actually profile it.
<tleydxdy>
well, raw don't even have "RGB" pixel I think
<pq>
depends on what you mean by "RGB"
<tleydxdy>
there's probably a lot more G pixels than R and B in a raw
<pq>
libcamera people could probably help here
<pq>
that's Bayer
<tleydxdy>
yes
<demarchi>
sima: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/44 contains the dim_pull_request part of splitting the tag/pr we talked about some time ago. There's a pending question there about creating the tag. Is the "tag something != tip of the branch" something desirable in general? Or is my workflow too different?
<pq>
that's a spatial arrangement, while here we're more interested in the colorimetry
<tleydxdy>
so processing it in rgb space seem completely wrong
<pq>
why would it be?
<tleydxdy>
well, you only know one color at any point, so how can you do colorimetry?
<pq>
obviously de-Bayering happens at some point, giving you a three-channel sample at each pixel
<tleydxdy>
you need to at least debayer it and that bakes in a lot of assumptions there
<pq>
we're not interested in the spatial properties here, just the (spatially interpolated) colorimetry
<tleydxdy>
that's not operating on raw anymore
<pq>
ok
<pq>
The same with displays, if you profile it, you get a sample cloud, that is, a 3D LUT essentially from device RGB -> optical measurement. This one is probably uniformly sampled in device RGB.
kts has joined #dri-devel
<tleydxdy>
yeah, there's a billion way to debayer, most likely you want to do chromatic aberration correction as well, the spatial aspect of "where the pixels is" is gonna affect your color result a lot
<pq>
If you profile a camera, I don't think either side will be uniformly sampled, or you have an impressive test target to take photos of.
<Calandracas>
not just profiling a camera, but profiling each lens :P
<tleydxdy>
the pixel value you get after you process a raw is not a simple function of the raw pixels at that point
<Calandracas>
and will give an idea of the level of complexity involved in demosaicing
<Calandracas>
its also important to do black level subtraction before debayering
* Calandracas
learned that the hard way
guludo has joined #dri-devel
<melissawen>
grillo_0, emersion I think we should keep the bkg TODO there, in our radar. But yes, we can describe the current task status better.
<melissawen>
BTW, I've seen a proposal for plane solid_fill prop (msm IIRC). Is there any relationship between these two props?
<emersion>
i don't think it makes sense to have both
<emersion>
to me, they describe the same feature
<melissawen>
hmmm... it looks like we are discussing towards the plane solid_fill property, right? In this case, do we need a CRTC bkg prop too?
<melissawen>
if so, should these possible plane and CRTC `solid_fill` props have a similar behavior?
kts has quit [Ping timeout: 480 seconds]
<melissawen>
BTW, sima, mripard, tzimmermann, we have a fix for a drm helper that is so far only used by VKMS and I'm in doubt about where should I apply it (-misc-next or misc-fixes).
<tzimmermann>
sima, what's the difference? drm-misc-fixes goes into drm-fixes, right? shouldn't that land at the end of the merge window at the latest?
<sima>
it's a bit subtle in the flow chart, but since there's no -rc only a release the 2nd question is "no"
<sima>
tzimmermann, only if you don't forgot the do a pr for both drm-misc-next-fixes and drm-misc-fixes
<tzimmermann>
i'll prepare the next PR on Thursday
<sima>
tzimmermann, tbh not sure we should change the docs and just send pr for both during the merge window
<sima>
it's a bit too reliably a confusion :-/
<tzimmermann>
:)
ninjaaaaa has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
<sima>
otoh as long as it's applied somewhere and not outright lost in a developer branch it's still a win
<tzimmermann>
i got it wrong for years, lol
<melissawen>
tzimmermann, sima thanks! I usually follow this part of the documentation "If in doubt, apply to drm-misc-next or ask your favorite maintainer on IRC"
<tzimmermann>
that's true, better than a lost patch
ninjaaaaa has joined #dri-devel
<sima>
tzimmermann, dim status says that currently there's unmerged patches in both drm-misc-fixes and -next-fixes anyway, so I guess 2 pr it is this week
<melissawen>
I'm also not clear about this "is the bug in the current -rc?". Does it mean if the bug exists in the current mainline -rc or if the bug **only** exists in the current -rc?
<mripard>
tzimmermann: tbf, I was just as wrong :)
kts has joined #dri-devel
<melissawen>
(maybe it is my low english skills)
<mairacanal>
tzimmermann, sima, is it possible to add a "Is it the merge window?" to the diagram make it more clear?
<mripard>
melissawen: I'm not sure what is the difference between your two options?
<sima>
melissawen, it's just confusing
<emersion>
melissawen: the CRTC background prop would be equivalent to exposing a plane underlay which only supports fullscreen color
phryk has quit [Remote host closed the connection]
yyds has joined #dri-devel
amarsh04 has quit []
<melissawen>
mripard, I mean, we have a bug since v6.5, so we can say the bug exists in the current -rc (and all past -rc). But if we are in the v6.9-rc2 and the bug was introduced in this -rc, so the bug **only** exists in the current -rc.
<gfxstrand>
Ugh... I need to make some decisions about unstructured NIR
<gfxstrand>
In particular, I need reg_intrinsics_to_ssa to work on unstructured control-flow.
<gfxstrand>
This means we need to be able to do a reverse post-DFS walk of the CFG.
<gfxstrand>
Do we want to require that the list of blocks in nir_function_impl is always a reverse post-dfs, add a helper to re-sort it, and enforce that with nir_validate?
<mripard>
melissawen: the "age" of the bug doesn't matter, the only thing that does is the version affected. The question is: is it in Linus' tree (in last -rc) or in drm-misc-next ?
<gfxstrand>
Do we want to DFS and sort the blocks on the spot every time we want to iterate that way?
<gfxstrand>
Do we want a half-way solution where dominance records the CFG post-indices and we sort right before we walk?
<gfxstrand>
cwabbott, jenatali, karolherbst: ^^
<melissawen>
mripard, oh, I got it! thanks for explaining!
<mripard>
melissawen: so if the bug is 10y old or just got merged in last rc, it should be merged in drm-misc-fixes either way
<mripard>
if it's not in Linus' tree but drm-misc-next, then it should either be merged in drm-misc-next before -rc6, or drm-misc-next-fixes if it's between X-rc6 and X+1-rc1
<javierm>
the drm-misc-next-fixes always confuses me as well. A couple of times I did wrong and a cherry-pick was needed, which duplicated the commits and polluted the git log :(
amarsh04 has joined #dri-devel
<melissawen>
mripard, okay... but then I'm confused again. Because the bug fix I've mentioned (drm+vkms) is present since v6.5, but we are now in a merge window.
<mripard>
melissawen: then "if it's not in Linus' tree but drm-misc-next" is false :)
<javierm>
melissawen: the question is, do you want your fix to land in v6.9 or v6.10 ?
<melissawen>
so, sima mentioned drm-misc-next-fixes because we are in a merge window... what should be evaluated first: merge window or Linus' tree?
<mripard>
I think that's the part where tzimmermann and I were confused about too
<melissawen>
x_X
<mripard>
like javierm was saying, it basically boils down to what version you want to target
<mripard>
after -rc6, you still have two releases for the current release
<mripard>
and after the final release, the merge window opens and the next version is going to be (X+1)-rc1
<mripard>
so what sima said was that drm-misc-next should always be open, drm-misc-next-fixes between -rc6 and (X+1)-rc1, and drm-misc-fixes between (X+1)-rc1 and X+1-final
<javierm>
melissawen: the problem is that there's a gap between DRM maintainers send the drm-next PR to Linus and the -rc1 released by Linus that is the target for drm-misc-fixes
<javierm>
and that gap is what drm-misc-nex-fixes tries to cover
<sima>
javierm, the gap is when the last drm-misc-next goes into drm-next
<mripard>
which seems a bit weird to me, I would have expected drm-misc-fixes to be always open, just like drm-misc-next, with drm-misc-next-fixes being just the stop-gap measure
<sima>
at around -rc6
<sima>
mripard, yeah maybe we should switch to that model, defacto it is already
<sima>
essentially if it's a bugfix, try drm-misc-fixes first if it contains the bug, then drm-misc-next-fixes, then drm-misc-next
<karolherbst>
gfxstrand: why do you need reg_intrinsics_to_ssa to run unstructured?
<javierm>
sima, mripard: but that needs drm-misc-fixes to get a backmerge of drm-misc-next right ?
<javierm>
err, of drm-next I meant
<mripard>
javierm: which will happen at next -rc1
<sima>
javierm, if all goes well you can just fast-forward to -rc1
<sima>
sometimes you have a few lost commits, and then yes you need a backmerge
<javierm>
mripard, sima: exactly, but the problem is that then you have the time gap I mentioned
<sima>
javierm, the time gap is much bigger
<gfxstrand>
karolherbst: Because to make my crazy but correct new warp barriers pass, NAK wants unstructured CF.
<karolherbst>
scary
<gfxstrand>
:)
<javierm>
sima: how so? Isn't between drm-misc maintainers send their last drm-misc-next PR and Linus releases -rc1 ?
<sima>
yeah
<gfxstrand>
karolherbst: That or I need to define a structured goto in NIR
<sima>
which is about a month, which is a bit much
<karolherbst>
I mean.. I totally see why you'd want that to run on unstructured CF, but... have you considered doing it in SSA regardless? :D
<gfxstrand>
Or add a whole new nir_scope CFG node type and a scope_break jump type which breaks out of N scopes
<gfxstrand>
Those are all options
<karolherbst>
ohh right...
<karolherbst>
uhhh
<javierm>
sima: yeah, I understand the rationale of drm-misc-next-fixes but is just that I never track that closely the part of the process
<sima>
javierm, the other thing is that you can't really merge drm-misc-fixes into drm-next, because that would replicate linus' merge commit
<sima>
which he really doesn't like
<karolherbst>
the barrier aspect isn't the issue, but rather doing all of this convergency stuff
<gfxstrand>
Yeah, roughly.
<sima>
and if you'd just merge that merge commit, you get a random point in the middle of the merge window, which isn't a good idea either
<gfxstrand>
There's a lot of different ways to slice this pie
<javierm>
sima: I wonder if dim could automatically close drm-misc-fixes during that period and warn users
<sima>
so you can't pick up all fixes during the merge window with drm-misc-fixes, you need -next-fixes even during that time since that's based on drm-next
<karolherbst>
gfxstrand: mhh. why not attach the convergency info to the CFG? Like... inner threads need to converge after leaving this block, and it's up to the backend to implement it correctly?
<sima>
javierm, I tried, I failed
<gfxstrand>
karolherbst: Oh, that's all implicit in NIR already
<sima>
javierm, like even the logic to push the right branch to the linux-next branches is mostly busted
<mripard>
javierm: the point is that you can't close drm-misc-fixes after -rc6, because there's still -rc7 and the final release that you still might want to target
<javierm>
sima: I see
<karolherbst>
mhh, fair
<sima>
since after the freeze we want to push drm-misc-fixes + drm-misc-next-fixes and _not_ drm-misc-next, since that's not for the current merge window
<javierm>
mripard: but -rc7+ are not merged from drm-misc-fixes but drm-misc-next-fixes
<karolherbst>
but I guess you want to insert the barriers when in nir, not when in nak
<sima>
and if there's anything big in drm-misc-next it really annoys people
<gfxstrand>
It's not really the barriers that are the problem. It's all the extra CF required to do the break cascade
<sima>
javierm, drm-misc-next-fixes only heads into drm-next (assuming no misplaced/lost commits outside of when it's needed)
<karolherbst>
mhh, I see
<gfxstrand>
And I'll feel way more comfortable about it if I can just leverage NIR's SSA re-construction.
<mripard>
javierm: honestly, it's from both. Each time I start handling drm-misc-fixes for a given release, I basically merge -rc1 and drm-misc-next-fixes if there's any commit
<javierm>
sima: I see
<gfxstrand>
NAK also has SSA reconstruction so I can also do it there in theory
<sima>
javierm, and drm-misc-fixes never goes into drm-next (well aside from misplaced patches during the merge window that would be stuck otherwise until after -rc1)
<mripard>
javierm: and from what tzimmermann, I'm pretty sure he does too :)
<tzimmermann>
right, when i take over -misc-fixes, i bring the branch up to the currect -rc1 and check -misc-next-fixes for any leftovers
<karolherbst>
gfxstrand: but I think I lean towards the "on-the-fly" solution, because in codgen we had implicit ordering and I still have nightmares from doing anything CFG related in codegen from that
<gfxstrand>
heh
<karolherbst>
ehh "on the spot" you said
<gfxstrand>
Yeah, it's just annoying because you have to DFS and return an array and then someone has to free the array.
<gfxstrand>
Not really the end of the world, just annoying.
<karolherbst>
in codegen it was even worse, because branches didn't point to blocks, but rather the first in the next list was branch taken or not taken, and uhh... it was all terrible. But they were also implicitly sorted and it messed with RA or something, it was horrible
<gfxstrand>
NAK is a little that way but probably not as bad
<karolherbst>
gfxstrand: what if you just have an iterator helper, which takes a callback with the block as an input and you shouldn't mess with the CFG while iterating?
<clever>
emersion: of note, the HVS on the rpi also supports a background fill color
<emersion>
good to know
<emersion>
is it per-plane, or per-CRTC?
<gfxstrand>
karolherbst: I think I have a clever plan
<clever>
emersion: per crtc
<clever>
let me find the exact details...
<karolherbst>
gfxstrand: is it the good kinda or the bad kind of a clever plan?
<clever>
all 3 outputs on the HVS, have a dedicated color and fill-enable flag
<gfxstrand>
karolherbst: IDK
<emersion>
cool
<karolherbst>
sounds promising then
<clever>
emersion: i think vc4_hvs.c is what enables it, via enable_bg_fill, but it never sets a color, so its just 000000, black
<clever>
emersion: basically, there is a chunk of ram being used as a fifo, the read side is treating it as a fifo, and sending pixels to the encoder (such as hdmi)
<clever>
emersion: but the write side is treating it as ram, and for each plane, just copies pixels from host ram to the fifo ram, doing scaling and blending as it goes
<clever>
if no plane covers a pixel, then that slot never gets written, and you get undefined (previous scanlines) as the result
<clever>
the bg fill prevents that, by just setting the entire scanline to a known state, but that also costs clock cycles
anujp has joined #dri-devel
<clever>
linux uses enable_bg_fill, to decide if there is a full-screen plane or not, and turn that on/off
<clever>
but it could definitely be exposed as a drm prop
Calandracas has quit [Quit: Leaving]
Calandracas has joined #dri-devel
sgruszka has joined #dri-devel
<mripard>
emersion: iirc sun4i's crtc allows a BG color too
<clever>
a random baremetal demo, where i used the bg fill
warpme has quit []
yyds has quit [Remote host closed the connection]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<pq>
emersion, melissawen, I think from purely UAPI perspective, I might prefer bg color prop on CRTC *and* solid_fill prop on planes that can use also real FBs. I think creating another (fake) plane that can only ever use solid_fill is more complicated for no benefit I can see.
<emersion>
so you prefer having two codepaths?
<emersion>
and try these when you need to paint bg?
<pq>
at first thought, yeah
<emersion>
that's surprising
<pq>
I guess I don't see myself using a plane with solid_fill
<pq>
but you're right, if one is aiming to use planes with solid_fill opportunistically, then CRTC bgcolor prop has no use.
<pq>
how do you tell userspace that this "bg plane" cannot ever take any FB?
<emersion>
you can just reject commits
<pq>
empty format list?
<emersion>
i mean, on Arm it's all virtualized planes anyways
<pq>
alright
<pq>
"bg plane" would be restricted to covering the whole CRTC. No problem either, I guess.
<vsyrjala>
yuck on 'bg plane'
<vsyrjala>
that would cause a lot of grief to the driver all over
phryk has joined #dri-devel
<emersion>
only because the DRM internals are designed this way
<vsyrjala>
yes. they are supposed to more or less reflect the hw
<vsyrjala>
i guess one could in theory intercept this more or less in the ioctl handle itself, and thus hide the mess from the lower level code
<vsyrjala>
but dunno if i really like that either. migth as well emulate it in userspace imo ;)
<emersion>
everything emulated in user-space is replicated as many times as there are compositors
<emersion>
and having 3 ways to do the same thing is not a great uAPI
odrling has quit [Remote host closed the connection]
odrling has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
<zamundaaa[m]>
pq: you could have no FB_ID property on the plane... But then again, some userspace is very trusting for the kernel to never change anything
<zamundaaa[m]>
If the choice is between a plane that has the "normal" properties, and a CRTC prop for the background color, I'd pick the CRTC prop though. Otherwise userspace will quite often waste atomic tests on the color-only plane
ghishadow has quit []
<emersion>
zamundaaa[m]: but some hw supports things that cannot be described via a CRTC proo
<emersion>
prop
ghishadow has joined #dri-devel
<zamundaaa[m]>
What kind of things?
<zmike>
mareko: I am convinced that the number of mesa/st nir passes broken with lowered io is infinite
<emersion>
zamundaaa[m]: a plane background color, or a square in the middle of the screen filled with a color
<zamundaaa[m]>
That sounds more like a new drm object would be needed to describe that
<zamundaaa[m]>
with some description of what the background color applies to
<DemiMarie>
emersion: which hardware is this?
frieder has quit [Remote host closed the connection]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
apinheiro has joined #dri-devel
<mareko>
zmike: yes the optional passes likely don't work
<zmike>
they not only don't work, the lowered io paths show a pretty fundamental misunderstanding of how lowered io works :/
aravind has quit [Ping timeout: 480 seconds]
<mareko>
it works here
<zmike>
sure
<zmike>
I am fixing them as I go
<mareko>
how is lowered IO misunderstood?
<zmike>
still searching for variables in e.g., nir_lower_clamp_color_outputs
<mareko>
yes, that's an optional pass
<zmike>
yes
<zmike>
I was agreeing with you
<zmike>
I have a bunch of fixes so far, but the goalpost seems far
<clever>
emersion: i can also picture how you could do a solid_fill plane on the rpi, just make a 1x1 or 2x2 pixel plane, and let the hw scaler do the rest
<mareko>
in the future I'm hoping we could lower IO for all drivers, and unlower it for drivers that don't accept it, so that we have only 1 code path and 1 style of NIR in st/mesa
lynxeye has quit [Quit: Leaving.]
<mareko>
that one is also far
<zmike>
very
<gfxstrand>
That would be nice
<zmike>
year 2050 goals
sukuna has joined #dri-devel
cmichael has joined #dri-devel
<mareko>
it's doable in 2024
<sima>
demarchi, dropped a comment
<sima>
demarchi, and I don't think your use-case for dim tag-branch is that unusual, makes sense to me
<sima>
like if you try to match the commit that CI has done overnight runs on or something like that, but only tag it when it's good
kts has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<jenatali>
mareko: I've considered doing exactly that. My backend wants the load/store intrinsics lowered, but still wants variables to iterate over. I'm perpetually tempted to add something late to reconstruct the variables from the intrinsic data
tzimmermann has quit [Quit: Leaving]
<zmike>
do I have great news for you
<jenatali>
:O
JohnnyonFlame has joined #dri-devel
<demarchi>
sima: thanks... I will take a look on getting the missing part
Calandracas_ has joined #dri-devel
junaid has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
Marcand_ has joined #dri-devel
junaid has quit [Quit: leaving]
warpme has joined #dri-devel
fab has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
warpme has quit []
cmichael has quit [Quit: Leaving]
gouchi has joined #dri-devel
ninjaaaaa has quit [Read error: Connection reset by peer]
simondnnsn has quit [Write error: connection closed]
simondnnsn has joined #dri-devel
ninjaaaaa has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.2.1]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Marcand_ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
iive has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
simon-perretta-img has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
The_Company has joined #dri-devel
oneforall2 has joined #dri-devel
vliaskov_ has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Company has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
anujp has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
vliaskov_ has joined #dri-devel
ninjaaaaa has quit [Remote host closed the connection]
simondnnsn has quit [Write error: connection closed]
simondnnsn has joined #dri-devel
ninjaaaaa has joined #dri-devel
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
vliaskov_ has joined #dri-devel
eocwzdenn^ has quit [Ping timeout: 480 seconds]
<mareko>
jenatali: that's what driver-specific shader info gathering is for... you just gather IO descriptions from the intrinsics and store it somewhere
<jenatali>
Yeah. I just haven't done that work yet :)
<mareko>
radeonsi has this large structure called si_shader_info
<mareko>
it's like shader_info, but more
vliaskov_ has quit [Remote host closed the connection]