<pq>
hwentlan, I see you have posted "drm_plane API to support HDR" RFC, and I'd like to let you know that I probably don't have time for it in August.
<pq>
that ^ goes for all dri-devel stuff, FYI
bcarvalho has joined #dri-devel
xexaxo_ has joined #dri-devel
yogesh_mohan has quit []
<danvet>
melissawen, I'm assuming you'll review the latest patch set from Sumera ?
sdutt__ has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
yogesh_mohan has joined #dri-devel
yogesh_mohan has quit []
yogesh_mohan has joined #dri-devel
tursulin has joined #dri-devel
<emersion>
thanks for the heads-up, but i'm afraid i'm not that interested in kernel self-tests
<airlied>
MrCooper, anholt_ : I've figured this out before but failing to do it again, where to the replay traces live?
<alyssa>
Question for kernel people: what's the rules around `float` for platform drivers?
<alyssa>
(and specifically arm64, whose FPU is probably less broken than x86?)
vivijim has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
<emersion>
alyssa: on x86, the floating point registers are not saved/restored, so you can't use them without a special guard
<emersion>
alyssa: see kernel_fpu_begin/kernel_fpu_end
frieder has joined #dri-devel
<siqueira>
alyssa for arm, you probably want to take a look at kernel_neon_begin/kernel_neon_end. Unfortunately, the FPU API is not unified in the kernel, and every architecture has its function name.
sdutt__ has quit [Ping timeout: 480 seconds]
<alyssa>
siqueira: Oh boy..
<alyssa>
What about just storing floats?
<alyssa>
(Like, as plain old data u32 even though it's actually a float and only a single routine needs to pack/unpack the float)
<emersion>
there might be fixed point helpers somewhere
<emersion>
(if floats aren't usable)
camus1 has quit []
<alyssa>
emersion: hmm, right
xexaxo_ has quit [Read error: Connection reset by peer]
<alyssa>
anything like mesa's fui() / uif()
<alyssa>
?
xexaxo_ has joined #dri-devel
<emersion>
sorry, i have no idea :P
sdutt__ has joined #dri-devel
Company has joined #dri-devel
sdutt has joined #dri-devel
sdutt__ has quit [Read error: Connection reset by peer]
levandi has joined #dri-devel
<siqueira>
alyssa From my experience with amdgpu dc, I recommend avoiding FPU if possible. Keep in mind that you will probably need to add some of the gcc fpu flags in your Makefile (e.g., -mgeneral-regs-only, -mhard-float, -msse, etc), which can be a problem in the ARM context. Ard said this about arm support in AMD: "[..] Note that putting
<siqueira>
kernel_neon_begin() and kernel_neon_end() around the code that does use FP is not sufficient here, the problem is in all the other code that may be emitted with references to SIMD registers in it.[..]" Ref: commit 'drm/amdgpu/display: drop DCN support for aarch64'.
levandi has left #dri-devel [#dri-devel]
<alyssa>
siqueira: The mailbox interface for the hardware uses honest-to-goodness IEEE 754 floats, my hand is forced here.
xexaxo_ has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
<alyssa>
thanks 🍎
<siqueira>
alyssa In that case, try to isolate everything that needs FPU operation in a single file and only use the fpu flags for that file. Maybe the approach suggested in this patch can be useful for you: https://patchwork.freedesktop.org/series/93041/ . If you plan how to use FPU before start to use it, you will be fine.
aravind has quit []
<melissawen>
danvet, yes, I will. btw, we did not reach a decision on the crc capture approach for this feature.
<melissawen>
I still think about the idea of computing one crc as a proof of crc support
<melissawen>
because I do not like the idea of just ignoring all crc testcases
<melissawen>
do you have any thoughts on it?
<melissawen>
siqueira, Sumera ^
macromorgan has quit [Remote host closed the connection]
xexaxo_ has quit [Read error: No route to host]
<siqueira>
melissawen It has been a while since I looked at virtual hw; for this reason, I don't have any opinion about that right now :(
<emersion>
siqueira, but virtual hw is your whole childhood :P
xexaxo_ has joined #dri-devel
<Sumera>
melissawen: yeah, I agree, I think we could try faking the polling event or something for starters
<danvet>
melissawen, I think one-shot crc support makes some sense, but it will mean a ton of changes to igts to make sure it keeps working
heat has joined #dri-devel
<danvet>
mlankhorst, did you do the backmerge as a fast-forward?
<danvet>
in drm-misc-next
sdutt has quit []
sdutt has joined #dri-devel
tzimmermann has joined #dri-devel
macromorgan has joined #dri-devel
<alyssa>
siqueira: Oof, thanks
<alyssa>
I picked the wrong hw to do my first real kernel driver for, eh? 😉
jkrzyszt has quit [Ping timeout: 480 seconds]
<alyssa>
oh well, back to Mali where things are ... uh ...
<jekstrand>
alyssa: Oh, come on. Floats in kernel-space make everything more "fun" :)
frieder has quit [Remote host closed the connection]
<danvet>
melissawen, but also maybe for a start we can go with crc-less virtual mode?
<danvet>
just to get this going
<danvet>
Sumera, ^^
<danvet>
alyssa, soft-fpu?
<danvet>
as in do all the computations in fixed point, and then just convert
<danvet>
"just"
<jekstrand>
zmike: Is there a version of drawoverhead that does a glFlush() between draw calls?
<jekstrand>
zmike: danvet and I need an execbuf micro-benchmark that runs through iris.
<zmike>
uhhhh
<danvet>
alyssa, the fpu-in-kernel stuff really only worth it if you share all the code with otheros and they do use it freely there
<danvet>
if you write it all yourself, fixed point everywhere is much less pain
<zmike>
jekstrand: no, I think it's just expected that drivers manage that
<zmike>
but you could add a case for it pretty trivially
<jekstrand>
zmike: Ok, sounds good
<jekstrand>
danvet: I think the problem is that there are HW packets that take IEEE754 floats. 'cause Apple.
<danvet>
yeah but converting from your fixed point to float32 once is a lot more doable than computing float32 in the kernel
<jekstrand>
alyssa: If you can't find helpers, there are some nice liberally licensed softfloat libraries kicking around that you can use.
<jekstrand>
alyssa: fixed->fp is easy. No nans to worry about.
<jekstrand>
Should be mostly a matter of finding the high bit and computing an exponent.
<jekstrand>
Then maybe dealing with rounding if you care
<jekstrand>
We should have NIR code for it you can look at. Also fp64.glsl
thellstrom has quit [Remote host closed the connection]
<alyssa>
danvet: Yeah, that makes sense. Still looking for helpers to do IEEE754 <--> fixed point conversion in kernel then.
<danvet>
not sure that exists
<alyssa>
and a typedef for uint32_but_actually_its_a_float for passing around the opaque data
<danvet>
we're not that big on type safety
<danvet>
but strictly speaking you can build something with sparse' bitwise stuff
<ajax>
void *
thellstrom has joined #dri-devel
<alyssa>
danvet: float* this i'm rewriting in rust 🙃
<alyssa>
jekstrand: if it comes to that, thank you 👍
<danvet>
alyssa, typdef u32 __bitwise my_float_t
<danvet>
is how you do this in the kernel
<danvet>
if you then check with sparse it'll complain if you try to access it like a normal u32
<graphitemaster>
What sort of float operations do you got to do here, like all the ALU or just some minor specific things? Because if just the latter I'd suggest just union the float and a uint32_t and do it raw
<danvet>
(or uint32_t or whatever you like)
<danvet>
without an explicit cast
<danvet>
it's used for all kinds of types and stuff
<alyssa>
danvet: lovely. thanks :)
<alyssa>
Apple sure makes everything "fun"
<jekstrand>
alyssa: Could be worse. You could be the one having to write a i-can't-believe-it's-not-json parser. :D
<danvet>
alyssa, for example read linux/gfp.h and gfp_t
<alyssa>
marcan: ❤️
<danvet>
apparently cast needs to be done with (__force gfp_t) to get it through
<danvet>
ofc gcc wont see any of this, need to install sparse and build with C=1 or C=2
<jekstrand>
alyssa: Out of morbid curiosity, what on eart is the kernel programming that needs floats?
<jekstrand>
Fixed-point would surprise me for just about anything exept maybe power management.
<jekstrand>
alyssa: Ok, I can believe that, I guess.
<alyssa>
"I guess"
<jekstrand>
Color curves make sense
<jekstrand>
Still horrible but it makes a little sense
nchery has joined #dri-devel
<danvet>
jekstrand, kms is full of fixed point fun
<alyssa>
danvet: did I pick the wrong subsystem to start out on?
<alyssa>
or just the wrong vendor
<danvet>
both?
<danvet>
:-P
<jekstrand>
alyssa: Maybe the real mistake was starting at all. (-:
<alyssa>
marcan: Let me know when you need that liability waiver signed from me 😉
<graphitemaster>
alyssa, Do you have to do something with that float contrast other than marshal the value to the hardware?
<alyssa>
Dunno yet
Duke`` has joined #dri-devel
<jekstrand>
alyssa: Just set it to 0x3f800000
<danvet>
alyssa, yeah the 0-order mistake is "kernel driver hacking should be fun" ...
<danvet>
it's mostly lots of pain to justify the occasional celebration :-)
<alyssa>
danvet: Look I paid C$1000 for this machine I better be able to read my code in 4k ;p
<danvet>
oh it doesn't boot in 4k?
<alyssa>
1080p
<danvet>
booo
<ajax>
standard tbh
<ajax>
dual-link dvi monitors usually booted at 1280x800
h1x has left #dri-devel [#dri-devel]
<jekstrand>
alyssa: 1000 CAD? Hardly seems worth it. If it'd been USD, on the other hand... :-P
<graphitemaster>
It's $1000 USD for the non-float-in-kernel-space version
<jekstrand>
:D
<alyssa>
jekstrand: rude
<alyssa>
:p
<jekstrand>
alyssa: $1000 and not having 4K does seem like a perfectly good justification for 1000 hours...
* jekstrand
should do work and stop snarking
<alyssa>
Jokes on you I can work and snark at the same time
Ahuj has quit [Ping timeout: 480 seconds]
<graphitemaster>
Can the M1 drive the Pro XDR display
<graphitemaster>
That's 6K right
Peste_Bubonica has quit [Quit: Leaving]
xexaxo has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
Hi-Angel has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
gouchi has joined #dri-devel
jkrzyszt has joined #dri-devel
gpoo has quit [Remote host closed the connection]
K`den has joined #dri-devel
Kayden has quit [Read error: Connection reset by peer]
Ahuj has joined #dri-devel
<mlankhorst>
danvet: yes
<danvet>
mlankhorst, generally an explicit backport is best, even if it's non-fastforward
<danvet>
dim backmerge should take care of that, if not, we should fix it
<danvet>
the reason is that for these big things it's always good to record a reason
K`den is now known as Kayden
Peste_Bubonica has joined #dri-devel
<danvet>
hm yeah no --no-ff in there
ngcortes has joined #dri-devel
<tzimmermann>
zackr, did you see my message about the lost patches. one of them is empty when cherrypicked into drm-misc-fixes. is that expected?
<jekstrand>
Is there a central place to figure out what patches gregkh failed to apply to stable?
lemonzest has quit [Quit: Quitting]
jessica_24 has joined #dri-devel
<zackr>
tzimmermann: sorry, i missed the message. i just checked and i do see that the implicit declaration fix is in both branches (drm-misc-next-fixes and drm-misc-fixes). hmm, i'm guessing i messed up cherry-pick and used drm-misc-next-fixes as a base because that change has already gotten all the way to Linus' tree. it's fine if it's empty (or if you want to keep the history just nuking it out of drm-misc-next-fixes would be fine too)
jkrzyszt has quit [Ping timeout: 480 seconds]
vivek has joined #dri-devel
<tzimmermann>
zackr, i see. i'll cherry-pick the other one and ignore the empty patch.
jagan_ has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<graphitemaster>
Okay so just doing the LD_LIBRARY_PATH= thing before it should be enough
<Venemo>
alyssa: you asked for a ping today about MR 8056 - so, here is a pingy ping
Hi-Angel has joined #dri-devel
<alyssa>
Venemo: Shoot!
<alyssa>
You win, let's read this MR :p
* alyssa
pauses Tom Lehrer
<Venemo>
thanks alyssa
<Venemo>
this stuff would help a sore spot for us
gouchi has quit [Remote host closed the connection]
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #dri-devel
<airlied>
pepp: thanks!
<graphitemaster>
Why would you pause Tom Lehrer to read an MR
gouchi has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<alyssa>
Venemo: the deed is done
* alyssa
reumses Tom Lehrer
mlankhorst has quit [Ping timeout: 480 seconds]
<Venemo>
alyssa: thanks!
rasterman has quit [Remote host closed the connection]
<alyssa>
Venemo: Poisoning pidgeons in the paaaark
Ahuj has joined #dri-devel
mbrost has joined #dri-devel
<HdkR>
Those poor borbs
rasterman has joined #dri-devel
danvet has quit [Read error: Connection reset by peer]
Ahuj has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
gouchi has quit [Remote host closed the connection]
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
pcercuei has quit [Quit: dodo]
ngcortes has quit [Ping timeout: 480 seconds]
iive has quit []
<alyssa>
danvet: et al: Other question, is there a preference for separate display/3D drivers or stuffed into the same driver? for hardware by the same vendor used on the same SoC, but otherwise completely unrelated hardware with no shared code except the drm_dev_register call
<alyssa>
(I guess there's probably precedent for both approaches.)
<airlied>
alyssa: I'd go separate
<anholt_>
vc4 was stuffed in the same driver, but we ended up having to do kmsro support anyway so it didn't help in the long run.
<airlied>
alyssa: we normally only do single drivers where there's a PCI device
<alyssa>
Got it, thanks :)
<alyssa>
anholt_: I'm not scared of kmsro :-)
NiksDev has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<airlied>
alyssa: though maybe it'll help to have all the binary json in one module :-P
<alyssa>
😇
meesmetsast has joined #dri-devel
meesmetsast has quit []
<alyssa>
if agx is more sketchy RPC....
<airlied>
I came to program hardware and all I got was this sketchy RPC interface
<alyssa>
airlied: mood
<airlied>
alyssa: would need zmike to figure out the correct meme for it :-P
<alyssa>
airlied: you'd think i'd know, being a zoomer, but i dont