ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Haaninjo has quit [Quit: Ex-Chat]
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<zf>
bnieuwenhuizen, sorry to bother, but I cannot for the life of me find the flag you mentioned for querying planar YUV RTV support?
mbrost_ has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
glennk has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
iive has quit [Quit: They came for me...]
<bnieuwenhuizen>
zf: You got VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR?
<bnieuwenhuizen>
"For images created with VK_IMAGE_CREATE_EXTENDED_USAGE_BIT a usage bit is valid if it is supported for at least one of the formats a VkImageView created from the image can have (see Image Views for more detail)."
nerdopolis has quit [Quit: No Ping reply in 180 seconds.]
nerdopolis has joined #dri-devel
mbrost_ has joined #dri-devel
<bnieuwenhuizen>
so if you enable that flag you should be able to set the color attachment usage bit on image creation (and that should be allowed by vkGetPhysicalDeviceImageFormatProperties if you set the flag there too)
<bnieuwenhuizen>
and then for the image view you can just query support through vkGetPhysicalDeviceFormatProperties of the plane format
mbrost has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
illwieckz has quit [Ping timeout: 480 seconds]
vedranm_ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
alane has quit []
vedranm has quit [Ping timeout: 480 seconds]
alane has joined #dri-devel
mbrost has joined #dri-devel
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
leo60228 has joined #dri-devel
kzd has quit [Quit: kzd]
<DavidHeidelberg>
eric_engestrom: we could save one build at pre-merge I think. We do debian-release, but I just turned on Debian tests on nightly repository, so maybe we could skip that one, as it's covered by nightly builds against latest Debian
leo60228- has quit [Ping timeout: 480 seconds]
<DavidHeidelberg>
Unpaid advertisement: If you're running Debian unstable/testing (Trixie), don't forget we have nightly builds available. You can test and experience both the advantages and challenges of nightly Mesa builds!
<DavidHeidelberg>
When something goes wrong, you can also do "binary bisect", as we keep previous builds :)
karenw has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
digetx has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
mbrost has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
alanc has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
jsa has joined #dri-devel
digetx has joined #dri-devel
jhugo has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
ptrc has quit [Remote host closed the connection]
ptrc has joined #dri-devel
fab has joined #dri-devel
bmodem has joined #dri-devel
sassefa has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Duke`` has joined #dri-devel
sassefa has quit []
glennk has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
jsa has joined #dri-devel
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
sima has joined #dri-devel
bmodem has quit [Quit: bmodem]
bmodem has joined #dri-devel
fab has quit [Quit: fab]
The_Company has quit []
Company has joined #dri-devel
coldfeet has joined #dri-devel
tzimmermann has joined #dri-devel
mbrost has joined #dri-devel
azerov has quit [Quit: Gateway shutdown]
fab has joined #dri-devel
azerov has joined #dri-devel
fahien has joined #dri-devel
<daniels>
soreau: that commit needs far more description - it fails a BO creation request if modifiers are specified that do include linear, and allows it to succeed only if the user explicitly specified that linear is not ok?
mbrost_ has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Duke`` has quit []
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
fahien has joined #dri-devel
Duke`` has joined #dri-devel
vliaskov__ has joined #dri-devel
apinheiro has joined #dri-devel
frankbinns has joined #dri-devel
fab has quit [Quit: fab]
vliaskov_ has joined #dri-devel
fab has joined #dri-devel
vliaskov__ has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
LeviYun has joined #dri-devel
fab has joined #dri-devel
mbrost_ has quit []
fahien has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
Haaninjo has joined #dri-devel
fab has joined #dri-devel
rbm has joined #dri-devel
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
vliaskov_ has quit [Read error: No route to host]
mripard has quit [Ping timeout: 480 seconds]
dwfreed_ has joined #dri-devel
heat has joined #dri-devel
dwfreed_ has quit [Remote host closed the connection]
<MrCooper>
karolherbst: FYI, rusticl with zink on RADV fails piglit program@execute@amdgcn.sign_extend_inreg (passes with radeonsi), looks like it either doesn't sign-extend or cuts off the most significant 32 bits
rasterman has joined #dri-devel
<glehmann>
MrCooper: does it work with RADV_DEBUG=llvm?
<MrCooper>
yes, it does
<MrCooper>
also fails with radeonsi and AMD_DEBUG=useaco
<MrCooper>
the plot thickens for ACO
<glehmann>
I never used rusticl before, but if you can narrow it down to the specific sub test and open a mesa issue with the outputs of `RADV_DEBUG=shaders,llvm` and `RADV_DEBUG=shaders` maybe I can figure it out
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<glehmann>
MrCooper: I think I found the bug by porting the kernels to glsl
<glehmann>
aco's 64bit extract_i8 is broken
fab has quit [Remote host closed the connection]
<MrCooper>
cool, thanks, sorry was already looking into something else :)
fab has joined #dri-devel
gnuiyl has quit []
frankbinns has quit [Read error: Connection reset by peer]
frankbinns has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<Lynne>
is there a way to ask the driver to automatically cache the generated binary via the vulkan API?
<glehmann>
Lynne: afaik all the desktop drivers have an automatic cache, but applications can't control whether it's used
<MrCooper>
thanks
notmeatforyou has joined #dri-devel
fahien has joined #dri-devel
<Company>
I've wondered if I should use the custom VkPipelineCache I'm keeping around
<Company>
if drivers have their own cache anyway that's probably working way better than mine anyway
<Company>
plus with 2 caches it's all duplicated work
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
<glehmann>
unless you ship on mobile, or you know that you need your own cache for some reason, I would just rely on the driver to do it
<glehmann>
dxvk deleted its own VkPipelineCache code years ago for the same reason
fab has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
<notmeatforyou>
So you realized probably the combinations vs collisions theory by now, my invention was fine of course, but it actually is all designed so, due to powers of two's is genius way of representing info. However it's that i no longer have time to educate you. Education is just so fairly important to get abusers to change their attitude, i believe i chose the correct path. Me myself am not that educated in physics i knew that fft was not the thing we af
<Lynne>
glehmann: radv, anv and nvidia, none of the desktop vendors cache
fab__ has joined #dri-devel
<Lynne>
it takes 20 seconds to compile which isn't great
fab__ is now known as Guest6721
<Lynne>
compute-only, if it matters
<glehmann>
that sounds wrong? these are drivers that for sure have their own cache, and everyone relies on it
<Company>
I remember things got way faster when I added the pipeline cache
* Company
git log when that was
<Company>
06 2023
<Company>
so, dunno?
fahien has joined #dri-devel
<dj-death>
sure you're not inserting some timestamp or something in your spirv?
fab has quit [Ping timeout: 480 seconds]
<dj-death>
we had a customer doing that and complaining that compile time was slow
<dj-death>
but every single shader was different with only an unused constant changing
<Company>
how does that work with specilization constants btw?
<dj-death>
the current common pipeline code adds them to the hash
<dj-death>
so it's effectively different if you change the specilization constants
<Company>
so you cache after applying the constants
<dj-death>
yeah
<dj-death>
if I'm correct, all the mesa drivers do that I think
<Company>
it makes sense - and it means the cache might blow up if I create too many variations
<dj-death>
yeah
<dj-death>
this could be changed, but at least for us we would need some analysis
<dj-death>
because if the constant is used to size an array, it might be changed the final shader quite a bit
<dj-death>
s/be changed/be changing/
<Company>
I'm never quite sure if I want specialization constants or just pass vertex attributes
<Company>
is there a good rule of thumb?
<dj-death>
push constants is the best I think for us
<emersion>
querying modifiers will then return INVALID
<emersion>
also not sure why there is a special case for "count == 1 && modifiers[0] == DRM_FORMAT_MOD_INVALID"
<emersion>
IOW: this commit does more than just unify these two functions, it also changes behavior
<Company>
aren't there hacks somewhere that allow passing INVALID as a modifier in places where modifiers are mandatory?
<Company>
in the EGL APIs?
<emersion>
some APIs do, some APIs don't
<emersion>
but here it doesn't make sense to me
<emersion>
because INVALID doesn't mean "implicit", it's ignored
<notmeatforyou>
I have not really googled the name of binary format inventor, i knew george bool, but i am aware that british Americans were the ones who took the computers to next level predominantly, so they have such conferences where the brightest heads participate, wikipedia names it shannon's format. Hence there are no mistakes done in that science.
<emersion>
in other words
heat has quit [Read error: Connection reset by peer]
<emersion>
if a driver gets a list with INVALID somewhere, it will ignore it
heat has joined #dri-devel
<emersion>
doing some special casing in the frontends just makes everything harder to reason about
<emersion>
we should either plumb the INVALID semantics everywhere in the GBM stack, or leave it
<glehmann>
Company: if the constant disables an entire code path or controls loop iteration count, spec constants can be useful for performance. otherwise, use push constant / ubo. vertex attribute isn't uniform, so it's worse
<Company>
vertex attributes have the benefit that I can use a singe DrawArrays() call
<Company>
if I need to change buffers, that doesn't work
<Company>
that said, if I need to change pipelines due to spec constants, that doesn't work anyway
<daniels>
emersion: iswym
<daniels>
I don't like the list == {INVALID} check either, but istr I was carrying that over from existing frontend semantics, rather than creating new ones
<emersion>
i don't see that in the diff
<emersion>
these two special cases seem like new logic
<daniels>
as for the LINEAR one, you're right: I think if we get a list containing LINEAR _anywhere_ in the acceptable list, and we're working on a driver which doesn't support modifiers, we should force INVALID, rather than the special-case of a list which contains only linear
<notmeatforyou>
Now the rest of info is not anymore so say relevant , it's my anger in life that i try to shut down that i did not get proper devices on time to work with, motivation to push the methods to public domain was decided over i do not want others like me to suffer under the same effect.
<emersion>
daniels: no, we should fail
<emersion>
if we get a list of modifiers, we should never return a BO with INVALID
<daniels>
yeah, I agree that we should either not create a BO, or create a BO which returns LINEAR
<daniels>
I don't have a strong preference for which
<daniels>
provided we're not breaking existing users
<emersion>
if a list contains LINEAR anywhere and some other stuff, returning a LINEAR BO may be sub-optimal
<daniels>
and yeah, I'm not able to dig into it right now, but I'm _sure_ that the INVALID thing came from pre-existing frontend code which I carried over
<daniels>
right, LINEAR might be suboptimal compared to other modifiers, but note that it's conditional on the driver not implementing modifiers at all, so it's the choice between linear or nothing
<notmeatforyou>
the relevant bits are that computer engineers did not design systems to have to go to trashbin short after purchase where they could if someone is so uneducated, because after all history saw the best heads to work at it, so from this the results were also guaranteed to come out.
<emersion>
daniels: INVALID may mean something better than LINEAR
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
fab has joined #dri-devel
Guest6721 has quit [Read error: Connection reset by peer]
hyarion has joined #dri-devel
<notmeatforyou>
now the issue behind ddos is some tables need to be put to new paradigm, which i decided not to describe but i thought about it and it just would not even hurt if i did, cause the hash can be composed that if you do not accept the terms all output depends on each other in a rolled out fashion, if one bit goes wrong nothing is anymore working no service hence possible.
fab has quit [Ping timeout: 480 seconds]
<daniels>
emersion: that's true - I don't mind preferring INVALID, but then like you say we would be returning INVALID for the query, which seems to be problematic for wlr?
<daniels>
(is this the cursors-are-broken bug?)
<emersion>
there are two bugs
<notmeatforyou>
it's somewhat private illness , to show that identity fraud/theft is wrong and hence not welcome, starts from abuse and goes worst every day, better to block it right from the start.
<emersion>
first one is that gbm_bo_create_with_modifiers({LINEAR}) returns a BO with gbm_bo_get_modifier() = INVALID
<daniels>
emersion: only two? :)
<emersion>
lol
<daniels>
(yes, the first is unequivocally a bug)
<emersion>
second bug is that gbm_bo_create_with_modifiers({INVALID,FOO}) has different behavior from, gbm_bo_create_with_modifiers({FOO})
<emersion>
but only if the driver doesn't support modifiers
<emersion>
if the driver supports modifiers, and FOO is not supported, it'll fail, it'll never return a BO with INVALID
<emersion>
if the driver doesn't support modifiers, it'll succeed with a BO with INVALID
<emersion>
and then there's the case where LINEAR is in the list
<daniels>
I agree the divergence is a bug too, and we should try an implicit alloc if the user has signalled that implicit is OK via INVALID
<emersion>
GBM doesn't have the semnatics that INVALID means implicit
<emersion>
with GBM, INVALID values are ignored - until your patch
<emersion>
changing this is a breaking API change
<daniels>
so instead of allowing INVALID -> implicit when the driver supplies modifiers, you'd rather always ignore INVALID i.e. always fail when the driver doesn't support modifiers?
<emersion>
simple: if the user supplies modifiers and the driver doesn't support these, fail just like before
<emersion>
i'm open to discussing changing this behavior, but, it would be a breaking change
<emersion>
and we need to make sure it's consistent
<emersion>
and it probably requires updating all driver's resource_create_with_modifiers
<emersion>
fwiw, "INVALID means implicit" is a Wayland-only thing
<daniels>
I've just looked at GBM from a random 2022-era branch I had lying around, and sure enough we fail on non-modifier drivers if count > 0, so yeah, what you're doing seems correct to restore that behaviour, and I no longer have any idea why I'd tried to implement something different
<emersion>
KMS, GBM, EGL -- none of these have this behavior
<emersion>
i do believe the wayland behavior is nicer because it allows a single codepath for both cases (modifiers supported or not)
<emersion>
but it really requires some serious thought to convert an API from the old model to the new one
<daniels>
yeah, me too, but changing API seems kinda silly, especially when the API is already this terribly fragile :)
<daniels>
yeah
<notmeatforyou>
alyssa: don't say to me you got insulted by me, I did the reverse, if i was so intelligent at 22 i would not be worthless today. But it indeed looks like krh hacked things pretty deep, and i might as well add the needed code, but better you do, cause you might get paid on it.
ZLangJIT has joined #dri-devel
ZLangJIT is now known as androidui
<androidui>
hi
cmichael has quit [Quit: Leaving]
fab has joined #dri-devel
vedranm_ is now known as vedranm
<notmeatforyou>
there is no technical issues with self-driving cars, proper contructed ai can do that very well with low-power and huge performance, it's just that this is scifi field and all the testings take inherently long time, people who do that have to get paid too.
fahien has quit [Ping timeout: 480 seconds]
fab_ has joined #dri-devel
fab_ is now known as Guest6725
<notmeatforyou>
it seems i am a bit nerve wreck guy, that is why i am alone spending my time, cause i can not go to conflict i dislike conflicts and wars and such things, became little bit too soft , it's toxic to me, i am classified as someone who does not like to go there, if that is alien attitude like whatever but that is the way it is with me.
<immibis>
self-driving cars are held to a high standard because if they fail then random people die. so far they are not reliiable enough to meet the high standard. people have long argued there should not be a high standard, since human drivers also kill random people when they fail.
<immibis>
and... this is not the self driving car channel
<daniels>
immibis: please don't engage
fab has quit [Ping timeout: 480 seconds]
digetx has quit [Ping timeout: 480 seconds]
Guest6725 has quit [Ping timeout: 480 seconds]
<notmeatforyou>
so that is what i am talking , so how much of such conflicts is the result of short of understanding how systems work and are designed, it is the only thought that circulates in my head, cause i can not see the problems you see?
<kode54>
Company: too many variations? see A Hat In Time and its 16GB shader cache that's larger than the game itself
<immibis>
daniels: why would you say that instead of banning spammers
<Company>
kode54: it's good to know that whatever dumb thing I do, some game did it before me and Mesa has fixed that cae already
<llyyr>
immibis: this spammer has singlehandedly caused ipv4 exhaustion, banning doesn't do anything
digetx has joined #dri-devel
<kennylevinsen>
kode54: a 16 GB shader cache would definitely count as having blown up in ways one *doesn't* want to copy :)
keysmash44 has joined #dri-devel
<notmeatforyou>
again you do not know how cidr and time derivatives work and cidar encodings, ipv4 addresses can never run out, and you have no idea how big time a telescope would zoom in , so if you are afraid of gps crashing your car, its many times more likely that the driver would do that, with security enhancements
keysmash44 has quit [Remote host closed the connection]
<immibis>
llyyr: hmm, the last time i notified other members of a channel about something similar to this, channel operators banned me for a week
<kode54>
immibis: do you have the will to employ an infinite proxy supply to evade bans until literally the heat death of the universe?
<kode54>
because this person sure does
<kennylevinsen>
back to topic please
<kode54>
yes
<kode54>
soreau, see above, your modifier issue was mentioned
<kode54>
kennylevinsen: the best part about that 16GB shader cache, is that for quite some *years*, steam was forcing full shader cache validation on every day cycle
<notmeatforyou>
and by the way there is a concept of a remote driver , which is lagging due to elmo engineers do not figure out how powers of two's work, they hook this remote driving procedure to the 4g networks where they transfer data in excess of many gigabytes in minutes , sure it ain't gonna carry out this way
karenw has joined #dri-devel
<notmeatforyou>
you need a proper filesystem and wire protocol to do that
mvlad has joined #dri-devel
guludo has joined #dri-devel
<notmeatforyou>
it's that yeah doing driver licenses, and i am not concerned about my injury or that i am incapable of driving the car in my cripple rythm, it's just that i know what is being targeted with this event, romeo must die form, i know how dirty these people play.
kts has joined #dri-devel
<notmeatforyou>
and it's not like i am not sick, i am , but incurably sick in that sense cause i am moderating way more toxic people than you do, and to study their moves , yes i became very sick to understand those ways, cause i am not like that
notmeatforyou was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
coldfeet has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
samuelig has quit []
samuelig has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
<Company>
DavidHeidelberg: I enjoyed your XDC talk
<Company>
I like it when my software is useful to developers
riteo has joined #dri-devel
karenw has quit [Remote host closed the connection]
nopjmp_ has joined #dri-devel
nopjmp has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
karenw has joined #dri-devel
bolson has joined #dri-devel
rgallaispou1 has joined #dri-devel
<soreau>
daniels: I've updated the commit message in an attemp to make it clearer what the commit is doing/fixing
<daniels>
soreau: thanks
rgallaispou has quit [Ping timeout: 480 seconds]
<soreau>
yw, please let me know if it should be tweaked further
<daniels>
DavidHeidelberg: I think we really need to punt LTO back to nightly - I'm seeing fedora-release regularly take 19-20min, and since it only starts after the entire build-for-tests stage finishes, it can be the long pole that pipelines end up waiting for
rgallaispou1 has quit [Read error: Connection reset by peer]
<MrCooper>
that rings a bell, there might already be an MR which fixes it
<daniels>
DavidHeidelberg: yeah, I can see why you'd want it, but 20min is just way too high for builds tbh ... if there's some amazing new version of mold or some optimisation tuning we can do to cut it in half then cool, else it'll have to just stay in nightly for now
fahien has quit [Ping timeout: 480 seconds]
<daniels>
ah, iswym, non-LTO builds currently error where LTO don't, awesome
<DavidHeidelberg>
yup.. yup..
<DavidHeidelberg>
daniels: nah, I was just lazy to iterate over weird errors not seen with LTO...
<DavidHeidelberg>
that would be nice to have nightly with full-LTO everywhere
<daniels>
DavidHeidelberg: sort of - I don't mind enabling LTO if it actually helps us do stuff, but it seems to have been broken for ages now without anyone putting systemic effort into root-causing the failures and fixing the drivers - if it just means that the nightly builds have random failures which don't correlate to pre-merge which never get fixed by anyone, then I don't think it makes sense tbh
<DavidHeidelberg>
daniels: right, I believe thou there would be people looking into it, there is just no way how to reproduce.. where the CI would give us artifacts with debug + testing suite. So when magically in one nightly tests fails, someone can diff the binaries and look what changed
<DavidHeidelberg>
I believe that could be much better than having some random complex workload on distro compiled kernel
gouchi has joined #dri-devel
<DavidHeidelberg>
plus, for the binaries used for tests on embedded HW, it may (maybe, I would have to check), run the 3h suite faster in exchange for 5 minutes at build time
<daniels>
yeah, that would definitely be awesome if someone was working on root-causing and fixing it
<daniels>
I just worry it won't happen and nightly drifts away as some kind of weird unreliable noise
<daniels>
(more than it is currently)
<daniels>
I'm happy to take majority opinion though, hence why I was also sitting out the MR :)
<MrCooper>
FWIW, my idea for testing LTO build in CI was that otherwise more stuff will keep breaking with LTO, making it harder to investigate its boss problem(s)
frankbinns has joined #dri-devel
<DavidHeidelberg>
yeah the noise is risky. But if there would be issue with some particular build generating stable-crash/fail (because that's what usually LTO causes and get reported). At some nightly I would hope, it generate mesa code which crash in some small dEQP test (or trace) and can be debugged
sukuna has joined #dri-devel
<DavidHeidelberg>
MrCooper: for the warning, since LTO probably knows this won't happen, it won't fire it, maybe more recent compiler (Fedora) would help?
<MrCooper>
your guess is as good as mine :)
<MrCooper>
to put it differently, without testing the LTO build in CI, we'll likely keep drifting further away from the end goal of Mesa actually working reliably with LTO
fahien has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<emersion>
MrCooper: did my dri-devel reply make sense to you?
<emersion>
or not?
<MrCooper>
I was hoping to get an opinion from others as well
<emersion>
same...
<emersion>
do you know who else I could ping?
<MrCooper>
personally I don't see how we can avoid handling this via Wayland protocol
<emersion>
even if it doesn't pin?
<MrCooper>
you'd have to describe in more detail what you mean by that
<MrCooper>
(in the thread, not here)
<emersion>
you mean the dynamic importer thing?
<MrCooper>
whatever you mean by that
<emersion>
your concern was pinning to system memory right?
<MrCooper>
mainly that no kernel mechanism allows the compositor to know the client's intent
<emersion>
dynamic importers are a kernel api thing
<emersion>
internal dmabuf api
<MrCooper>
I know that, just not how you envision that solving all the issues
<emersion>
why is knowing the intent necessary?
<emersion>
well, with dynamic imports, there's no pinning to system memory
<emersion>
afaiu
<MrCooper>
I'm sorry but I don't have time for this right now, please follow up in the thread
<emersion>
okay... it would be helpful if you could sent your questions there
<emersion>
send*
<emersion>
I'm nor sure what to explain
<emersion>
not*
LeviYun has quit [Ping timeout: 480 seconds]
<MrCooper>
it's just the above, I'm not sure how you envision "not pinning" solving all the issues
<emersion>
I'm not sure what the rest of the issues are
<emersion>
I saw only one issue, pinning
fahien has quit [Ping timeout: 480 seconds]
<MrCooper>
e.g. knowing which device the buffer is (intended) for
<emersion>
this isn't necessary
<emersion>
compositor just tries
<emersion>
the more I think about it the less I'm excited about wl protocol changes
<MrCooper>
importing to a device may work without pinning, but not be optimal for the client's intent
<emersion>
the compositor knows where it needs to paint the buffer
<emersion>
so, your concern is maybe, device where the buffer will be painted cannot import the buffer, there are 2 other devices where the buffer can be imported, what's the most optimal?
<emersion>
does this really happen?
<emersion>
what's an example of this?
jsa has joined #dri-devel
LeviYun has joined #dri-devel
<zamundaaa[m]>
emersion: an example would be a laptop with iGPU, dGPU + an external GPU
<emersion>
zamundaaa[m]: these devices cannot import each others buffers without moving
<zamundaaa[m]>
If a buffer from the eGPU needs to be presented on the dGPU, but direct import doesn't work, then the compositor could either blit to a compatible buffer on the eGPU and then copy that over, or it could first copy to system memory and then to the dGPU
<MrCooper>
DavidHeidelberg: I'm quite skeptical about getting any progress on the LTO boss problem(s) just from CI, given how random they've been
<MrCooper>
emersion: "not pinning" doesn't help for the case I described, where the buffer already resides in system RAM
<emersion>
MrCooper: why not?
<MrCooper>
being in system RAM is bad even if not pinned
<emersion>
being in system ram is not a consequence of the import
<emersion>
something else triggered it
<zamundaaa[m]>
emersion: both iGPU and eGPU can access the buffer directly, but only one of them is efficient
<MrCooper>
it could still mean the importing GPU can only access it in system RAM, in which case there would be migration ping-pong between the exporting GPU's VRAM and system RAM
warpme has quit []
<zamundaaa[m]>
Even if the kernel could tell us which import would be more efficient, the protocol changes are still useful
<zamundaaa[m]>
To tell the client which devices it can expect the compositor to handle
<zamundaaa[m]>
And which GPUs are preferred over others
<emersion>
I need to run, will reply later
<MrCooper>
I tell you I don't have time right now, you drag me into it anyway, then you need to run? Great ;)
<DavidHeidelberg>
:D
<MrCooper>
that might have been too harsh depending on the reason for needing to run, in which case I'm sorry
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
<DemiMarie>
Why would the protocol and the kernel change be mutually exclusive?
karenw has quit [Remote host closed the connection]
sander192 has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
androidui has quit [Remote host closed the connection]
ZLangJIT has joined #dri-devel
ZLangJIT is now known as androidui
tobiasjakobi has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
fahien has joined #dri-devel
tobiasjakobi has quit []
fahien has quit [Ping timeout: 480 seconds]
<zf>
bnieuwenhuizen: thanks. of course it tripped me up because that flag is never mentioned in VUIDs, which effectively contradict the relevant parts of the spec
<zf>
love vulkan :-)
kts has quit [Quit: Leaving]
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
sassefa has quit []
cyrinux has quit []
cyrinux has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
<zmike>
I just fixed some related parts of the spec recently around whether creating planar views was even legal (obviously it is), so it's not surprising there are other bugs in the same area
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
sander192 has quit [Remote host closed the connection]
scandals9 has joined #dri-devel
scandals9 has quit [Remote host closed the connection]
sabotage1 has joined #dri-devel
sabotage1 has quit [Remote host closed the connection]
fahien has joined #dri-devel
ranawaywith has joined #dri-devel
ranawaywith has quit [Remote host closed the connection]
hopelessman has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
anujp has joined #dri-devel
fahien has joined #dri-devel
smaeul has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
smaeul has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fahien has joined #dri-devel
a1batross has joined #dri-devel
<DavidHeidelberg>
karolherbst: I see rusticl now reports CL_DEVICE_IMAGE_SUPPORT: CL_TRUE, but CL_DEVICE_MAX_READ_IMAGE_ARGS: failed, expected at least 128, got 16
<DavidHeidelberg>
by spec, when CL support image, it needs to report 128
fahien has quit [Ping timeout: 480 seconds]
<DavidHeidelberg>
while rusticl reads PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS and pass it
DPA has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
DPA has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
Caterpillar has quit [Read error: No route to host]
Caterpillar has joined #dri-devel
hopelessman has quit [Remote host closed the connection]
hopelessman has joined #dri-devel
hopelessman has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
karenw has joined #dri-devel
karenw has quit []
karenw has joined #dri-devel
<karolherbst>
you don't need 128 with the embedded profile
<karolherbst>
DavidHeidelberg: piglit is just unreliable with everything in regards to those caps, because it just hardcoded against clover + r600
Duke`` has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
gouchi has quit [Quit: Quitte]
fahien has quit [Ping timeout: 480 seconds]
cphealy has quit [Read error: No route to host]
ondracka has quit [Ping timeout: 480 seconds]
CME has quit [Read error: Connection reset by peer]
CME has joined #dri-devel
fahien has joined #dri-devel
<DavidHeidelberg>
The spec say "Max number of image objects arguments of a kernel declared with the read_only qualifier. The minimum value is 128 if CL_DEVICE_IMAGE_SUPPORT is CL_TRUE, the value is 0 otherwise."
<DavidHeidelberg>
which seems pretty explicit. Maybe I'm missing some extension adjusting this paragraph?
<DemiMarie>
What are the plans for long running compute on Asahi? My understanding is that that will require long-term pinning of memory, but I think that it is better to have that as an option than to not offer it at all.