ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
mclasen_ has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
* airlied
yeets the lvp 1.3 submission into the void
mclasen has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
sylware has joined #dri-devel
<sylware>
Hi, recent git llvm broke mesa gl for radeon (navi10 lxe), xorg crash while enable glamor. Issue already known? (could be on my side though).
<sylware>
I must compile mesa with a 2 weeks old llvm or crash.
<mripard>
danvet: hey, I'm not entirely sure about when drm_connector_unregister() is supposed to be used, and the documentation seems to have some errors
<mripard>
should it be s/drm_dev_register()/drm_connector_register()/ ?
<mripard>
and if connectors are unregistered automatically when drm_dev_unregister() run, why do we need to bother with drm_connector_unregister?
<danvet>
mripard, ah yes
<danvet>
maybe clarify that this is for hotplugged stuff
<danvet>
mripard, and maybe link between the drm_connector_register/unregister if you do a patch
<mripard>
ack, I'll send a patch
<mripard>
I'm not sure what the connection with drm_dev_unregister is though?
<mripard>
if "connectors are unregistered automatically when drm_dev_unregister() is called.", then we shouldn't need to call drm_connector_unregister at all?
<mripard>
or is it only to be called when it's hot-unplugged?
<danvet>
mripard, so the thing is that unless you do something really funny
<danvet>
a dp mst hotunplug can race with a outright pci unplug
<danvet>
since stuff can get held up and all that
<danvet>
so not-hotplugged stuff that drm_dev_register registers, is unregistered by drm_dev_unregister
<danvet>
which might also unregister a pile of hotplugged dp mst connectors
<danvet>
but for connectors that you do hotplug you must call drm_connector_unregister too
<danvet>
and the functions internally resolve races
<danvet>
assuming your driver is not outright buggy in some way and fails to stop the hpd processing worker before it tears down the drm_device
<danvet>
I tried to explain this and obviously fell very very short :-)
Ryback_ has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
I spent some more time this weekend thinking about the Vulkan blitter problem.
<alyssa>
The harder problem is of course dispatching the compute shaders or fragment shaders or whatever.
<alyssa>
The easier problem is actually constructing those shaders. Which every driver has their own nir_builder code for..
<mripard>
danvet: ok, I'll try to amend the documentation to make that clearer then, thanks!
<alyssa>
Gallium "avoids" this with the "simple shaders" library, which u_blitter uses.
<alyssa>
Of course ... Gallium's simple shaders are TGSI assembly.
thellstrom has quit [Quit: thellstrom]
<FLHerne>
well, that's what TTN was for originally
<alyssa>
Maybe it makes sense to translate them to NIR, move them to somewhere common so they can be used across the tree (NIR is the Mesa lingua franca), and use NTT for legacy drivers.
<FLHerne>
using the various TGSI assembly shaders in NIR-only drivers
<alyssa>
(Which might also have a maintainability benefit, seeing as the set of active Mesa devs in 2022 who are comfortable with TGSI is a small subset of those comfortable with NIR, I expect.)
<FLHerne>
it being used for Nine and things came later aaui
<alyssa>
sure
<FLHerne>
makes sense though, but are you going to reopen the "NIR assembly language" can of worms?
<alyssa>
Do we have to? nir_builder is plenty capable.
<alyssa>
It's not the prettiest thing (ah, C...)
<alyssa>
but it's probably better than mixing TGSI assembly with %s specifiers. .
<alyssa>
Now that i actually look at u_simple_shaders it looks a bit trickier to extract from Gallium than I was hoping for. Hmmph.
* alyssa
tries to understand why a blitter possibly needs transform feedback
<alyssa>
util_blitter_copy_buffer ... that's a nasty hack :|
<alyssa>
for r600 only
<alyssa>
that comes from 8ac9801669c ("r600g: accelerate buffer copying")
<alyssa>
that path is used if streamout is available but CP DMA is not
<alyssa>
which is the case for r600, r700, evergreen, and cayman on approximately drm minors 14 through 26
iive has joined #dri-devel
<alyssa>
but drm_minor is just the kernel version, right? not the kernel? CP DMA is always available on any remotely recent kernel?
<javierm>
tzimmermann: at what pointof the cycle does the drm-misc-next branch get rebased on top of v5.19-rcX ?
<tzimmermann>
javierm, we always backmerge
<tzimmermann>
do you need a patch from -rc3?
<alyssa>
mainline is at... 46, I think?
<alyssa>
Seemingly this is an optimization for old kernels for old hardware for new Mesa?
<javierm>
tzimmermann: right, I meant s/rebased/backmerge. There are some new API in regmap core that are useful to drop some workarounds in the ssd130x-spi driver
<javierm>
tzimmermann: no rush but I was curious since we are still on v5.18-rc5 as a base
<tzimmermann>
javierm, oh. ok that backmerge got lost. i'll take care of it in a bit
<alyssa>
v27 of amdgpu seems to date to 2018, i think. so actually not *that* old
<javierm>
tzimmermann: no worries, so it's usually done after -rc1 or -rc2 ?
<tzimmermann>
javierm, drm-next is at -rc2. is that sufficient?
<javierm>
tzimmermann: yes, the API changes landed in -rc1
<javierm>
tzimmermann: but more than this particular case I wanted to understand how the backmerges are done and when
<javierm>
or is more of "when needed/asked" ?
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
<mripard>
javierm: yeah, we usually do it once around -rc1, and then whenever needed or asked for
<alyssa>
Oh, ugh, but even on a current kernel, r600g older than Evergreen uses the streamout path for clear_buffer
<MrCooper>
that should work for non-atomic user space as well
<robclark>
MrCooper: I'm not sure how you'd work backwards from a LUT -> CTM.. but I think it should be possible to go the opposite direction for hw that didn't support CTM natively (AFAIU)
<MrCooper>
xf86-video-amdgpu does LUT → CTM
<robclark>
hmm, I'd have to look at how that works.. tbh I've not looked closely at color mgmt stuff.. but if it is possible, it seems like a thing drm core should do
* ccr
boogies.
<MrCooper>
robclark: yeah actually not sure it's just that, the code is hard to follow :(
<alyssa>
asahi would like LUT -> CTM in a core helper, I think
<MrCooper>
that makes at least two of you then :)
<alyssa>
MrCooper: In fairness for us it's probably not "unsupported in hw/fw" and more "I don't think macOS uses it so we won't know how to either"
<alyssa>
the CTM api is easy
<alyssa>
and yes I would like Night Light to work on my m1 :p
<robclark>
afaiu, GAMMA_LUT is a legacy feature anyways.. better for userspace to use CTM ;-)
<alyssa>
I don't fundamentally disagree
<vsyrjala>
ctm can only do linear transformations. so you can't convert lut->ctm in the general case
<vsyrjala>
is the hw that has a ctm but has no luts? how would that even work when the output pretty much always has to be non-linear?
alyssa has quit [Quit: leaving]
pixelcluster has quit [Remote host closed the connection]
<robclark>
in this case the hw has ctm but no lut.. no idea how it works but CrOS compositor uses it to implement night-light somehow
<vsyrjala>
i suppose it's happy to just scale the non-linar output a bit. but otherwise a ctm like that is pretty much useless
Duke`` has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
toolchains has joined #dri-devel
bbrezillon has joined #dri-devel
idr has joined #dri-devel
tobiasjakobi has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<danvet>
yeah lut -> ctm helper in the kernel sounds a bit too bogus
<danvet>
that's why all three parts of the pipeline are optional, because hw
<danvet>
ofc X only supports the legacy gamma, which fairly blindly maps to just one of the luts and that's it :-)
<vsyrjala>
i suppose what that ctm is actually meant for is rgb->ycbcr conversion (which is peformed on non-linear rgb values). so exposing it as the ctm prop is a bit sketchy
frieder has quit [Remote host closed the connection]
fossuer1771t has quit []
tobiasjakobi has quit []
<robclark>
ctm in the crtc is different from yuv->rgb (which is done in the planes) and applies to the result of compositing all the overlay planes
<vsyrjala>
i mean rgb->ycbcr on the output
<tzimmermann>
javierm, done
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
flto has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
<javierm>
tzimmermann: thanks!
ahajda has joined #dri-devel
MajorBiscuit has joined #dri-devel
pixelcluster has joined #dri-devel
The_Company has joined #dri-devel
frankbinns1 has joined #dri-devel
lumag__ has joined #dri-devel
ds- has joined #dri-devel
FLHerne_ has joined #dri-devel
enunes- has joined #dri-devel
karolherbst_ has joined #dri-devel
HerrSpliet has joined #dri-devel
glehmann_ has joined #dri-devel
g0b_ has joined #dri-devel
gruetze_ has joined #dri-devel
dos11 has joined #dri-devel
vup2 has joined #dri-devel
mriesch_ has joined #dri-devel
jkqxz_ has joined #dri-devel
dj-death_ has joined #dri-devel
marex_ has joined #dri-devel
dreda has joined #dri-devel
mceier_ has joined #dri-devel
dreda is now known as Guest2694
Haaninjo has quit [reticulum.oftc.net liquid.oftc.net]
heat has quit [reticulum.oftc.net liquid.oftc.net]
Company has quit [reticulum.oftc.net liquid.oftc.net]
frankbinns has quit [reticulum.oftc.net liquid.oftc.net]
lumag_ has quit [reticulum.oftc.net liquid.oftc.net]
enunes has quit [reticulum.oftc.net liquid.oftc.net]
Emantor has quit [reticulum.oftc.net liquid.oftc.net]
CME has quit [reticulum.oftc.net liquid.oftc.net]
jernej has quit [reticulum.oftc.net liquid.oftc.net]
bbrezillon has quit [reticulum.oftc.net liquid.oftc.net]
iive has quit [reticulum.oftc.net liquid.oftc.net]
ds- is now known as ds`
FLHerne_ is now known as FLHerne
Thymo has joined #dri-devel
sravn has joined #dri-devel
glehmann_ has quit []
glehmann has joined #dri-devel
Prf_Jakob has joined #dri-devel
vsyrjala has joined #dri-devel
javierm has joined #dri-devel
Adrinael has joined #dri-devel
angerctl has joined #dri-devel
mntmn has joined #dri-devel
kgz has joined #dri-devel
iive has joined #dri-devel
i-garrison has joined #dri-devel
bbrezillon has joined #dri-devel
iokill has joined #dri-devel
jadahl has joined #dri-devel
Haaninjo has joined #dri-devel
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
tzimmermann has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
mceier_ has quit []
heat has joined #dri-devel
Lynne has joined #dri-devel
CME has joined #dri-devel
Emantor has joined #dri-devel
yoslin has joined #dri-devel
Arsen has joined #dri-devel
bnieuwenhuizen has joined #dri-devel
glennk has joined #dri-devel
reactormonk[m] has joined #dri-devel
sigmaris has joined #dri-devel
undvasistas[m] has joined #dri-devel
tomba has joined #dri-devel
naheemsays[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
go4godvin has joined #dri-devel
pushqrdx[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
Anson[m] has joined #dri-devel
onox[m] has joined #dri-devel
yshui` has joined #dri-devel
bylaws has joined #dri-devel
Vin[m] has joined #dri-devel
danylo has joined #dri-devel
shadeslayer has joined #dri-devel
Newbyte has joined #dri-devel
chivay has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
jernej has joined #dri-devel
mceier has joined #dri-devel
karolherbst_ is now known as karolherbst
karolherbst has quit []
karolherbst has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
gruetze_ is now known as gruetzkopf
YuGiOhJCJ has joined #dri-devel
linkmauve has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
lumag_ has joined #dri-devel
lumag__ has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
remind me why we have all of align, ALIGN, and ALIGN_POT, and they're all identical?
pixelcluster has quit [Quit: Konversation terminated!]
<alyssa>
and ALIGN_NPOT and autil_align_pot
<airlied>
because you haven't removed them yet :-)
<airlied>
I thought there we some differences
<airlied>
esp around npot ones being a lot more efficient if you know it's a power of two
<alyssa>
airlied: align, ALIGN, and ALIGN_POT are all identical afaict
<alyssa>
ALIGN_NPOT and util_align_npot are defined differently but are either equivalent or one is wrong ;-)
<airlied>
alyssa: should probably burn ALIGN and ALIGN_POT down at least
<alyssa>
airlied: part of the problem are that some are in u_math and some in u_macros
<alyssa>
and I don't want to play the #include game ...
<airlied>
well ALIGN vs align should be simplest
<airlied>
would be perfect for cocinelle
<alyssa>
70 files use ALIGN_POT, delight
<alyssa>
airlied: i just used sed :-p
<airlied>
no sideswipe damage?
<alyssa>
sideswipe?
<airlied>
like other ALIGN's gtting replaced
<airlied>
wasn't sure how subtle sed was here
<alyssa>
diff looks ok
<airlied>
launch it into sun^WCI
<ccr>
"it compiles, thus it works"
<alyssa>
../src/compiler/nir_types.cpp:791:35: error: ‘align’ cannot be used as a function
<alyssa>
oh ffs
<alyssa>
scoping heck
<alyssa>
so far so good though
<alyssa>
src/freedreno/vulkan/tu_tracepoints.c:883:5: error: initializer element is not constant
<alyssa>
aaaaand that's a tough one. do I really want to debug autogenerated code from someone else's driver
<alyssa>
macro vs function ..
<alyssa>
More to the point, the ALIGN_POT macro is generic over 32-bit and 64-bit
<alyssa>
align/align64 are not
<alyssa>
so there's not a straightforward substitution ..
* alyssa
tags out
pcercuei has quit [Quit: dodo]
* jenatali
mumbles something about C++ templates and constexpr that could do this without macros