<kisak>
airlied: Dare I ask how painful it was? Is it more Creature from the Black Lagoon or Frankenstein?
<airlied>
kisak: initially I expected to be really horrible, but it's ended up frankensteining the llvmpipe compute shaders and the draw pipelines together and it mostly seemed to work
KunalAgarwal[m][m] has joined #dri-devel
daniliberman[m] has joined #dri-devel
devarsht[m] has joined #dri-devel
bmodem has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Company has quit [Quit: Leaving]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
nehsou^ has joined #dri-devel
dcz_ has joined #dri-devel
vyivel_ has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
vyivel_ is now known as vyivel
aravind has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
kugel has quit [Read error: No route to host]
kugel has joined #dri-devel
oneforall2 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
fab has joined #dri-devel
mvlad has joined #dri-devel
Zopolis4 has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
f11f12 has joined #dri-devel
lemonzest has joined #dri-devel
junaid has joined #dri-devel
thellstrom has joined #dri-devel
junaid has quit [Remote host closed the connection]
ngcortes_ has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
sima has joined #dri-devel
mdroper has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
columbarius has joined #dri-devel
smiles_1111 has quit [Remote host closed the connection]
co1umbarius has quit [Ping timeout: 480 seconds]
smiles_1111 has joined #dri-devel
frieder has joined #dri-devel
bmodem1 has joined #dri-devel
bgs has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<pq>
airlied, will you be coming back to the new KMS color pipeline UAPI discussion? It seems to have died off. Were you convinced in the end at all?
<airlied>
pq: I was waiting until I'd see everyone chime in :-), I'm still on a fence, but probably going to have to let people create a noose for themselves
<airlied>
if sima is okay with the direction I'll trust it'll all work out :-)
<pq>
alright
<pq>
airlied, I'm not sure if your intention was to explicitly enable proprietary drivers and algorithms, or the opposite, with your question about nvidia.
<airlied>
the problem isn't what I explicity want to enable, it's what happens when their solution to enabling them is to replace a bunch of distro libraries
<airlied>
we've been through this pain before with libGL and libgbm etc
<pq>
if you are suree it will happen, I guess it means a loader with the userspace lib - if that ever gains widespread use in compositors.
<airlied>
yes and the creating a loader starts leading down to creating conformance tests etc
<pq>
sure
tursulin has joined #dri-devel
<sima>
pq, yeah I got really badly sidelined with typing up the uapi header + docs last week
<sima>
but also, I think it's largely orthogonal and not consequential for the actual color pipeline uapi semantics
<airlied>
like we can probably ignore it in the short-term, but I'd like to make sure people aren't forgetting the pain of userspace vendoring
<airlied>
like it's probably not egl streams painful, unless nvidia decide to expose a completely different uapi from their color library
<sima>
airlied, for what you brought up, I'm not sure there's really a good solution, I think best we can is be keenly aware of the tradeoff we're picking
<pq>
and that's probably not where anyone would be starting. The KMS UAPI starts with fairly generic elements that will get directly used compositors, and whether a userspace library actually emerges remains to be seen. So proprietary vendors may not even have a place to hook into / replace, unless someone is serious about driving a userspace lib with the essential aim of enabling proprietary algorithms.
<airlied>
sima: put the perscriptive api in the kernel "fixes it" :-)
<sima>
yeah
<airlied>
pq: that's worse thoguh
<airlied>
I don't want compositors directly using the kms uapi in case hardware changes direction
pcercuei has joined #dri-devel
<sima>
pq, was anyone from asahi involved too? apparently they have a maxxed out prescriptive api due to half the macos driver running in the fw ...
<airlied>
then the kernel has to fake up some generic elements to keep things going on newer hw
<airlied>
yeah we also have to deal with mappings to the nvidia/asahi fw apis which might be a nightmare
<airlied>
or we end up having per-driver uapi for those, which is also a nightmare
<airlied>
if we can define a minimal viable set of hardware that will always be there, then maybe compositors using it is okay
<pq>
sima, are you sure you have prescriptive vs. descriptive the right way around? I have no idea of any asahi stuff.
<airlied>
but if we start having non-niche compositors with baked in pipeline knowledge it'll be horrible
<airlied>
like I don't really care what gamescope does, but mutter/kwin/weston shouldn't get stuck in corners needing rewrites on new hardware
<pq>
My opinion is that if the KMS color operations are not mathematically defined and explicit, then "my" compositors won't be using them.
<pq>
I'm not sure what kind of "pipeline knowledge" you are imagining.
djbw has quit [Read error: Connection reset by peer]
<sima>
pq, maybe not, it's early and coffee not yet working :-)
<airlied>
pq: like the existance of certain LUTs with certain abilities
<airlied>
then a new hw design removes those in favour of something completely different
<sima>
pq, yup I got the wrong, I meant asahi seems very descriptive
<airlied>
and now the compositor can't do a bunch of things on that hardware
<sima>
yeah that's the awkward part of a prescriptive uapi
<sima>
like if a new gpu would suddenly break gl1 or so
<sima>
and gears stops working :-)
<airlied>
but at least there we fix one driver in userspace, not 500 GL1 apps
<pq>
airlied, well, I can't talk for anyone else, but Weston will always be doing an optimization to map its internal pipeline to KMS, and sometimes it works and sometimes it won't. There will be no assumptions, just a mapping algorithm attempting its best.
<airlied>
my worry is compositor proliferation is going to cause all sorts of I plugged in new hardware and now my desktop looks like 8-bit solaris firefox
<airlied>
or my laptop now consumes all the Ws
<sima>
airlied, I guess the fallback should always be gl, ie. crappy battery times but otherwise looking good?
<airlied>
yea I guess it will have to be that, and then we have to rewrite all the compositors
<pq>
why is plugging in new hardware suddenly a kernel-regression-severity problem?
<pq>
yes, shader fallbacks are the answer when KMS does not fit
lynxeye has joined #dri-devel
<airlied>
pq: distros like to provide a uniform set of features across vendors as possible
<airlied>
it's called an abstraction layer for a reason
<airlied>
if I have to update all the compositors in my distros every 6 months to keep up with new hardware, that's going to be a substantial increase in testing costs
<sima>
pq, it's not a kernel regression issue of "stop the press, need a fix asap"
<sima>
but a "users are going to be disappointed and that's not very good" issue
<pq>
airlied, but the only difference with plugging in new hardware is that battery drains faster - not that image becomes crappy.
<airlied>
pq: we do care about batteries on laptops though
<sima>
my take is that if we really can't do better then oh well, but we should at least be clear on this
<pq>
sure, but it's like asking for all the goodies without requiring any work - impossible.
<sima>
and we might inflict retrofitting a descriptive retrofit underneath a common prescriptive uapi for more compat
<airlied>
pq: hence why I asked if you put it all in the kernel
<airlied>
so we don't have to keep every compsitor up to date for every hw release
<pq>
you want to generate shader sources in kernel?
<airlied>
if we had one userspace library hiding it all, that would also be preferrable
<airlied>
but getting userspace devs to agree on that would probably be difficult
<pq>
very
<sima>
pq, essentially if you go with pure prescriptive then kms is no longer the abstraction layer
<airlied>
pq: at this stage it's probably saner to add spirv generators to the kernel than update numerous compositors on each new hw release :-P
<sima>
ebpf
* sima
had to, resistance was futile
<pq>
sima, it still is an abstraction layer, just not as high-level, but also not down to hardware-level.
<pq>
airlied, my compositor has no vulkan
<sima>
pq, I guess it'd be like vk, but with zero required features
<airlied>
spirv would just be the transport language :-)
<sima>
everybody gets a compiler!
<airlied>
or we return an ebpf program :-P
<pq>
airlied, ok, then what about the policy question?
<airlied>
but yeah it's going to be a horrible mess, please make a userspace library at least, or attempt to
<sima>
I mean the trouble with that is if your fallback isn't full gl/vk but just a fancy 2d blend engine
<sima>
you're still screwed
rasterman has joined #dri-devel
<pq>
airlied, who do you put the policy into userspace if the kernel UAPI is descriptive?
<pq>
*how
<sima>
I think that was prescriptive uapi + mandated userspace lib that provides some descriptive uapi
<airlied>
I think that's the closest we'll get to sanity
<sima>
we could ship them in the kernel even, perf does that too iirc
<pq>
sima, that's the different design.
<sima>
not that kernel build system is great
<airlied>
I think starting with compositors all going on their own is going to end badly
<airlied>
pq: not sure where you'd policy, ebpf? :-)
<sima>
pq, mandated as in lowest common denominator fallback, compositors could still do their own thing that integrates better
* airlied
has to dinner
<pq>
it really makes no difference if the policy is in a userspace lib maintained in the kernel tree, it's still in the kernel
<pq>
if userspace is not allowed to bypass that lib
<sima>
well it makes a technical difference of what the kernel does
<sima>
the spirv generator would then at least run without kernel privs
<pq>
that technical difference is irrelevant, userspace i.e. compositors are no longer in control of the policy.
<sima>
pq, see my clarification, I don't mean mandated as "the only uapi"
<sima>
but as in "we'll patch this to offer a lowest common denominator thing as fallback"
<sima>
so more a mandate for people who add new gpu generations to their driver, when the color pipeline changes completely
<sima>
kinda like mesa3d is the mandated 3d library
<sima>
you can still do whatever you want, and plenty vendors do
<pq>
but mesa3d does not decide what or how stuff gets shaded, the apps still define that policy.
<pq>
but if you have a descriptive API, then the policy is necessarily behind that API
<sima>
there's a lot of fast&loose in the spec especially around texture sampling
<sima>
or at least historically there was
swalker_ has joined #dri-devel
<pq>
sure, little details - but here we're talking about major details
<pq>
obviously visible details
<sima>
but yeah if there's just no reasonable descriptive api for this then trying to have it in userspace as a fallback is also not going to work
swalker_ is now known as Guest431
<sima>
but given that every other os does have some descriptive api somewhere for this I'm not sure that's a solid claim
<pq>
well, a descriptive API that everyone agrees to might emerge in a decade I guess, assuming that hardware and color research do not advance much.
<pq>
a decade if active in-production use, I mean
<sima>
yeah if that's the consensus across all stakeholders
<sima>
then I think we just have to bite the cost of the prescriptive approach
swalker__ has joined #dri-devel
<sima>
i.e. document it clearly that this is what we're doing and why, get a pile of acks as sign-off, ship it
<sima>
stock up on good beverages too :-)
<jadahl>
si
<jadahl>
sima: there were discussions on mastond
<pq>
Wayland will be a descriptive API. Are you comparing other OSs on equal terms? Apps will be using Wayland, not KMS.
<jadahl>
on about asahi + kms color pipelines
<jadahl>
apparently apple hardware is very much implemented to match the apple compositor, with fixed color spaces/formats/... in various steps
<sima>
pq, afaik the driver interface is generally descriptive too
<sima>
not just the app/compositor interface
<sima>
jadahl, yeah that one might be big time lolz :-/
<jadahl>
not super different from what it seems nvidia hw does
<pq>
sima, are "KMS" and GPU stuff split into separate APIs, or are both collected behind the same API?
<pq>
as in, does Windows compositor have the policy, or does the driver have it?
<pq>
The crucial point for fallbacks when KMS does not work is that the policy is in a single place. Windows could as well put the policy in the gfx drivers, but for Linux I'd like to allow alternatives that are not tied to your hardware driver.
<pq>
jadahl, no, it does sound super different from what you said.
Guest431 has quit [Ping timeout: 480 seconds]
<pq>
jadahl, unless the policy behind that firmware API is strictly fixed-function?
<sima>
pq, I think the driver has it, to make it all work
<jadahl>
pq: wasn't the nvidi ahardware designed to do blending in (put long acronym here)?
<sima>
kinda like hwc2 in android
<pq>
but if macOS changes its policies, wouldn't the firmware behavior change without warning too?
<sima>
driver gets the surface stack, makes it into something the gpu+display can consume and shows it on the display
<sima>
which is a pretty fundamental break of how kms works
<pq>
jadahl, I haven't heard anything like that.
<jannau>
apple's firmware API has at least pixel format, color space and eotf per plane (with some weird limitations)
<pq>
sima, right. And our hwc2 is a Wayland compositor, many of them.
<sima>
pq, you specify the exact fw you get in your boot entry, kinda like loading a specific fw version in linux instead of just any
<jannau>
the whole pipeline has at least a gamma LUT (exposed by macOS) and a CTM (which appears to have some weirdness) too
<pq>
since there is no "The Linux OS", there are multiple distributions which even allow multiple choices
<sima>
pq, yeah so I guess just document all these constraint in the uapi doc as the reason for why we have this is probably best
<sima>
constraints/tradeoffs
<jadahl>
pq: I think nvidia has fixed function blocks that do things like converting LMS to ICtCp
<jannau>
I believe it has degamma LUT too but afaik not exposed by macOS
<pq>
jadahl, sure, but that's ok, and nothing to do with blending.
<jadahl>
pq: sorry, shouldn't have assumed it was blending, I meant that it isn't exposing arbitrary math ops, but rather specific transformations, which seems similar to what apple hw does
<jannau>
I haven't yet looked at what macOS does for HDR but it looks like the firmware handles that based on described input and selected output color format
<pq>
jadahl, from the hackfest, I understood that the NVIDIA blocks can be described with mathematics and they are deterministic. Apple fw API I don't know if it can be described like that, or is it non-deterministic.
<jannau>
the firmware presents a long list of detailed possible output color formats
<jannau>
I don't think marcan has looked into HDR in detail either
<pq>
even if Apple fw API is purely descriptive, then if a set of input parameters always leads to the same mathematical processing, it could theoretically be exposed as a prescriptive API, but it's going to be very fixed-function.
jdavies has joined #dri-devel
jdavies is now known as Guest434
<pq>
which means special snowflake KMS elements - however, the intel/nvidia/amd KMS drivers could likely expose the same elements as an alternative pipeline.
<jadahl>
pq: maybe it has clear mathematics, but it adds restrictions
MajorBiscuit has joined #dri-devel
<pq>
all elements always have restrictions
<jadahl>
sure, but a set of luts and matrixes is a different story from "this can do LMS->ICtCp"
<pq>
yes
<jannau>
regarding the firmware interface: we will only support selected firmware versions (based on the macOS version they ship with). other versions will simply not work since the interface is not stable
<pq>
jannau, sounds fine - just add the color operations as another thing to keep matching the KMS UAPI you expose.
<jannau>
so if Apple changes how the color pipeline works we can in principle change annotations of the color operations, they main issue is probably if we are able to detect changes
<pq>
so it kind of sounds like asahi should be the first one to design new KMS colorop elements, because they have the most special-cased ones.
<pq>
However, since you say the output description affects the operation, and the output cannot be described per plane (can it?), then that looks like the big problem.
<pq>
is there a split between before-blending and after-blending color management?
Zopolis4 has quit [Quit: Connection closed for inactivity]
Guest434 has quit [Ping timeout: 480 seconds]
<pq>
or do you just describe output per CRTC, input per plane, and then magic happens in between to come up with a single image from multiple planes?
<jannau>
timing and work load wise it's probably a bad idea to have to wait for asahi
<pq>
jannau, well, if DRM maintainers say that any UAPI design must also fit asahi...
<pq>
and even without needing any changes in userspace
<pq>
I mean in compositors
<pq>
then we really need to start from the most special, most restricted, hardware/firmware there is that we need to support
<jannau>
I've seen no explicit color management on a per plane basis except the colorspace and eotf description but I haven't looked at HDR yet
<pq>
jannau, those parameters are exactly what we're talking about.
<pq>
they are the descriptive API
<pq>
you set a color space and eotf per plane, and then trust that something chooses a good color conversion (policy) to go from that to what you want out
<pq>
what we need is a prescriptive API: with these parameters values, the mathematical operation is that.
angerctl has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
<pq>
deja vu EGL Streams...
<javierm>
I don't see that difficult on getting devs to agree on using a single library to hide all the details and provide a more abstract interface
<javierm>
libinput and libcamera are too good examples
<javierm>
*two
Namarrgon has quit [Ping timeout: 480 seconds]
<jannau>
I would expect that blending respects the per plane description, blends into a internal format and does further conversion for the output format (if necessary)
MajorBiscuit has joined #dri-devel
<pq>
jannau, the problem is that the KMS color pipeline is (so far thought to be) strictly split between before-blending and after-blending color operations which can be defined independently. That creates the question: in which color space and encoding does apple fw blend in? Because that will necessarily need to be defined in the UAPI.
<jannau>
one potential problem is that changing the output color format could require a modeset
<pq>
other drivers already require that sometimes if not always
<jannau>
pq: I don't know what format the hw uses for blending internally
<pq>
yes, which is a problem - but it doesn't need to be known for real, we "just" need a mathematical model that matches the results.
<pq>
but in the end, it's another policy decision robbed from compositors
<pq>
it's a really difficult impedance mismatch - more like a whole different design paradigm, which is why I'm really scared of the demands to make that apple fw be on equal footing with "real" FOSS drivers.
<pq>
I'm not sure if Weston would ever be able to make use of the apple fw API really, the design fundamentals are so different.
<pq>
emersion, are reading all this today? ^
<pq>
*are you
<pq>
javierm, I've mentioned libcamera to people, but I don't really know about it, and no-one else seems interested to look at its design...
<pq>
I guess the closest equivalent in libinput are the pointer acceleration curves, and I think it just recently grew a presciptive API for it (let compositors define an arbitrary LUT curve).
<pq>
AFAIU, originally libinput intended to have just whatever that works for everyone, then it needed more and more choices, and now it has a fully prescriptive option, so I would claim that it failed in having a descriptive API.
<javierm>
pq: I can't say that understand that much about color management but I see the parallel with what libcamera tries to achieve
<pq>
javierm, I imagine libcamera would be excellent inspiration indeed.
_jannau_ has joined #dri-devel
<javierm>
basically in modern systems you don't just have a USB Video Class camera but video pipelines consisting of dumb camera sensors + ISP + other IP blocks for video scaling, format conversion, etc
<javierm>
and the kernel exposes a graph with all these IP blocks (called Media Entities) and user-space need to setup a pipeline
<javierm>
this means that you can't have a generic user-space and need platform specific logic to set these media pipelines
<pq>
Color management has color gamut and tone mapping operations, that are totally subjective and there are multiple conflicting goals that one could have with them, which means there cannot be a single algorithm to fit all.
cmichael has joined #dri-devel
<javierm>
so what libcamera does is to provide an abstract camera API for user-space to use and the pipeline configuration is done by the library, that contains platform specific logic for that (called pipeline handlers)
<pq>
more over, those algorithms are still actively researched, too, with an unlimited complexity range
<javierm>
pq: yeah, that's another thing that libcamera does. Because besides configuring the pipeline, the camera sensors are dumb and you need post-processing of the frames using 3A algorithms
<javierm>
3A = autoexposure, auto balance and autofocus
<pq>
javierm, yes, that sounds like a very good fit here too. The public library API might have different design principles, maybe.
<javierm>
so libcamera allows to plug these algorithms too
<javierm>
pq: I guess it boils down to attempt to describe this in a generic way using KMS properties and have as a goal to have generic user-space or make the KMS API more low level and have a library on top
<pq>
javierm, what's the kernel UAPI like? Is it full of hardware specifics or does it pretend to abstract something?
<pq>
javierm, and why is libcamera not completely in the kernel side of UAPI? - airlied and sima asking ;-)
<sima>
pq, needs more pinchartl but I think 2 weeks of vacation
<sima>
afaik the kernel api is still a bit up in the air, and rn just reusing some v4l drivers until the userspace lib interface is clearer
<javierm>
sima: no, the kernel API is very old actually but is just that every product had platform specific code and there wasn't a generic library for it
<pq>
emersion, hwentlan_, jadahl, are you getting all this? ^
<sima>
but there's been all kinds of proposal floating around from further extending mediactl to new subsystem to somehow bashing this into drm
<javierm>
AFAIK it was even used in the Nokia N phones like a decade ago
<sima>
javierm, afaik there's not a lot of actual recent products fully using mediactl api
<sima>
but I'm also rather far away from all that discussion
<javierm>
sima: wasn't used in Chromebooks for example?
<javierm>
but yeah, we need pinchartl to make sure that I'm not saying anything silly here :)
<sima>
cros team is working on a new kamera api
<sima>
kcam or something, there was an lpc talk
<sima>
android afaik is just yolo vendor stuff behind the android interfaces in userspace
<sima>
I've also heard a few of the details on the intel side with the ipu6 driver
<pq>
javierm, is that one get-info ioctl all what's common there?
<sima>
the one for dell where it's just a driver in userspace really and very blobby
<sima>
javierm, I also thought there's a bunch of important things missing like sync_file support or atomic commit
<javierm>
sima: yeah, for x86 is complicated because the ACPI tables shipped are mostly for Windows and so not compatible with the IPU driver
<javierm>
sima: I believe only the Chromebooks ship a DSDT table that are compatible and describe the media graph using a _DSD extension
<sima>
oh I didn't even know about any acpi issues
<javierm>
sima: yeah, that's why you couldn't have cameras working on the Window Surface tablets
<javierm>
but that's a different conversation than libcamera :)
<pq>
javierm, that sounds like what would be the best in the long run, but also that design would have practically zero element abstraction at KMS UAPI.
<pq>
as in what an element does and how it's confisugre
<pq>
*configured
<sima>
pq, yup, for that design the prescriptive api is probably the right one
<sima>
or at least a good stepping stone
<javierm>
pq: yup, that's why I said that the trade off is basically an abstraction in KMS vs not hiding the color pipelines and have platform specific user-space
<pq>
sima, the kernel UAPI would not even be prescriptive or descriptive, it would be fully hardware and driver specific.
<javierm>
which I believe is the descriptive vs prescriptive discussion ?
<pq>
not really
<sima>
pq, I'm not sure we'll get there right away, but yeah that would be possible
<sima>
entirely hw specific api is a bit a too big step from where kms is currently
<sima>
unless you want a multi-year experimental phase to figure out the lib api, before anything lands
<javierm>
sima: yeah, it is diverging a lot from the existing KMS design that attempts to provide a more abstract interface to user-space
<javierm>
but I can't fail to see the similarities between what you are trying to achieve for color pipelines and what the media folks solved with the media controller API
Company has joined #dri-devel
<pq>
sima, that multi-year effort is exactly what I've been saying would need to happen if we did what airlied and you asked first.
<pq>
Isn't the proposed prescriptive KMS color UAPI design a natural step in a path to establish a single common userspace library, after which the UAPI can fall into total hardware-specificness naturally over time, making less and less userspace bypass the library?
<pq>
That won't happen if you demand the UAPI to maintain its abstraction. It must be allowed to fall into total hardware-specificness, or there won't be an incentive to have that single library.
<sima>
pq, yeah I think that's probably the right pragmatic tradeoff
<sima>
so for me as long as everyone's on board with the direction, we're good
<pq>
I might even say that the existing KMS UAPI for planes, CRTCs and connectors is a little too easy to use and abstracted for everyone to start caring seriously about libliftoff.
<sima>
we're _really_ good in drm at keeping somewhat regretful uapi alive for a long time :-)
<javierm>
pq: indeed. I agree with you that's either an abstract KMS API or a low-level hardware API + library to abstract those details away
<HdkR>
The AGP API is gonna live forever
<sima>
so I'm not super worried about all the concerns, as long as we don't ignore them and don't try to get to something better longer-term
<sima>
and some pragmatic stepping stones meanwhile are needed to get this off
<sima>
and the proposed prescript color pipeline looks like a good one
<emersion>
pq: I'm on leave atm
<sima>
HdkR, why did you just drop that reminder :-P
<javierm>
sima, pq: all I'm trying to say is that before commiting to an API to talk with pinchartl, because IIRC the media folks attempt to abstract the pipelines in the kernel using the v4l2 API and that failed
<HdkR>
sima: Need to take the good with the ugly :P
<pq>
emersion, enjoy, but please bookmark today's chat to revisit when you're back. :-)
<emersion>
will try to remember
<javierm>
sima, pq: and at the end decided that the only way to implement it properly was to expose the whole media graph using a different API and let user-space to setup the entities and connections
<sima>
HdkR, it should just be an iommufd but alas 20 years too late for that
<HdkR>
Indeed
<pq>
javierm, good points, thanks!
<sima>
pq, I do think that we might end up in a future where the prescriptive pipeline is fairly limited for just backwards compat and the real interface is a per-crtc blob a la ADF (android display framework)
<sima>
but that really then means the libkmscolor is fully established and everyone is ok with using that
<sima>
and that's a very long road to get there I think
<pq>
yup
<sima>
plus display color pipelines might be limited enough that we never need to get there
<sima>
unlike cameras, where the post-processing and life-capture controls really are innovating a _lot_
<sima>
because it's such a competitive advantage in the mobile space to have slightly better camera
<pq>
well, gamut and tone mapping operators are innovating a lot too
<pq>
SBTM signalling is coming, which means "do it all yourself in the source"
<sima>
yeah it's definitely not settled, but with cameras not even the physical approach to autofocus is settled
<sima>
so you have widely different hw inputs with widely different algorithms even before you get into anything specific
<sima>
sbtm?
<pq>
Source Based Tone Mapping
<sima>
ah so sink goes completely dumb for hdr, like with old panels where real color correction was all done in the source too?
<pq>
instead of sending BT.2020/PQ or HLG to a sink, you send sink-specific native data
<sima>
yeah that's going to be fun
<pq>
yes
<pq>
well, it will make my work *easier* when there is no need to guess what a monitor may or may not do
<pq>
and it also required hw vendors to correctly describe their monitor behavior, which means a "copy&paste EDID" no longer flies
<pq>
but it also means there will be more demand from display controller color pipelines, because taking the hit of a shader pass might be upsetting to gamer performance
<sima>
well on mobile you often flat out don't have the memory bw for a full post-process step
<pq>
right
<sima>
but yeah this sounds like pain until both sink and source support is widely adoopted
<pq>
and you don't have the circuitry of an external monitor either, I presume
<sima>
like the first few sinks/source drivers will just screw this up
<sima>
like with adaptive sync, and you'll need to buy the right combo
<sima>
I guess self-refresh panels should have enough circuitry to not make the sink-side mapping too costly
<sima>
but it's still duplicated silicon for no gain
<sima>
ok gtg, ttyl
xxmitsu has joined #dri-devel
jkrzyszt has joined #dri-devel
<kbingham>
Hola! I got pinged to look at the backlog here relating to libcamera ... I saw a few questions / topics above I could answer/comment on ... But I think the conversation is over. I'll add them here in case it helps clarify anything but I'm always around to talk about libcamera too, (or we're over in #libcamera too)
heat has joined #dri-devel
<kbingham>
> the problem is that the KMS color pipeline is (so far thought to be)
<kbingham>
libcamera also has to deal with colorspace issues and configuration too all the way through the pipeline. We are trying to take a lot of care to ensure we can expose CCM's from the hardware, but also ensure we can track how the colorspace is conveyed from the hardware and through all the transforms it can have through the pipeline. Generally colors are always hard ;-)
<kbingham>
> <pq> javierm, and why is libcamera not completely in the kernel side of UAPI? - airlied and sima asking ;-)
<kbingham>
libcamera handles the userspace side and doesn't fit in kernel space. In particular there are lots of parts that need algorithms to run that are not suited to kernel side, and then management of sending buffers from one device to another. That all needs to be configurable as well.
<kbingham>
> <sima> javierm, afaik there's not a lot of actual recent products fully using mediactl api
<kbingham>
<kbingham>
There's quite a few from my perspective ... I guess it depends on what you use.
<kbingham>
<kbingham>
> <sima> cros team is working on a new kamera api
<kbingham>
Cros team are working on a new api called kcam ... it has not been well received.
<kbingham>
Khronos are also working on a new Kamaros API. We're working with them and we would expect the linux implementation of that to be ... (I'm sure you can guess) ... libcamera.
<kbingham>
> Intel IPU6 ..
<kbingham>
<kbingham>
Yes, work in progress.. There are some key technical challenges there. (Well maybe they're political challenges as if Intel were happy to open things up the technical difficulties would go away :D)
<kbingham>
> <sima> unless you want a multi-year experimental phase to figure out the lib api, before anything lands
<kbingham>
libcamera is about 5 years into this ... Second best time to start is now ? ;-)
<kbingham>
<end of me commenting on backlog>
elongbug has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
<pq>
kbingham, thanks!
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<sima>
kbingham, thx
vliaskov has joined #dri-devel
MajorBiscuit has joined #dri-devel
jaganteki has joined #dri-devel
<pendingchaos>
is there any reason why NIR doesn't allow vec6/7 and vec9-15?
<pendingchaos>
I expect it would be simpler to support every size below 17
thellstrom has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
swalker__ has quit [Remote host closed the connection]
Zopolis4 has joined #dri-devel
angerctl has joined #dri-devel
sgruszka has joined #dri-devel
<jenatali>
pendingchaos: Is there a reason to do so? There's some alu opcodes that need to be replicated by vector size and it'd be a lot of bloat
<pendingchaos>
all of the alu opcodes are or can be generated, so it would just be some switch cases like nir_fdot() helper (and that can be fixed by generating count->op helpers for reduction opcodes)
<pendingchaos>
it would also make the rules for valid vector sizes simpler (<=16 instead of the weird <=5 || ==8 || ==16 thing)
jaganteki has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<karolherbst>
with stuff like that I always feel like there is no actual reason to do it besides "I want a vec src"
camus has quit [Ping timeout: 480 seconds]
<karolherbst>
if the harware requires a vec6 src, sure, but I highly doubt that
<karolherbst>
and we kinda should stop adding arbitrary vec sizes
<alyssa>
08:01 < pq> airlied, but the only difference with plugging in new hardware is that battery drains faster - not that image becomes crappy.
<karolherbst>
I could argue the same for nvidia, but we have two vec4 sources, thats' it
<alyssa>
counterpoint, Night Light in both KDE and GNOME is KMS only and just refuses to work if the display controller doesn't support, neither implements the gl fallback
<karolherbst>
sure, we could _push_ those tex arg inside a vec6 for certain tex operations, but.... why
<alyssa>
so IDK if compositors will bother with gl fallbacks if It Works On My Machine
<alyssa>
08:05 < sima> I mean the trouble with that is if your fallback isn't full gl/vk but just a fancy 2d blend engine
<alyssa>
wasn't this the libliftoff promise?
<pq>
alyssa, that's a compositor's design choice. You can totally implement night light without KMS too. Well, any desktop compositor must.
<sima>
alyssa, yeah this was in reply to airlied's suggestion that the kernel return a spirv shader that implements what the hw does
<pendingchaos>
the hardware does use a vec6 src, it puts all texture sources into a single vector
<pendingchaos>
3 components for cube/2darray coordinates; then offset, bias and compare
<pendingchaos>
this is somewhat extreme edge case, so maybe we could just round the NIR vec to vec8, but why not add more vec sizes if we aren't increasing the max?
<alyssa>
pq: CAN, yes. But if the two big desktop compositors don't.. well..
<pq>
alyssa, fallbacks are already implemented for KMS overlay and cursor planes, too. No desktop compositor assumes they always work for everything they throw at it, so they already have a GPU or software renderer to do the same job.
<alyssa>
I just don't have a lot of faith in mutter implementing standards at this point.
<pq>
alyssa, file bugs to them.
<pq>
ok
<alyssa>
gfxstrand: clearly we need oyu
<alyssa>
you
<alyssa>
to bring back my Faith
<alyssa>
:p
<MrCooper>
alyssa: Night Light is a compositor internal feature, what does it have to do with any standards?
* alyssa
is just grumpy and will show herself out
alyssa has left #dri-devel [#dri-devel]
<karolherbst>
pendingchaos: nir_serialize does some werid magic on the vec size for now and it's kinda packed, but yeah, could be changed
<pendingchaos>
nir_serialize should already work for all values below 256
<pendingchaos>
below 2**32 if you change some local variables from uint8_t to uint32_t
<jenatali>
IIRC MSVC actually has an additional warning here compared to clang/gcc
mbrost__ has quit [Ping timeout: 480 seconds]
<jenatali>
But no __typeof__
phreer has left #dri-devel [#dri-devel]
MajorBiscuit has quit [Ping timeout: 480 seconds]
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
kxkamil has quit []
kxkamil has joined #dri-devel
Leopold_ has joined #dri-devel
fab has quit [Quit: fab]
<karolherbst>
robmur01: uhh.. why ....
<karolherbst>
this is so stupid...
<robmur01>
because narrowing of unsigned types is well-defined, unfortunately :)
<pepp>
is it expected that vk_common_ResetCommandBuffer doesn't check if the command buffer state is "pending"? The doc says "commandBuffer must not be in the pending state"
<zmike>
could be an oversight
kzd has joined #dri-devel
<pendingchaos>
I don't think vulkan drivers are expected to do these kinds of checks
<HdkR>
That's what the validation layers are for
<pepp>
oh ok
<zmike>
there's a lot of validation in common code though
alyssa has left #dri-devel [#dri-devel]
bmodem1 has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
djbw has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
MrCooper has joined #dri-devel
lemonzest has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
<Company>
my app = GTK, I've been hacking on the Vulkan renderer there
jfalempe has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
<zehortigoza>
Company: huum! this could be several things... it vkcube works fine on X in my Tigerlake. will give a try later with Wayland. file a bug so we can better track this.
<Company>
yeah, XWayland works fine - both with my GTK and with vkcube
mbrost_ has quit [Ping timeout: 480 seconds]
ADS_Sr has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
jaganteki has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
guru_ has quit []
oneforall2 has joined #dri-devel
psykose has joined #dri-devel
jfalempe has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
mvlad has quit [Remote host closed the connection]
agd5f has quit [Read error: No route to host]
alyssa has left #dri-devel [#dri-devel]
agd5f has joined #dri-devel
jfalempe_ has joined #dri-devel
jfalempe has quit [Read error: No route to host]
Haaninjo has quit [Quit: Ex-Chat]
djbw has quit [Read error: Connection reset by peer]
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
jfalempe_ has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
gouchi has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
I may regret asking, but why does llvmpipe call nir_convert_from_ssa?
<alyssa>
I mean, LLVM itself is SSA so why not just translate phis?
<alyssa>
airlied: ^^
<DavidHeidelberg[m]>
does this spam-storm happen time to time: ERROR - dEQP error: MESA: warning: vk_log*() called with client-invisible object 0x55c31bd83d60 of type VK_OBJECT_TYPE_DEVICE? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/41927818
<alyssa>
DavidHeidelberg[m]: there's an MR to fix that
<Kayden>
aren't variables limited to 4GB typically?
<Kayden>
only case I can think of where that would be needed is the last unsized array in an SSBO or something, but even then I'm not sure
bgs has quit [Remote host closed the connection]
elongbug has quit [Read error: Connection reset by peer]
<alyssa>
airlied: Well, I have helpers to have our nir reg cake and eat it too, I can translate llvmpipe
<alyssa>
*gallivm
<alyssa>
and zink if we really insist on not passing phis through to spir-v.
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<alyssa>
more worried about all the random little backends (lima, etnaviv, r600, ..)
<idr>
Kayden: Is the i2i64 something the shader is explicitly doing?
<Kayden>
no, it's coming from vtn_access_link_as_ssa
<Kayden>
I guess the deref chain as a whole is 64-bit involving pointers...
<alyssa>
OK, finally managed to get a T860 testing environment locally
<Kayden>
but array indexes really shouldn't be 64-bit IMO
<alyssa>
and yep, can reproduce the regression. despite no change in the assembly. Uh.
jfalempe has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
pyromancy has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
jfalempe has quit [Read error: No route to host]
jfalempe has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
<DemiMarie>
As a security researcher, please run as little as possible with kernel privileges. It’s okay for there to be a userspace lib that is maintained as part of the kernel, but if something can run without kernel privileges, it should unless there is an extremely good reason not to.
<alyssa>
SCREAMING
JohnnyonFlame has joined #dri-devel
<alyssa>
karolherbst: Identical disassembly, different bytes (-:
jfalempe has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<alyssa>
yes, this is probably a midgard backend bug, or two
<alyssa>
no, I'm not about to go fixing deep midgard backend bugs
<alyssa>
test passing now anyway. yoof.
<alyssa>
deqp is a lot happier now, lol
<alyssa>
down to 2 fails in deqp-gles2, ok
vliaskov has quit [Remote host closed the connection]
jaganteki has quit [Remote host closed the connection]
<cmarcelo>
is @nora from gitlab on IRC?
<zmike>
cmarcelo: are you planning to review my spirv debug MR
<cmarcelo>
zmike: missed that, will look at it now
<zmike>
thx
Danct12 has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: No route to host]
<karolherbst>
cmarcelo: doubt it, but what's the matter?
TMM has joined #dri-devel
<gfxstrand>
alyssa: What do you need me for?
<gfxstrand>
Oh, mutter. 🙄
<gfxstrand>
It's possible I have a commit in mutter. I don't think so but I know I filed some bugs back in the day.
<cmarcelo>
karolherbst: rusticl registers a callback with spirv_to_nir to get all the error messages and apparently is printing all of them regardless the level, apparently this generates noise to conformance.
<karolherbst>
uhh.. I think I did that
<cmarcelo>
karolherbst: spirv will pass the level, but I wonder if the rusticl side has/should-have an env var to toggle off (or on) the debug output.
<cmarcelo>
(i.e. is probably fine ignoring the level, as long as you give rusticl users a way out of the prints)
<karolherbst>
let me see the code
<karolherbst>
*check
<cmarcelo>
karolherbst: thanks!
<karolherbst>
huh..
<karolherbst>
it shouldn't...
<karolherbst>
cmarcelo: I've added some RUSTICL_DEBUG=spirv thing to make it do that
<karolherbst>
but if that's not used it shouldn't print any errors by itself
<karolherbst>
and it usually does so in debug builds
<cmarcelo>
karolherbst: comment there so @nora can see it. :-)
<cmarcelo>
I don't think spirv code is printing those, as it follows the log level env var we have.
<karolherbst>
ehh
<karolherbst>
that's expected behavior actually
<karolherbst>
on debug builds, the vtn log level can't be changed
<karolherbst>
or the other way around? uhm...
<cmarcelo>
vtn side seems solid here. the thing is we ALWAYS give everything to the debug callback (msg, level, etc)
<karolherbst>
yeah...
<karolherbst>
but there is no debug callback installed by default
<karolherbst>
I'll ask nora what the initial case was
agd5f_ has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
<karolherbst>
Okay, seems like nora did set RUSTICL_DEBUG=program
<cmarcelo>
karolherbst: cool thanks!
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
smiles_1111 has joined #dri-devel
<karolherbst>
alyssa: if I don't forget to check next week, please remind me to verify that all `nir_register` handling inside codegen is dead code
<karolherbst>
actually...
<karolherbst>
uhhh
<karolherbst>
forget what I said, we still call nir_convert_from_ssa(true)
<karolherbst>
uhhh
<alyssa>
karolherbst: boop
<karolherbst>
it's super stupid in codegen
<karolherbst>
so you know what codegen does first coming out of nir?
<alyssa>
convert to ssa
<karolherbst>
not quite, do some pre SSA lowering, _then_ convert to SSA
<alyssa>
heh
<alyssa>
karolherbst: Good news for you, you can just translate the new intrinsics to moves totally naively and then the nouveau optimizer should crunch through them
<karolherbst>
I'd rather consume SSA directly than make use of the new reg things :D
<alyssa>
and you don't need to bother with all my fancy new reg stuff
<alyssa>
or that yes
<alyssa>
or you could just switch to NAK
* alyssa
devil emoji
<karolherbst>
yeah.. the only reason nir_register stuff gets handled because of resolved phi nodes
<karolherbst>
besides that it's all clean SSA
<karolherbst>
the TGSI code path isn't though.. but who cares anyway
<karolherbst>
anyway, it's something I can probably look into next week
aravind has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]