ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
RAOF has joined #dri-devel
ngcortes has quit [Quit: Leaving]
ngcortes has joined #dri-devel
RAOF_ has joined #dri-devel
RAOF has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
ADS_Sr_ has joined #dri-devel
ADS_Sr has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
shashanks_ has joined #dri-devel
shashanks__ has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
kzd has quit [Quit: kzd]
pac85 has quit [Quit: Connection closed for inactivity]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
kzd has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
shashanks has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
simondnnsn has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
pitust has quit [Write error: connection closed]
kennylevinsen has quit [Read error: Connection reset by peer]
rpigott has quit [Write error: connection closed]
kuruczgy has quit [Read error: Connection reset by peer]
simondnnsn has quit [Read error: Connection reset by peer]
sumoon has quit [Remote host closed the connection]
kchibisov has quit [Ping timeout: 480 seconds]
cmarcelo has quit [Read error: Connection reset by peer]
rosefromthedead has quit [Read error: Connection reset by peer]
mainiomano has quit [Ping timeout: 480 seconds]
ifreund has quit [Write error: connection closed]
Leopold has quit [Remote host closed the connection]
glennk has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
cef has quit [Quit: Zoom!]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
MarkCollins[m] has joined #dri-devel
simondnnsn has joined #dri-devel
Duke`` has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
Guest13704 has joined #dri-devel
Guest13704 has quit [autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2024-01-11 06:19:51)]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
dsrt^ has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
dsrt^ has joined #dri-devel
ondracka has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
ondracka has joined #dri-devel
DodoGTA has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
ondracka_ has joined #dri-devel
elongbug__ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
ondracka has quit [Ping timeout: 480 seconds]
DodoGTA has joined #dri-devel
fab has quit [Quit: fab]
elongbug_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
macslayer has quit [Remote host closed the connection]
rasterman has joined #dri-devel
frieder has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
elongbug__ has quit [Remote host closed the connection]
sima has joined #dri-devel
kts has joined #dri-devel
elongbug__ has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
fab has joined #dri-devel
jsa has joined #dri-devel
jsa1 has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
jsa1 has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
Leopold has joined #dri-devel
elongbug_ has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
tursulin has joined #dri-devel
Leopold has quit [Remote host closed the connection]
elongbug__ has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
glennk has joined #dri-devel
fdu_ has quit []
fdu has joined #dri-devel
Ermine has joined #dri-devel
hansg has joined #dri-devel
DodoGTA has quit [Ping timeout: 480 seconds]
DodoGTA has joined #dri-devel
DodoGTA is now known as Guest13722
DodoGTA has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
elongbug_ has quit [Remote host closed the connection]
Guest13722 has quit [Ping timeout: 480 seconds]
elongbug_ has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
DodoGTA is now known as Guest13723
DodoGTA has joined #dri-devel
<pq>
emersion, whoa, did we actually convince people to rename "secure buffers" to "restricted buffers"?
<emersion>
pq, yeah, i can't believe it
<pq>
just another dozen series left to get the memo I guess
<pq>
This made me start to think how a "restricted buffers architecture" could be made usable for everyone and not just the few big companies...
<emersion>
yeah, too late for GBM_BO_USE_SECURE or w/e
Guest13723 has quit [Ping timeout: 480 seconds]
<pq>
maybe some kind of public/secure key split; anyone could encrypt their own content with the public key, and only the hardware has the private key for decrypting it. Then some handwaving around restriction levels (how much HDCP or whatnot is enough) and how to manage a bajillion different key pairs because people have different devices.
<pq>
Then anyone could publish "eyes only" content - as far as the fallacy of "eyes only" is true.
elongbug__ has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
elongbug has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
elongbug_ has quit [Ping timeout: 480 seconds]
elongbug__ has quit [Ping timeout: 480 seconds]
<karolherbst>
how can I run jobs with the correspdoning container locally (and potentially debug them)?
<MrCooper>
karolherbst: docs/ci/index.rst "Building locally using CI docker images" might be a start at least
simondnnsn has joined #dri-devel
<karolherbst>
MrCooper: you know if there is a simple way to pull the env vars used for the build script?
<MrCooper>
those set by the CI configuration YAML, or by the script itself?
<karolherbst>
by the CI config yaml
simondnnsn has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
mvlad has joined #dri-devel
<karolherbst>
mhh, but also "./.gitlab-ci/meson/build.sh: line 96: uncollapsed_section_switch: command not found"
<ernstp>
Struggling with the amd-gfx mailing list and Gmail... "Your membership in the mailing list amd-gfx has been disabled due to excessive bounces"
<MrCooper>
ernstp: #freedesktop is better for that
<ernstp>
thanks
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
andrey-konovalov has quit [Quit: ZNC - http://znc.in]
<airlied>
karolherbst: oh I fought that for a while last week and mostly gave up, but definitely learn to use real docker and not podman :-P
<karolherbst>
installing real docker on fedora is pain tho
<karolherbst>
(and to get it to work)
<MrCooper>
I'd expect podman to work fine for this
<karolherbst>
sure, but podman is also podman and has its own caveats
<MrCooper>
one crude way is to add 'env' to the job script and run it in CI :)
vliaskov has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<mupuf>
pq: I guess it would require FPGA-based GPUs to implement that... but honestly, the entire thing is broken anyway so all you need to do is "encrypt the video file" and let the cpu decode it
simondnnsn has joined #dri-devel
<karolherbst>
mhhh *sigh*.. the error I try to debug doesn't reproduce locally :)
simondnnsn has quit [Read error: Connection reset by peer]
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
yyds has quit [Remote host closed the connection]
<karolherbst>
I blame ccache 🙃
<karolherbst>
though I think it's not used in that job
<dolphin>
So I will send the PR, but will be hard to assess on the quality as the drm-next baseline also looks bleak.
<dolphin>
PR sent
Haaninjo has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<pq>
mupuf, the point of "eyes only" is that the receiver can decrypt and view but not save/copy the decrypted content. For example photographers who need to give out drafts over email but don't want to give out digital pictures, since they sell specifically hardcopies.
<mupuf>
oh, right!
<mupuf>
now I get your point
<pq>
Very much like Digital Rights Management, but available to everyone rather than just the cabal of big companies.
<pq>
of course, if you can view, you can also copy, so the whole premise of "eyes only" is false
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<pq>
just like one can put a hardcopy photo into a scanner
<tleydxdy>
except it's not tho
<tleydxdy>
they can just videograph the whole time you are looking at it
pac85 has joined #dri-devel
<tleydxdy>
all that we have right now is just foreplay to get people comfortable
<javierm>
maybe more like "receiver only with the same image quality that was sent"
<tleydxdy>
tv with cameras are coming very soon
glennk has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<pq>
tleydxdy, so what prevets me from pointing a camera at the screen while I am viewing it?
<pq>
*prevents
cef has joined #dri-devel
<tleydxdy>
the tv sees you are doing that and stops showing you the pictute?
<pq>
the tv doesn't see my camera
<tleydxdy>
well then their camera system is crap
kts has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<pq>
the camera can be behind a half-mirror in a black box, or look like Mickey Mouse, or...
<ccr>
I think "eyes only" can only truly work for situations where both parties ('sender' and 'viewer') explicitly trust each other. for any DRM purposes it is a fallacy. if the content can be viewed, it can be copied - period.
<pq>
indeed
cmichael has joined #dri-devel
<Company>
pq: reddit comments mocking you for not knowing the screenshot tool prevent you from pointing the camera at the screen
<pq>
degrading quality during the copy is a thing though
<ccr>
of course.
<ccr>
and one can try all kinds of stop-gap methods to make it more difficult and slow things down, but alas ..
<Company>
if you do it well, Sam Altman won't use it
<sima>
dolphin, uh looks like lockdep splat in pci subsystem ...
simondnnsn has joined #dri-devel
<sima>
airlied, maybe backmerge?
<sima>
airlied, looks like it's 49de0dc87965079a8e2803ee4b39f9d946259423 we need
simondnnsn has quit [Read error: Connection reset by peer]
<sima>
which is only in 6.7 release sadly :-(
<sima>
still probably good enough excuse to make sure we can CI before sending the main pr to linus ...
<dolphin>
sima: wonder why it would impact only shards?
<sima>
dolphin, it's just a part of pci, maybe the others don't have that?
<sima>
I've seen the splat also in some bat machines I think, or I mislooked
<sima>
pci_bus_sem is the thing to grep for, and then it needs to hit some vmd_ functions and I think it should be a match
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<javierm>
pq: yeah, the degrading quality part is why I said that more than "eyes only" is more like "receiver with the quality sent only"
<dolphin>
sima: AFAIK, the BAT and shard machines are not that different, maybe different Kconfig?
<sima>
dolphin, tbh not sure ...
<dolphin>
CI folks confirmed it's the same, so it just happens to not be touched by BAT, but most of the shard tests fail
<dolphin>
so each shard seems to hit it quite early
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
mripard_ has joined #dri-devel
mripard has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
Leopold_ has quit [Remote host closed the connection]
lcn has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
cmichael has quit [Quit: Leaving]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
bmodem has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
cmichael has joined #dri-devel
<sima>
pq, emersion daniels what do you think of output properties in atomic ioctl?
<pq>
sima, what are output properties?
<emersion>
OUT_FENCE_PTR?
<sima>
probably a new type, read-only, and you give atomic a list of these that are read back and stored into the userspace array after atomic_check has finished
<sima>
emersion, yeah but a lot more generic
<emersion>
what's the use-case?
<sima>
so we could give error reasons, hints, computed stuff like the output format and all that
<sima>
just randomly cross my mind rn
fab has joined #dri-devel
<mupuf>
sima: sounds useful for libliftoff
<sima>
so instead of the rather magic OUT_FENCE_PTR trickery it would be a lot more like normal properties
<pq>
javierm, HDR WCG displays probably do enough of quality degradation by simply displaying the picture alone. You'd need expensive camera to properly capture it, and even the picture has already been mangled for the display's panel, which would be less than optimal for any other panel.
<emersion>
that sounds useful, sima
<sima>
plus that added output-prop list in the atomic ioctl so you can get at them with TEST_ONLY
<emersion>
yeah
<emersion>
getting info out of the kernel via TEST_ONLY is important
<javierm>
pq: indeed
<emersion>
so user-space provides a list of output props it wants to query?
<sima>
kinda came up with this because trying to smash the current IMMUTABLE props we have for connector stuff like edid into the atomic framework needs some work anyway, and might as well do it properly ...
<pq>
sima, sounds really cool.
<emersion>
and the kernel fills that?
<sima>
emersion, yeah
<sima>
and since we make it a new property flag we could give it some clear read-only semantics and maybe some high level sanity checks on the implementation side
<sima>
instead of continuing to abuse IMMUTABLE
<emersion>
the thing i'm worried a bit about is in case the output value needs memory
<emersion>
user-space would need to allocate before-hand
<sima>
emersion, blob property
<emersion>
but might not know how much to allocate before-hand
<emersion>
hm, right
<emersion>
so kernel memory
<sima>
it gets a bit tricky though to make sure we don't leak them like a sieve
<sima>
like if we assing a blob prop id then it'll stay around until userspace nuked it
<emersion>
what is user-space's signal for "i'm done with it"?
<sima>
so if userspace doesn't know about a new blob output prop it might leak
<emersion>
user-space should only request props it understands
<sima>
DRM_IOCTL_MODE_DESTROYPROPBLOB
<sima>
hm
<sima>
we could do a weak reference trick
<sima>
since the kernel keeps stuff alive that's still referenced in the current state
<emersion>
ie, not request a prop which creates a blob and then not destroy it
<sima>
including keeping the blob prop id reserved
<sima>
so we could just put the blob in there like that
glennk has joined #dri-devel
<sima>
and as soon as a new blob is put into the output blob prop, the old one gets garbage collected
<sima>
hm
<sima>
no
<sima>
doesn't work for TEST_ONLY, it gets garbage collected before the ioctl finishes :-/
<pq>
definitely "user-space should only request props it understands"
<sima>
emersion, I guess the rule would be a bit tricky, like we make it a weakly referenced blob
<sima>
but if userspace asks for it explicitly as an output prop in an atomic commit
<sima>
we upgrade it to a blob prop as if it has been created by userspace with DRM_IOCTL_MODE_CREATEPROPBLOB
<sima>
including all the lifetime and possible cgroups account rules
<emersion>
that sounds reasonable
<sima>
pq, yeah, but need some rules that work for this ...
itoral has quit [Quit: Leaving]
<sima>
and if it's not requested as an output prop it's just like the boot-up state (for drivers with fastboot, e.g. i915 does create a mode blob this way)
<sima>
weak reference that's gone as soon as that state is gone
<pq>
sima, sound like you are thinking of kernel internals here - they confusee me. Why would a weak blob be created if userspace didn't ask for it.
<emersion>
yeah, kernel internals
<sima>
pq, mostly to keep the api consistent, since these things would work exactly like a prop
<pq>
UAPI?
<sima>
i.e. you could do atomic commit ioctl and then get prop ioctl, which seems to be the use-case for the actual_output_format one (or whatever it was called)
<emersion>
to me the easiest kernel API would not be blobs internally
<sima>
yeah from userspace
<pq>
umm...
<emersion>
like, it would be the blob contents struct instead
<sima>
emersion, it's a pretty simple way to get a pile of data to userspace
<emersion>
and then core DRM creates a user-space blob at the end of the commit if requested
<sima>
otherwise you get the entire 1. query size 2. allocate buffer 3. do the ioctl again dance
<emersion>
but drivers never deal with blobs directly
crabbedhaloablut has quit [Read error: Connection reset by peer]
<sima>
emersion, oh yeah that'd be definitely how the internals would work
<emersion>
ah, then i don't understand the weak ref part
<pq>
oh, I didn't understand you wanted to use get_prop ioctl for these!
<sima>
I'm just talking uapi here
<emersion>
hm, get_prop?
<sima>
pq, it sounded like that's the plan for these hdmi output props ...
<sima>
might be that in the end we'll only ever use output prop list in the atomic ioctl together with test_only
<pq>
I thought you wanted to add a new pair of arrays to atomic commit ioctl, one array lists the output props to return and the other kernel writes the results into.
crabbedhaloablut has joined #dri-devel
<sima>
pq, well that part is just to make it useful together with TEST_ONLY
<emersion>
my understanding would be that user-space passes a {prop_id, value} array to the kernel
<sima>
since the kernel otherwise entirely tosses that state and there's no way for you to get at it
<pq>
but why need get_prop ioctl support at all?
<emersion>
and then the kernel writes the values
<emersion>
without having to get_prop
<sima>
pq, it's zero code because it's all the same already on the kernel
<sima>
disallowing it would require code :-)
<pq>
sima, it cannot be zero code, if you have invent weak block refs or whatnot.
<pq>
*blob
<emersion>
(brb dealing with a ddos)
<sima>
pq, that's only complications in the atomic ioctl, and the added code would be for _strong_ refernces so the blob survives a TEST_ONLY atomic ioctl
<pq>
get_prop could just always fail on output props, or return always zero, or...
<sima>
the weak blob prop thing is already in use as I mentioned for fastboot state in i915
<sima>
also I think GETFB does a weak bo ref, same idea
<pq>
well, if you want to make get_prop ioctl work, okay.
<sima>
pq, weak referenced blob is essentially what you get if a) current atomic state refernces the blob and b) userspace called DESTROYBLOB
<pq>
but if atomic commit ioctl already contains the array where the kernel returns uint64_t results of the output prop queries, then I don't know why anyone would want to get_prop on output props.
<sima>
this is because people really don't like the RMFB semantics and much prefere CLOSEFB
mripard_ has quit [Ping timeout: 480 seconds]
<sima>
pq, yeah maybe no one
<sima>
aside from that seems to have been the plan for the hdmi output format props
<sima>
since they're set in commit, not in the ioctl, they're only guaranteed to be set when the drm event for that commit has come through
<sima>
for nonblocking
<sima>
so it's always a get_prop for that design
Daanct12 has quit [Quit: WeeChat 4.1.2]
<pq>
oh
<sima>
but if we add output prop list to atomic ioctl, that's probably redundant
<sima>
(I don't like that design for a bunch of reasons, which is why I pondered what this should look like really)
<sima>
pq, other reason is that we could do it more incrementally
<sima>
1. add output props, use them with get_prop ioctl
<sima>
2. add more fancy output props that only make sense for TEST_ONLY, add the atomic ioctl complications
<sima>
incremental design and all that
<sima>
plus like I said, it's zero additional code to make it work compared to directly going atomic with output prop list
<pq>
except all the userspace code that needs to be written
<pq>
sound more complicated to me, but also not wrong
<sima>
we have very disjoint compositor space, so might not actually be real overlap there
<sima>
but yeah if userspace wants to go directly all the way, that's a good reason
<pq>
how could userspace not?
<sima>
well for props that only make sense to drive TEST_ONLY decisions, then yeah it has to
<pq>
userspace has to add the code to understand new props anyway
<sima>
I didn't look at what exactly userspace wants to do with the hdmi output format prop, but current code has no support for TEST_ONLY so seems not needed
<pq>
is the HDMI output format prop about RGB vs. 4:2:0 vs. 4:4:4 on the cable?
<sima>
yeah
<pq>
I guess the best use of that is to make sure you force it to remain the same when a compositor is taking over and wants a flicker-free boot, while having the option to force otherwise.
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<pq>
Some people need to force things that drivers currently pick automatically. For backward compat a KMS prop to set that needs to have an "auto" value. But when it's "auto", you still want to know what the driver actually picked...
ifreund has joined #dri-devel
<pq>
...so that if you are fine with "auto", you can tell the end user what they got, or if you want to enforce a value, you know what value is there already to avoid a modeset flicker.
Mangix has quit [Read error: Connection reset by peer]
sumoon has joined #dri-devel
kchibisov has joined #dri-devel
Mangix has joined #dri-devel
ella-0 has joined #dri-devel
mainiomano has joined #dri-devel
kennylevinsen has joined #dri-devel
cmarcelo has joined #dri-devel
rosefromthedead has joined #dri-devel
<pq>
sima, if the atomic commit ioctl contains both output prop array and the return value array, it should also work when the commit lists no other props at all, used purely for reading output props.
kuruczgy has joined #dri-devel
rpigott has joined #dri-devel
pitust has joined #dri-devel
mripard has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
<sima>
pq, yeah it'd also be a get_mutliple_prop ioctl I guess
<pq>
in TEST_ONLY mode at least
<sima>
pq, probably need to decide whether you're allowed to have objects in your output prop list that weren't in the input prop list
<pq>
oh?
<sima>
well if not we need to write a new impl because currently atomic duplicates states and would then read out the values from the duplicated states
<sima>
whereas get_prop ioctl reads the value directly from the current state
<pq>
That would forbid the purely reading case.
<sima>
so if we allow arbitrary output prop it needs a bunch more code
<sima>
not much, but it's not zero
<pq>
I think saving in implementation line counts is much less important than a clear UAPI. :-)
<sima>
pq, oh sure, just saying you don't get it for free, so needs actual usecase and tests and all that
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<pq>
I never assumed any of that could happen without full-blows test and usersapce effort.
<sima>
pq, I mean the incremental addition of using TEST_ONLY + output prop list as a fancy get_prop ioctl
<pq>
adding a single output prop to be used with *any* UAPI needs the full test and userspace effort, right?
<sima>
yeah
<sima>
I thought you want to use this for state readout on compositor switch for existing props though?
<pq>
I didn't think of that.
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<sima>
ah I guess I misunderstood what you meant with taking over and flicker free boot
<pq>
that was specific to the HDMI color format prop
<pq>
sima, but now that you mentioned, if the same call can be used to read out everything, that would be cool. OTOH, being a new feature, userspace cannot lose the old code for quite some time.
<sima>
any1, it's pretty much directly relevant since output props is the generic way for drivers to tell userspace about all kinds of things
<sima>
any1, meaning this idea was motivated by pondering your patches
<any1>
Well, they're really Werner's patches. I just rebased them and fixed the i915 implementation. :)
cmarcelo has quit [Ping timeout: 480 seconds]
rosefromthedead has quit [Ping timeout: 480 seconds]
kuruczgy has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
pitust has quit [Ping timeout: 480 seconds]
ifreund has quit [Ping timeout: 480 seconds]
rpigott has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
kennylevinsen has quit [Ping timeout: 480 seconds]
<pq>
any1, I think the best way to deal with the combinatorial explosion with format/mode/bpc props is to avoid having to generate all combinations. I guess most of them can have a "auto" setting, also in UI, and then separate show what you would get.
kts has quit [Ping timeout: 480 seconds]
sumoon has quit [Ping timeout: 480 seconds]
<pq>
what you would get would be queried from the driver
kchibisov has quit [Ping timeout: 480 seconds]
ella-0 has quit [Ping timeout: 480 seconds]
mainiomano has quit [Ping timeout: 480 seconds]
<pq>
then if people want to force some aspects to specific values, they can change "auto" to something else in the UI, and see how the driver responds.
<any1>
pq: That sounds like the current approach.
<pq>
when the user opens a drop-down of possible values for one prop, the UI could probe the driver for all those values in order to tell the user which ones are possible with the currently selected values for all the other props
<sima>
yeah for gui interfaces the current test_only should be enough since users can't change more than one value at once
<sima>
so there's no combinatorial explosion to test
<pq>
any1, I have a hard time imagining anything else, given the fully exploded list of all driver-possible combinations would still be too long.
elongbug has quit [Remote host closed the connection]
<sima>
the trouble is with compositors where you don't have a human who can just play around with stuff to get an intuitive feel for constraints
<pq>
If the end user is fiddling with these, they know which prop is most important to them, and can fix that first, and see what's left with the others.
<sima>
yeah
elongbug has joined #dri-devel
<sima>
also with gui there's no "must draw next frame in 5ms" constraint
rpigott has joined #dri-devel
mainiomano has joined #dri-devel
<pq>
Well, a compositor is not very different: a compositor has its own policy of which prop is most important to maximize first, then pick what's left of the rest.
<pq>
This is only needed on mode switch, too, so performance is not *that* critical.
<sima>
pq, well I meant for the more general kms config problem, picking the right plane config for a given scene is rather hard
<javierm>
sima: for compositors that don't have an human to play around, that will mostly be embedded / vertial integrated products where the constraints will be mostly fixed I guess?
<any1>
I was just thinking that since color format is a per-mode capability, it might be good idea to send it with the mode info.
<sima>
any1, shared output clocks can break your assumption
<sima>
so you still cannot rely that if an output format is in the mode_info that it's guaranteed to work
<sima>
only that there is _a_ possible kms config where it's possible
<any1>
sima: But at least you know up front what's _not_ going to work.
<pq>
javierm, and all the usual desktop compositors too, because most people do not want fiddle with trivialities.
<javierm>
pq: right
<javierm>
hence your comment on 'auto'
<sima>
any1, doesn't help you in your gui selection box, because you still need to TEST_ONLY verify against the current config
<sima>
unless you want to piss of userspace by showing stuff that doesn't work in the drop-down list
<pq>
well, "auto" is good for most end users too, but it's also needed for UAPI backward compat as the default value for the prop.
<sima>
*piss off users
<sima>
any1, so you need TEST_ONLY anyway, and at that point you don't really need the flags in mode_info since it's purely redundant info
<any1>
That's a fair point
macromorgan has joined #dri-devel
<sima>
any1, now where current atomic test_only breaks apart is if you want to change a lot of props and then figure out what's possible
rpigott has quit [Ping timeout: 480 seconds]
mainiomano has quit [Ping timeout: 480 seconds]
<sima>
that's where the output prop list idea comes in, so you can ask the kernel what a good value would be for an entirely different config
<sima>
but incremental changes in gui should be fully covered as a use-case
<pq>
sima, I didn't realize you wanted to tackle that biggere problem as well.
mbrost has joined #dri-devel
<sima>
pq, well we've been talking about it since forever and been pondering what could error/hints for TEST_ONLY failures look like since years ...
<pq>
sure, but I failed to connect that to output props properly.
<pq>
I see the mechanism working, but defining the actual output props to help with it seems difficult.
<sima>
pq, fully agreed
Leopold_ has joined #dri-devel
<sima>
but maybe starting with a smaller problem might get this going
vliaskov has quit [Ping timeout: 480 seconds]
<pq>
for failure feedback, I wonder if there should be a kernel-writable array matching the KMS props that are being changed, in order to return hints which props were disliked and maybe even why.
<sima>
pq, but I think it might help with a lot of the detail issues, like if the hw needs a tiny bit of rounding in plane coordinates, or a bit of fiddling with gamma ramps and all these might be doable in failure simple and well-contained output props
<sima>
pq, yeah that's where the discussion usually landed, but I feel like that's too big
cmichael has quit [Quit: Leaving]
<sima>
so maybe adding incremental output props for more specific issues is a more tractable approach to get somewhere
<pq>
it feels really difficult to define output props for failure conditions, especially if userspace needs to explicitly ask for each output prop to be returned.
<agd5f>
robclark, Do you know anyone on the gmail team? Can you figure out why gmail seems get so many bounces? Lately I get unsubscribed once or twice a week from freedesktop MLs due to excessive bounces and as the amd-gfx admin, I get get tons of emails that list members with gmail addresses are also getting disabled due to excessive bounces.
<agd5f>
only seems to affect gmail
<sima>
agd5f, maybe #freedesktop?
<sima>
pq, could also be more meaningful, e.g. there's often constraints between features
<agd5f>
sima, I asked there yesterday, they checked the logs and it seems gmail no longer plays nicely with mailing lists
<sima>
like where a given format is incompatible with rotation, and changing either would help
<sima>
agd5f, ugh :-(
<zamundaaa[m]>
pq: whether or not a property is "at fault" for the commit failing sounds a bit difficult to define too. If it needs too much bandwidth, it would have to complain about most plane properties for example
<sima>
zamundaaa[m], yeah there might also be rather general "oversubscribed on planes, use less" issues
<pq>
zamundaaa[m], yes, bandwidth is like that.
<sima>
or "oversubscribed on memory bw"
<sima>
I think some of them are well defined enough that compositors can then do meaningful stuff with it
<pq>
I guess we should ask: what kind of feeedback would let userspace do better, rather than what actually went wrong.
<sima>
pq, yeah
<MrCooper>
agd5f: #freedesktop is still better to discuss that, the relevant people are unlikely to notice it here
<agd5f>
sima, I'm guessing gmail is lowering sender reputations due to too many recipients or something like that. Maybe this is the end of mailing lists
<sima>
like for pure memory bw it's pretty easy for userspace to figure out how to cut it
lcn has joined #dri-devel
<MrCooper>
the end of using gmail for mailing lists, maybe
<agd5f>
like the email lists get really low sending domains because it's assumed that mailing lists are spam
<agd5f>
*low reputations
<sima>
any1, can you pls summarize the discussion/conclusion here on-list?
<any1>
sima: I think you're probably in a better position to summarise than I am, since you have a full understanding of it. :)
<sima>
any1, uh I just jumped over that thread because "explained it on irc" :-)
<any1>
This is my first foray into the DRM subsystem.
<javierm>
any1: IME re-reading these kind of IRC discussiones and trying to come with a summary is a very good learning experience :) It's OK if there are misunderstandings in your summary since Sima and others can chime in
<javierm>
*discussions
<sima>
any1, if you want you can pastebin the draft here for quick review
<any1>
sima: When you say "So I think the better approach would be to put the output type into drm_connector_state", by "output type" do you mean the "active color format"?
<sima>
any1, yeah
<sima>
any1, but that's the big fancy output prop idea (at least a first step towards that), I thought the irc conclusion here was that TEST_ONLY should be good enough for gui config tool usecase?
<sima>
airlied, ah just seen your drm-next PR, I guess that makes the backmerge obsolete
<any1>
sima: Ahh, ok, so we're back to dropping "active output format" entirely?
<pq>
sima, TEST_ONLY that can answer "what would the driver have picked for this prop that I set to auto?", then yes.
<sima>
any1, yeah it sounds like you don't really need it?
<any1>
Well, except some people have pointed out that the user might want to know what was picked if they selected "auto"
<pq>
there are two separate use cases here
<pq>
people playing with setting UI would like to know what "auto" would result in, but that's just nice to have
<pq>
the other use case is the flicker-free boot into known configuration I mentioned
<pq>
the former need TEST_ONLY feedback, the latter is happy with the old get_prop is there if a prop that tells us
<pq>
*if there is
<any1>
It's currently possible to continue with the previously set property?
<pq>
sure
<pq>
The precedent for the flicker-free boot is "max_bpc" prop which is actually a little different than what was discussed here. It has no "auto" setting, but it still acts as a limiter.
<pq>
so the actual bpc picked can be lower
<any1>
Cool. Then we don't need "active color format". :)
<pq>
drivers may initialize with different values for max_bpc, so userspace needs to read it before programming it
<pq>
well, people still want to know what the driver actually chose
<pq>
some people
bmodem has joined #dri-devel
<any1>
Those people can get an HDMI analyzer for $500. :D
<pq>
the problem with "auto" is that any mode set could make the driver decide differently, so if you want to keep your format, you cannot rely on "auto"
<any1>
hmm, yes
<any1>
I'll try to write a summary some time today.
<zamundaaa[m]>
The UX problem with "auto" is really that if the user has a problem with their screen, they first have to trial and error the other options because they don't know what's currently beinh used
dsrt^ has quit [Remote host closed the connection]
<zamundaaa[m]>
We have the same problem with broadcast rgb and we have one or two bug reports about that
<zamundaaa[m]>
But waiting with fixing that until we have output properties for commits, and then adding an output property that says what the driver would recommend / choose with "auto" would probably be okay. As long as we actually get that eventually
yyds has joined #dri-devel
pac85 has quit [Quit: Connection closed for inactivity]
<robclark>
agd5f: sorry I don't.. and it's a pain, it's happening to me too
ckinloch has joined #dri-devel
kts has joined #dri-devel
kts has quit []
pac85 has joined #dri-devel
djbw has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
kzd has joined #dri-devel
kts has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
macslayer has joined #dri-devel
<any1>
Was there a conclusion regarding resource management for output property blobs?
glennk has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mripard has quit [Remote host closed the connection]
<gpiccoli>
Hi folks, this could be an old question..but here it goes (apologies if obvious): why efifb doesn't work after S3/deep sleep? It seems to be restored fine after s2idle, though during s2idle the screen is effectively "powered-up", I can see its backlight on...
bmodem has quit [Ping timeout: 480 seconds]
<gpiccoli>
On S3 it power-offs fine, screen is disabled, but never comes back. Would the display need to be reprogrammed (like it is on boot time by the UEFI GOP) after S3 ?
<sima>
any1, thanks a lot, lgtm
<sima>
any1, I guess the part that's missing is that for gui config selectors current TEST_ONLY should be enough and we don't need any of these more fancy things we discussed
<sima>
that was really the main reason why I asked you to summarize since that's the question you jumped into the discussion with
<sima>
tzimmermann, we generally don't take -next pulls during the merge window, only -next-fixes for the current one ...
<tzimmermann>
sima, oh sorry
<tzimmermann>
sima, maybe just wait until -rc1
<tzimmermann>
i promise to do better
<sima>
tzimmermann, no worries, just wanted to tell you if you'll wonder why it's not landing
mbrost has joined #dri-devel
<sima>
the "-next never closes" is kinda more for committers' benefit, to avoid them pushing new features into the merge window
Duke`` has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
tzimmermann has quit [Quit: Leaving]
vliaskov has joined #dri-devel
kts has quit [Quit: Leaving]
vliaskov_ has joined #dri-devel
kts has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
Leopold_ has joined #dri-devel
yyds_ has joined #dri-devel
alatiera has quit [Quit: Connection closed for inactivity]
<agd5f>
gpiccoli, on S3, the GPU usually loses power. on s2idle, it generally just gets put into a low power state
yyds has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
yyds_ has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
rasterman has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<gpiccoli>
Hi agd5f , thanks - indeed that makes sense. But I thought efifb was basically a memory region set/mapped, different from the full gpu works ...
<gpiccoli>
so, even this in this simple mode, we'd require reprogramming?
mbrost has joined #dri-devel
<javierm>
gpiccoli: but same could be for the display controller or any needed clocks, regulators, etc
<agd5f>
gpiccoli, sure, but the GPU points to it and you need to program the display hardware to actually scan it out
<gpiccoli>
oh yeah, I just had a wishful thinking here..that for a simple fb that would be simpler haha
<gpiccoli>
this was due to my narrow understanding of how GPUs work..certainly! Thanks a bunch javierm and agd5f for the clarification
<gpiccoli>
The good point: amdgpu_fb works fine after S3, so amdgpu reprograms everything..so not a biggie not having efifb [I'm testing something with amdgp blacklisted, that's the full context heh]
<agd5f>
I doubt S0i3 works fully without the GPU driver loaded. I don't think the firmware will enter the lowest power state without the driver driver setting up a bunch of power features
Duke`` has quit []
Duke`` has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
K`den has joined #dri-devel
<gpiccoli>
interesting...
<gpiccoli>
it apparently works, but I'm not measuring power ... so it maybe be suboptimal despite appearing to work heh
Kayden has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
K`den is now known as Kayden
mripard has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
AnuthaDev has joined #dri-devel
ngcortes has joined #dri-devel
hansg has quit [Quit: Leaving]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
<karolherbst>
agd5f: well.. core pci can runtime suspend GPUs just fine (mostly)
<karolherbst>
it's just not enabled by default
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
ondracka_ has quit []
AnuthaDev has quit []
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<agd5f>
karolherbst, depends on the device
Kayden has quit [Quit: office]
simondnnsn has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
simondnnsn has joined #dri-devel
ngcortes has joined #dri-devel
ngcortes_ has joined #dri-devel
ngcortes_ has quit [Remote host closed the connection]
simondnnsn has quit [Read error: Connection reset by peer]
<karolherbst>
yeah, fair
mbrost has joined #dri-devel
Leopold_ has joined #dri-devel
gouchi has joined #dri-devel
Kayden has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
arielcp01 has joined #dri-devel
arielcp01 has quit []
frieder has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
vyivel has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
vyivel has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
mszyprow has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<jenatali>
Is it expected to get a Gallium resource_copy_region call where the source and dest have wildly different formats?
<zmike>
there's a util function for determining copy_region compatibility
<zmike>
I'd read that
<jenatali>
That I'm supposed to call within the driver? Or that mesa/st should call?
<zmike>
in the driver
ngcortes has quit [Ping timeout: 480 seconds]
<zmike>
you would e.g., call this at the top of blit() and then just call copy_region instead of blit if compatible
<jenatali>
Right, I'm not getting a blit though, I'm getting a copy
<zmike>
yeah I'm just giving an example of the usage
<jenatali>
Yeah it seems like gallium should be giving me a blit though, unless it's expected that I can internally route in both directions
<zmike>
I don't think that's expected, no
<airlied>
maybe if the wildly different formats are in the same class
<jenatali>
RGBA16 vs RGBA8
<airlied>
seems wrong then
<airlied>
unless they have different pitches maybe
<jenatali>
Cool. Sounds like I should get an apitrace and file an issue then
<airlied>
it should just operate like a memcpy
<jenatali>
Right
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
hansg has joined #dri-devel
ngcortes has joined #dri-devel
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
luben has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
luben has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
hansg has quit [Quit: Leaving]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
Leopold has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<jenatali>
Oh cool this app crashes apitrace
<jenatali>
Oh nvm, my fault
<jenatali>
Ok so it looks like the app is trying to redefine a texture that was RGBA with UNSIGNED_SHORT and mips, to RGBA with UNSIGNED_BYTE and no mips, and Mesa seems to be trying to copy the RGBA16 mip data into the new RGBA8 texture
<robclark>
possibly fallback path for something the blit path doesn't support?