ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tzimmermann has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
ngcortes has quit [Ping timeout: 480 seconds]
CME has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: that's what caused my problem!
<alyssa>
jekstrand: Ah, wise
<karolherbst>
then.. don't write your own?
<alyssa>
but then I won't have 4k!
<anholt_>
freedreno test farm is back up, now with 2 more runners. let me know if you see anything strange.
<karolherbst>
alyssa: mhh sad
<pinchartl>
alyssa: isn't that issue solved by this "code review" process where you throw very fragile code to a mailing list and expect someone to rewrite it for free ? at least some SoC vendors think this way :-)
<karolherbst>
pinchartl: I thought they only publich perfect code? I mean.. they have internal processes and everything!
<pinchartl>
(no, I won't name any, and for all of you here who work for SoC vendors, you're obviously among the good ones, it's your competitors who are bad)
<pinchartl>
some indeed publish perfect code only
<alyssa>
pinchartl: Hmm, that worked for the PCIe driver
<alyssa>
🙃
<pinchartl>
but the consequence is that they don't publish anything
<alyssa>
Idk
<karolherbst>
pinchartl: well, if you have to pay for the software it's better anyway
<alyssa>
how do I get better at writing kernel code? it's harder than userspace for me
<karolherbst>
alyssa: you write more code
<pinchartl>
+1
<pinchartl>
practice is the key, really
<alyssa>
fair.
<karolherbst>
and after a while you learn that removing code is also an option
<pinchartl>
and review, jokes aside
<alyssa>
I suppose I should have started with a less jank driver as well
<pinchartl>
but that goes both ways
<pinchartl>
you learn from other people reviewing your code
<pinchartl>
but you can also learn from reviewing other people's code
<pinchartl>
which driver is this ?
<pinchartl>
and have you written it from scratch, or are you trying to stabilize an existing code base ?
<alyssa>
currently writing a display driver for an awful Apple hack of a firmware
<pinchartl>
ah, that one
<alyssa>
admittedly would've been easier starting with hardware that I had docs on
<alyssa>
or with hardware I actually had access to and not tunnelled through a NIH firmware
<karolherbst>
mhhhh
<pinchartl>
there's a short supply of that
<karolherbst>
rust bindings for nir? mhhh
<airlied>
alyssa: read more kernel code :-P
<pinchartl>
and docs are not always as good as one may hope (that's a strong euphemism)
<alyssa>
well aware
<pinchartl>
airlied: the trick is to figure out which kernel code to read
<alyssa>
airlied: there's so much of it!
<pinchartl>
as different drivers are bad in different ways
<alyssa>
but yes have been reading a lot
<airlied>
pinchartl: indeed there is
<airlied>
incoming patches in a similiar area are always a good place to start
<pinchartl>
alyssa: I've also found that over-documented my code in areas that I'm not very experienced with helps putting my thoughts straight
<pinchartl>
and over time, as I get more familiar in such areas, comments disappear
<alyssa>
Hmm, alright
<alyssa>
I dunno I'm probably doing okay all things considered
<alyssa>
Just trying to tread water in the deep end
<pinchartl>
so that the next person to read my code gets as puzzled as I was in the beginning :-)
* pinchartl
goes back to camera work
<alyssa>
good luck..
<pinchartl>
anyone interested in image processing algorithms and/or ISP reverse-engineering, by any chance ? :-)
<pinchartl>
thanks
<alyssa>
pinchartl: was that an attempt at a nerd snipe
<pinchartl>
a very bad one, yes
<alyssa>
because i'm still trying to unfsck the m1 gfx stack
<pinchartl>
I was talking with danvet earlier today, and told him that ISP r/e is an order of magnitude more complex than GPU r/e
<alyssa>
yeah?
<pinchartl>
(is that a better nerd snipping attempt ? :-))
<alyssa>
(yes :-) )
<pinchartl>
not that it means GPU are easy
<pinchartl>
but that ISPs are close to impossible
<alyssa>
why?
<pinchartl>
so, like GPUs, you have undocumented hardware, and a userspace binary blob
<pinchartl>
so far, so good
<alyssa>
sure
<alyssa>
well, "good", but sure
<pinchartl>
the output of the hardware is an image that you can inspect, so it's also similar to a GPU
<pinchartl>
the issue is the input
<pinchartl>
for GPUs, your input is a well-documented fine-grained API (including a shader language) where you can change lots of tiny knobs to see what happens
<alyssa>
right
<pinchartl>
and if you run the same test twice, it should (hopefully) lead to the same result
<alyssa>
hopefully, but yes
<pinchartl>
with ISPs, the input is a live stream from a camera sensor, and very high-level parameters such as "enable or disable auto-exposure" that are transformed by the binary blob into thousands of values
<pinchartl>
the hardware has more or less a fixed pipeline
<pinchartl>
and the binary blob is stateful, it implements big feedback loops
<pinchartl>
the hardware also outputs statistics, in an undocumented format. that part is a bit easier to r/e, assuming you know enough about the ISP to program the statistics engine already
<pinchartl>
as you can feed a test pattern and try to see how the statistics change
<pinchartl>
so I'd compare it as having to r/e a GPU by playing a game, and trying to figure out the command stream from your gameplay
<alyssa>
ooh, yikes
<alyssa>
~ghidra?~
<robclark>
pinchartl: I suppose it is good in a way that we have gotten to the point where camera is the long-pole from upstream standpoint.. but yes, I agree, that camera is a cluster-f***.. on the snapdragon chromebooks (and I think it is similar w/ mtk, etc), that is where we have a pile of downstream patches and despair
<robclark>
and when it comes to android phones.. probably as many or more vendor engineers working on camera as gpu
<pinchartl>
robclark: the qcom camera stack has a closed-source userspace component that more or less prepares a set of register address/value pair that is passed to the kernel
<robclark>
yup
<pinchartl>
goodbye security
<alyssa>
pinchartl: so how do we fix it?
<robclark>
get nerds excited about cameras?
columbarius has joined #dri-devel
<robclark>
(I mean, it worked for gpus :-P)
<pinchartl>
some vendors are more supportive, it's easier to start with those
<pinchartl>
(btw, speaking of r/e a GPU by playing a game, if you haven't seen the super mario bros 3 speed run that requires assembly programming, https://www.youtube.com/watch?v=WWbZFj-cLvk)
co1umbarius has quit [Ping timeout: 480 seconds]
<alyssa>
robclark: i'm not a--
<alyssa>
i'm not excited about gpus!
<bnieuwenhuizen>
I mean we hear you on IRC about being less excited about a certain one :)
<HdkR>
Isn't that just a display controller making pain as usual? ;)
<alyssa>
this is a stupid game of debug.
<robclark>
I think you can be excited about gpu's and annoyed by display controllers at the same time.. display controllers are the gpu nerd's necessary evil ;-)
<alyssa>
robclark: i just don't like pidgeon holing myself
<robclark>
alyssa: gpu's are a pigeon mansion
<robclark>
I mean, vendor/blob team is actually probably three different teams at least ;-)
<alyssa>
No
<alyssa>
*Nod
<dcbaker>
karolherbst: the problem is that setuputils always does in tree builds, meson always does out of tree builds
<dcbaker>
But it's still the "we assume you're going to use build-system X"
<karolherbst>
ahh
<dcbaker>
the cython community seems interested in helping us out, so that's nice at least. I guess it kinda helps that Python realized having a single build-system for all python didn't really work, it wasn't flexible enough for complex cases (without resorting to writing python code), and was too complex for simple cases
<pinchartl>
dcbaker: any luck they would help our meson + android issue, while at it ? :-)
<dcbaker>
lol, wouldn't that be nice :)
<dcbaker>
I suspect Meson + android will just have to wait until enough projects google cares about use Meson, and then they'll just solve it themselves, honestly :/
<alyssa>
i'm real starting to believe this "the hardware hates me" theory
<dcbaker>
maybe we can convince Linux to use Meson, lol
Lucretia has quit []
<karolherbst>
lol
* robclark
would be a huge fan of getting python as a build dependency for kernel for free
<karolherbst>
"then I need python to build linux?!?!? but my 1MB RAM SoC which won't be able to build linux anymore!!11!!!!!!"
<pinchartl>
:-)
<airlied>
you can have python if you first remove all the perl
<karolherbst>
airlied: you mean like start with git and then...
<pinchartl>
:-D
<karolherbst>
"but perl doesn't use 500MB of RAM!!!"
<kisak>
I'd be more concerned about rust and needing 1GB more memory per core during the compile
<karolherbst>
but actually
<pinchartl>
we've been trying to move v4l-utils from autotools to meson for about a year, but it has encountered some resistance :-(
<karolherbst>
python runs on less platforms I think
<airlied>
at this point I doubt it matters
<pinchartl>
maybe it's not a coincidence that the resistance comes from the perl camp :-)
<karolherbst>
pinchartl: the python or the "I have everything new" kind?
<karolherbst>
pinchartl: lol
<airlied>
I'm not sure anyone is learning perl anymore :-P
<pinchartl>
karolherbst: both actually
<karolherbst>
pinchartl: change the community ¯\_(ツ)_/¯
<karolherbst>
pinchartl: ohh I have an idea
<karolherbst>
just rewqrite v4l-utils in rust
<karolherbst>
*rewrite
<pinchartl>
I'll comment on that under NDA only :-D
<pinchartl>
(or rather under chatham house rules)
<karolherbst>
maybe we'll have a fosdem next year?
<pinchartl>
in 2022 that seems quite unlikely
<karolherbst>
ehhh, maybe
<pinchartl>
under normal circumstances I always catch a cold or worse at the fosdem
<pinchartl>
so in a pandemic...
<karolherbst>
well, but people are more vaccinated ... maybe.. at least from.. rich countries and stuff...
<pinchartl>
open-source vaccine ? :-)
<karolherbst>
might sound drastic, but could be vaccinated only, which would be an asshole move though
<pinchartl>
(that would be an interesting project)
<karolherbst>
pinchartl: well.. it kind of is already
<karolherbst>
you mean a FOSS vaccine!
<pinchartl>
yes :-)
<bnieuwenhuizen>
so lesson from last XDC, if you want to chat, it is easy to just create random rooms, doesn't need to be offical channels only. Not sure how much that aligns with your chatham rules
<pinchartl>
bnieuwenhuizen: as long as there's no anonymous lurker in the room, it could work
<karolherbst>
ohh, right
<karolherbst>
I think I am in a better mood this year, so I might even join those chatty rooms :D
<pinchartl>
some conversations require drinks too though
<karolherbst>
mhhh
<karolherbst>
gitlab integration? :O
<alyssa>
pinchartl: it's just like the real thing! with random guys in fedoras lingering in the back with partially obscusred name tags... just listening
<karolherbst>
alyssa: you mean those RH folks?
<alyssa>
karolherbst: Oh. Right.
<kisak>
how would you manage pull requests to an opensource vaccine? do a test run on a test group?
<alyssa>
kisak: CI! Requires giving injections to 5000 people before every merge.
<karolherbst>
kisak: yep
<bnieuwenhuizen>
do we need to wait for the results before we start the testing for the next merge a la marge-bot?
<karolherbst>
alyssa: ... :D
<alyssa>
ok this is bizarre now
<pinchartl>
too late at night / too early in the morning / too much alcohol / too little alcohol : pick your excuse
<pinchartl>
I usual tick the first two together
<alyssa>
ah, the wonderful time of 3am
<pinchartl>
I personally like the concept of 14:00am
<HdkR>
Who do I shame for VC4 and V3D not packing their ioctl structs correctly? :P
<bnieuwenhuizen>
HdkR: nobody. That is not a friendly thing to do :P
<anarsoul>
HdkR: git blame :)
<HdkR>
hehe
Bennett has quit [Remote host closed the connection]
<HdkR>
I get to do the fun thing of 64-bit ioctl emulation now if I want to support those correctly
<HdkR>
misalignment due to 64-bit handles, bweh
ngcortes has joined #dri-devel
slattann has joined #dri-devel
Company has quit [Quit: Leaving]
jhli has quit [Ping timeout: 480 seconds]
<HdkR>
Shame to bbrezillon for DRM_IOCTL_VC4_PERMON_GET_VALUES, and shame to anholt_ for DRM_IOCTL_V3D_SUBMIT_CSD :)
<HdkR>
My tooling captured it, Feels like other people should have similar tooling to notice when ioctl struct definitions don't match across architectures
<airlied>
HdkR: you should just write a kernel tool like header check\
<airlied>
that gets run in kernel builds
<alyssa>
pinchartl: IOMMUs, like device trees, turn my brain to guacamole
<HdkR>
But then I'd have to try and be a kernel developer and we've seen how that goes
<pinchartl>
alyssa: if I had to pick, I'd go for device tree
<alyssa>
HdkR: hey same
<alyssa>
pinchartl: Aaahhhh
<pinchartl>
although I'd probably pick guacamole...
<alyssa>
hahaha
<alyssa>
I need to uhhhh
<alyssa>
walk the existing IOMMU mappings and tell linux about them I guess? maybe?
<alyssa>
i don't understand io-pgtable-arm.c even a litte
<jekstrand>
But do you understand it a latte?
<alyssa>
NOpe
* jekstrand
neither
* jekstrand
doesn't drink that stuff. :P
<pinchartl>
alyssa: it's been a long time since I've touched IOMMUs. pretty much since my talk on the topic :-)
<alyssa>
lucky
gpoo has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
ickle has quit [Remote host closed the connection]
ickle has joined #dri-devel
<alyssa>
io-pgtable-arm.c confuses me
<HdkR>
If it is anything like touching PML4, then yes. pain
<alyssa>
okay first things first, where do I find docs on these pgtbl formats..
thaytan has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
thaytan_ has quit [Remote host closed the connection]
thaytan has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
slattann has quit []
muhomor has quit [Ping timeout: 480 seconds]
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
flto has quit [Remote host closed the connection]
<jenatali>
dcbaker: You've convinced some Microsoft people to use Meson for some projects, so that's something at least
<dcbaker>
I'll take it!
flto has joined #dri-devel
<karolherbst>
jenatali: I guess cross plattform and everybody hates cmake/scons/whatever?
<jenatali>
Basically
<karolherbst>
But I have to say, cmake isn't all that bad, I've done terrible things with it
<jenatali>
Yeah, we've got a fair amount of CMake on our team these days, it's got pros and cons compared to Meson. I like both but for simple things I prefer Meson
ngcortes has quit [Remote host closed the connection]
<jenatali>
I quite like CMake's FetchContent contrasted against Meson's subprojects/wraps, in that the dependency is stored in the top-level build tree, instead of at the Nth level source tree
<karolherbst>
I like about cmake that you can do random shit with the DSL itself :D
<karolherbst>
it goes so far, that there is a cmake project out there you can include and then you get PCH enabled in one line for each target
<karolherbst>
try enabling PCH in meson
<karolherbst>
although I guess explicitly declaring your PCH header file does have advantages
<jenatali>
I mean CMake also made PCH a first class citizen recently-ish, it does only need one line
<karolherbst>
cool
<karolherbst>
but do you have to write your header file still? :D
<karolherbst>
there was this cool project which was scanning source files and collected them on its own or something
<karolherbst>
dunno
<karolherbst>
it was magic
<karolherbst>
and it ended up being faster then any hand written pch file I was able to achieve
<karolherbst>
*come up with
<jenatali>
Oh interesting. No this is just declaring a header as a PCH and then it's force-included in all your sources
pendingchaos has quit [Read error: No route to host]
rgallaispou has joined #dri-devel
pendingchaos has joined #dri-devel
<karolherbst>
I don't want to think about details like "how do I have to write this PCH header file" :D
<karolherbst>
I think what meson is doing is way too much and it could be as simple as the cmake thing
<karolherbst>
why pushing this "yeah, but MSVC sucks, so you have to do this and this" down to the developer
rgallaispou1 has quit [Remote host closed the connection]
<karolherbst>
but I guess not writing a header file might lead to some extreme parsing overhead, so I understand why cmake wants to be explicit here at least
<dcbaker>
The meson way is "write a .h file with some #includes in it" that doesn't seem very hard to me
<karolherbst>
dcbaker: it's more than I want to do :p
<karolherbst>
I just want to list headers
<dcbaker>
especially since you only want to pch external headers, since if any of the headers change it forces a full rebuild
<karolherbst>
at most
<karolherbst>
actually.. I just want it the cotire way: "enable PCH"
<dcbaker>
you know, we could probably add a module for that...
<karolherbst>
yeah
<karolherbst>
would be cool :D
<karolherbst>
but I think I'd hide this "MSVC is special" thing away
<karolherbst>
like cmake is doing
<karolherbst>
the point is to not have to think about those stupid deals
<dcbaker>
in recent versions of Meson (>= 0.56) we do hide that
<dcbaker>
you don't need the .c/cpp file anymore, we'll generate it for you at configure time
<dcbaker>
I don't think it's well documented though
<karolherbst>
ahh cool
<karolherbst>
yeah. not menitoned in the docs
<karolherbst>
ohh
<karolherbst>
wait
<karolherbst>
my fault
<karolherbst>
I didn't saw the first sentence
<karolherbst>
"Since Meson version 0.50.0, precompiled headers with MSVC work just like with GCC. Meson will automatically create the matching pch implementation file for you."
<karolherbst>
then I guess that's fine
<karolherbst>
maybe we want to use PCH in mesa :D
<karolherbst>
like... for the basic stuff
<karolherbst>
nir.h ..
<karolherbst>
or ...
<karolherbst>
gl.h
<karolherbst>
:D
<karolherbst>
anyway.. I should sleep
pendingchaos has quit [Remote host closed the connection]
<dj-death>
shocking news: I don't know how to write detph
<dj-death>
dpeth
<dj-death>
depth!
<imirkin_>
i think you proved your point...
<imirkin_>
dj-death: btw, you shouldn't need to require GL >= anything. the GLSL >= 1.10 should be enough (which is aka GL 2.0 btw)
JohnnyonFlame has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
<dj-death>
imirkin_: thanks will update
<dj-death>
imirkin_: do you know how one runs the compiler tests?
<imirkin_>
glslparsertest
<dj-death>
imirkin_: shader_runner complains about the missing [require] block
<dj-death>
thanks!
<imirkin_>
(which takes a variety of arguments)
<imirkin_>
i'd be lying if i said i remembered what they were
xexaxo_ has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
thellstrom has joined #dri-devel
i-garrison has joined #dri-devel
slattann has quit []
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
Peste_Bubonica has joined #dri-devel
bcarvalho has quit [Ping timeout: 480 seconds]
sturmmann has joined #dri-devel
<Venemo>
jekstrand: if you have a better suggestion for the name of nir_op_sad_u8x4 I'm listening
<dj-death>
sad :)
<dj-death>
is that the step after op_mad
NiksDev has joined #dri-devel
<Venemo>
lol
<Venemo>
dj-death: both mad and sad are valid instructions :)
<Venemo>
sad = sum of absolute differences
<bnieuwenhuizen>
they're also valid (if unfortunate) emotions
iive has joined #dri-devel
pnowack has quit [Quit: pnowack]
gpoo has joined #dri-devel
<Venemo>
bnieuwenhuizen: yeah, when reading the ISA I always imagine this is how the HW engineers felt who had to implement these instructions
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
jcline has joined #dri-devel
Company has joined #dri-devel
bcarvalho has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
<ccr>
now you just need op_happy
orbea1 has quit []
<jenatali>
Or op_glad
orbea has joined #dri-devel
<ccr>
:)
<ccr>
op_bliss
<jekstrand>
Venemo: Maybe if you threw in a python comment saying "sum of absolute difference" so the acronym makes sense?
<Venemo>
jekstrand: can do
bbrezillon has joined #dri-devel
<alyssa>
ccr: op_happy causes the GPU to shutdown cleanly and instead use llvmpipe
<jekstrand>
That's not very happy
<Venemo>
jekstrand: is there a place I can put this comment to make the NIR documentation page pick it up and add it to the documentation for this opcode?
<zmike>
tomeu: are your ci fails from infra issues or legit fails?
<jekstrand>
Venemo: No, not yet.
<zmike>
trying to decide whether to bother marging something
<jekstrand>
Venemo: I'd like to find a solution to that one day but haven't got anything yet.
<tomeu>
zmike: some infra, some legit
<zmike>
hm :/
<Venemo>
so, I should just write a sentence above the instruction in the .py file? would that be OK for you?
<alyssa>
jekstrand: Joking aside, bifrost has a +EUREKA instruction
<alyssa>
that causes all threads of the shader to exit without a warning
<alyssa>
s/warning/error/
<jekstrand>
Venemo: Yup. That's fine.
<Venemo>
ok, will do
mattrope has joined #dri-devel
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
pendingchaos has joined #dri-devel
<MrCooper>
is eglCreateImageKHR supposed to work with explicit DRM_FORMAT_MOD_INVALID ?
<rburton>
anholt_: you added src/util/format/u_format_unpack_neon.c but our builds on machines without NEON (armv5 without hard float) are now failing. are you just saying that mesa *needs* neon, or should there be a check?
<ajax>
rburton: if i could get a tested-by i'd tell marge to take care of it for you
<rburton>
yeah i'll give it a spin
Lucretia has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
<jenatali>
Out of curiosity, does anyone know if someone's ever taken a stab at hooking up EGL+GLES for Windows?
<dcbaker>
jenatali: I had it all compiling at one point, though I don't know if it actually worked
<jenatali>
dcbaker: Any chance you've got a changeset laying around? I'm interested, and would love to have a starting point that's not "from scratch"
luckyxxl has joined #dri-devel
<dcbaker>
I think the only thing we did was artificially throttle it to keep you from building shared glapi on windows
<dcbaker>
I should be clear I had GLES building, not EGL
<jenatali>
Oh, sure, but GLES without EGL isn't super useful :P
<dcbaker>
Since WGL doesn't have GLES, lol
<HdkR>
wait, did anyone ever actually ship GLES+EGL before on Windows? I know the AMD stack used to have something completely mangled and broken, but no one else right?
<jenatali>
You can build shared glapi on Windows, but right now that disables the use of TLS, since TLS can't be shared across DLLs the same way it can on Linux, and there's dragons in the non-TLS paths
<jenatali>
HdkR: I mean, there's ANGLE...
<HdkR>
Funny jokes I see :P
<jenatali>
I believe Intel ships EGL+GLES as part of their drivers as well but I'm not sure about that
<HdkR>
Hm, I haven't tested for quite a few years, maybe the situation changed a bit
Peste_Bubonica has quit [Quit: Leaving]
<jenatali>
I know when we started the GLOn12 effort, I dug in, and at least one vendor did have an EGL+GLES implementation on Windows
<jenatali>
But it wasn't all of them
<HdkR>
Back when the AMD E-450 was new I tinkered with it a bit on that stack. Could create an EGL context but it was effectively broken
<HdkR>
Sounds fun if it was supported though :)
<jenatali>
Yeah I think the EGL implementation might not be too bad, I'm a little unclear on which DLLs would end up with which code though, which matters much more on Windows than Linux
<dcbaker>
I think at one pont there was discussion of doing away with shared glapi in the future since with glvnd now, but that would probably need some work
<ajax>
was literally just poking at that
<ajax>
get out of my head
<dcbaker>
ajax: you know you want to
<dcbaker>
Tell you what, I'll make glvnd a hard requirement
<ajax>
re egl on windows there's always the option of using mesa's egl frontend using wgl for the backend
<ajax>
code that does not exist, i admit, but
<jenatali>
ajax: That'd be doable probably if we only cared about desktop GL, but I'm actually interested in GLES right now, which definitely can't work that way
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
<anholt_>
ajax: pretty cool. comments sent
shfil has joined #dri-devel
ngcortes has joined #dri-devel
Anorelsan has joined #dri-devel
hikiko_bsd has joined #dri-devel
Anorelsan has quit []
Anorelsan has joined #dri-devel
<anholt_>
sigh. turned off the two new chezas since they didn't appear to be stable. Next time I have time to work on it I'll have to give them their own tag and do some custom MRs to test those boards.
gouchi has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa>
pinchartl: Uh oh more DMA fun.
<pinchartl>
alyssa: the fun never ends
<alyssa>
:d
<alyssa>
I effectively need cross-device sharing in one driver
<robclark>
alyssa: multiple devices can hang off of the same iommu_domain
<alyssa>
I tried doing dma_map_resource(virt_to_phys(dma_alloc_coherent)) but that was not happy
<alyssa>
(effectively that. in reality allocation andmapping are separate operations since the copro runs the show)
<pinchartl>
virt_to_phys sounds like a bad start
<alyssa>
yep, the WARN_ON told me that much 😅
<pinchartl>
:-)
<pinchartl>
if you have to deal manually with physical addresses, it's usually a sign that you're doing it wrong
<pinchartl>
have you tried looking at how DRM imports a dmabuf ?
<pinchartl>
that's essentially the same use case, mapping an externally allocated buffer to the device
<pinchartl>
if your buffers only need to be shared between devices within the kernel you may not need dmabuf
<alyssa>
nod
<pinchartl>
but how dmabuf import uses the DMA mapping API to import a buffer should more or less match what you need
<alyssa>
Yeah, guess I'll look there
<pinchartl>
a possible source of inspiration
<alyssa>
(the existence of dma-bufs tells me this is possible to do, anyway)
<alyssa>
pinchartl: dma-buf seems to manipulate sgt's directly
<pinchartl>
I suppose your two devices don't share the same IOMMU space ?
<alyssa>
No, that would be too easy
hikiko_bsd has quit [Ping timeout: 480 seconds]
<alyssa>
and tying them together like robclark suggested is nontrivial given one of the IOMMUs is locked down
nchery has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<pinchartl>
then you'll indeed need to create an sgt and map it with dma_map_sgtable()
<alyssa>
sven: says that sgtables aren't necessarily contiguous
<alyssa>
though i dunno how dma-bufs would work in that case
Anorelsan has quit [Quit: Leaving]
<pinchartl>
the idea is that dma_map_sgtable() will map a possibly non physically contiguous sgt to a contiguous DMA space through the IOMMU
<danvet>
doesn't need to be contig after mapping
<alyssa>
LKML mail from robmur01 seems to say that's an implementation detail (that happens to hold on common platforms due to elaborate duct tape) and not an API invariant
<sven>
afaik map_sg only guarantees that it'll take nents entries and spit out <= nents dma-addressable entries. it just so happens that dma-iommu will merge all inputs to a single one if they are PAGE_SIZE aligned, but that's an implementation detail.
<alyssa>
...but that the raw IOMMU API will do this fine, and I think for this particular case I probably just want the IOMMU API anyway.
CME_ has joined #dri-devel
<alyssa>
can't be worse then the current hack I have of a shim driver just to probe an extra struct device * to model this hardware that's wholly owned by the copro *except* for its IOMMU
CME has quit [Ping timeout: 480 seconds]
CME has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<pinchartl>
sven: an implementatoin detail we have to rely on though
<pinchartl>
it could certainly be cleaned up
<pinchartl>
with a dma-mapping function that would take an sgt and return a dma_addr_t
CME_ has quit [Ping timeout: 480 seconds]
<alyssa>
that's really scary
Ahuj has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
luckyxxl has quit []
xexaxo_ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
CME_ has joined #dri-devel
CME has quit [Ping timeout: 480 seconds]
tursulin has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<alyssa>
pinchartl: welp, did the "fundamentally unsafe" thing and it seems to work
<alyssa>
I don't have any kittens so I dunno if they'd still be alive if I did though
<pinchartl>
which one is the fundamentally unsafe option ?
<pinchartl>
I thought it was all of them :-D
<alyssa>
dma_get_sgtable(device_a), dma_map_sgtable(device_b), use sg_dma_address() as is
<alyssa>
this seems to be how the API was intended to be used and also is totally broken for the reasons sven mentioned
<alyssa>
but now I have weston in 4k so 🤷
<pinchartl>
:-)
<pinchartl>
you can now move to camera ISP r/e, nice :-D
lemonzest has quit [Quit: WeeChat 3.2]
<alyssa>
:D
<alyssa>
Need to add some duct tape to the house of cards so it'll stop falling over
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
nchery has quit [Remote host closed the connection]
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
Ryback_ has quit [Remote host closed the connection]
unerlige has quit [Remote host closed the connection]
Ryback_ has joined #dri-devel
unerlige has joined #dri-devel
shankaru has quit [Remote host closed the connection]
sdutt has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
rsripada has joined #dri-devel
mdnavare has joined #dri-devel
sdutt has joined #dri-devel
shankaru has joined #dri-devel
ramaling has quit [Remote host closed the connection]
ramaling has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
nchery has joined #dri-devel
mauld has quit [Remote host closed the connection]
mauld has joined #dri-devel
<airlied>
screw you a306-traces, caught you before you defeated marge
gouchi has quit [Quit: Quitte]
Ryback_ has quit [Remote host closed the connection]
Ryback_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
shankaru has quit [Remote host closed the connection]
sdutt has joined #dri-devel
mdnavare has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
rsripada has quit [Remote host closed the connection]
jhli has quit [Remote host closed the connection]
rsripada has joined #dri-devel
jhli has joined #dri-devel
shankaru has joined #dri-devel
unerlige has quit [Remote host closed the connection]
unerlige has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
mauld has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
pzanoni has quit [Remote host closed the connection]
mattrope has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
mattrope has joined #dri-devel
ramaling has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
ramaling has joined #dri-devel
ngcortes has joined #dri-devel
nchery has quit [Remote host closed the connection]
achrisan has joined #dri-devel
<airlied>
dang it dead stoney instead
<anholt_>
link me the a306 fail job?
nchery has joined #dri-devel
<anholt_>
nm dug it up
<anholt_>
hangcheck in traces feels new to me.
Ryback_ has quit [Remote host closed the connection]
Ryback_ has joined #dri-devel
<airlied>
now I have to start all over agin
thellstrom has quit [Remote host closed the connection]
<airlied>
can we make marge-bot have a retry jobs list for flaky jobs
ramaling has quit [Remote host closed the connection]
ramaling has joined #dri-devel
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
aswar002 has quit [Remote host closed the connection]
unerlige has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
rsripada has joined #dri-devel
<airlied>
pretty much anything running on real hw should have a retry once option
aswar002 has joined #dri-devel
sdutt has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
pzanoni has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
mattrope has quit [Remote host closed the connection]
shankaru has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
sdutt has joined #dri-devel
jhli has quit [Remote host closed the connection]
nchery has quit [Remote host closed the connection]
cedric has joined #dri-devel
ngcortes has joined #dri-devel
mattrope has joined #dri-devel
shankaru has joined #dri-devel
<zmike>
iirc there's something like that in progress
<anholt_>
for collabora hw disappearing like that stoney, there's an MR open working on it
cedric is now known as bluebugs
<anholt_>
(this is also why basically all of iris ci is disabled)
unerlige has joined #dri-devel
<alyssa>
airlied: I guess "no testing!" is a 'benefit' of kernel work
<airlied>
alyssa: we call it non-determinsitic distributed testing :-P
<alyssa>
airlied: :d
<alyssa>
how does the clipping work for drm_plante_state src/dst rects?
<alyssa>
well
<alyssa>
I think I can answer that
<alyssa>
("incorrectly, for our hardware")
<daniels>
alyssa: wdym?
nchery has joined #dri-devel
<alyssa>
daniels: Well, the user visible symptom is that moving the cursor halfway offscreen instead causes it to be squashed in half but displayed in full
<alyssa>
clipping and scaling are entangled in both DRM and DCP, as I understand, although I guess the semantic is different? maybe?
<daniels>
well, I guess they're somewhat intangled, but they're also inviolable
<daniels>
like, src dims give you the area to pull from the fb, and dst dims give you the area to realise that on the crtc
achrisan has quit []
cef has quit [Ping timeout: 480 seconds]
achrisan has joined #dri-devel
unerlige has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
cef has joined #dri-devel
cef has quit [Ping timeout: 480 seconds]
nirmoy has quit []
cef has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
iive has quit []
<alyssa>
Oh... hardware clamps src width/height to 32x32
<alyssa>
that explains that then.
<kisak>
alyssa: out of mild curiousity, how much of a unicorn is the asahi hardware? Does it resemble older known hardware or is it wildly different?
<alyssa>
kisak: it's an iphone.
<kisak>
right, but people generally don't run not-iOS on an iPhone to tinker with the hardware
pcercuei has quit [Quit: dodo]
<kisak>
I guess I was asking how the view is from the driver dev perspective, not the hardware perspective
<alyssa>
Apple hardware is ... special
<daniels>
alyssa: eesh - presumably it allows the dst to extend offscreen then?
<alyssa>
uhm.. maybe a little
<alyssa>
if it's significanlty overscreen it gets corrupted
<alyssa>
although if apple wanted to be generous, it would allow up to 32x32 of overflow off screen to make cursors/windows work
<daniels>
heh ...
<daniels>
oh well, just reject updates when you clip out src dims < 32 then
<alyssa>
tried that, weston would freeze as soon as the cursor went partially off screen and wouldn't come back ... but I'd believe it if I broke something else
<robclark>
alyssa: are you sure the hw is really that crippled wrt overlays? Or are you missing something (like a region-of-interest setting)? You'd think coming from a phone background that they'd use overlays pretty heavily