ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<idr>
There are definitely a couple shaders in that trace that depend on correct derivatives after discard.
mszyprow has quit [Ping timeout: 480 seconds]
<idr>
alyssa: Does panfrost treat discard like demote or like terminate?
<imirkin>
idr: you probably know all the drama, but GLSL says it can be terminate, but DX says it's like demote. some DX -> GL conversions don't take that into account.
tursulin has quit [Read error: Connection reset by peer]
<imirkin>
radeonsi has a special setting to treat it like demote for some games
<idr>
Yeah... I'm just trying to decide if I should try to enable the driconf for that game (and the trace, somehow) or find a different solution.
<imirkin>
idr: there's *further* annoyance involved in texturing ... e.g. on nvidia, a tex() can etiher fetch for live channels or for all channels
<idr>
radeonsi does something like what Iris currently does... always try to treat it like demote, but add some extra flowcontrol in the shader to avoid infinite loops.
<imirkin>
and you have to do for all chans if the resulting values are ever used as tex coords or explicitly in derivatives
<imirkin>
treating it like demote is definitely the safe thing
<alyssa>
idr: Uhhhh
<alyssa>
on Bifrost -- terminate, but it's configurable
<alyssa>
Then again panfrost on Bifrost... err.... only supports the CTS
<idr>
Ok
<idr>
alyssa: Which kind of thing is t860?
<HdkR>
A smidge difficult to run the latest AAA games on Panfrost :D
<HdkR>
I've been hitting a bunch of games that require GL 4.1
<karolherbst>
mhh, is there a way to do OpenGL via gbm on an SSH session?
<ajax>
karolherbst: uh. what?
<karolherbst>
ajax: well.. you can do OpenGL directly on a tty, but I am wondering if you can also run stuff via ssh
<karolherbst>
completely surfaceless I mean
<karolherbst>
like running CTS tests
<ajax>
yes, surfaceless should work when ssh'd in
<karolherbst>
mhh
<karolherbst>
then something is wrong here
<ajax>
or at least, if it doesn't, i'd consider it a bug probably
<ajax>
what's the failure you're seeing?
<karolherbst>
eglinfo
<karolherbst>
ehh
<karolherbst>
no error, just no context
<karolherbst>
"eglinfo: eglInitialize failed"
<ajax>
eglinfo from mesa-demos git or from the fedora package? i think the latter is a bit stale
<karolherbst>
ajax: should this also work on a system without acceleration? like where llvmpipe is the only driver available?
<imirkin>
karolherbst: yeah, i run surfaceless over ssh no problem
<imirkin>
oh dunno about llvmpipe. _should_ work, but who knows
<karolherbst>
yeah...
<karolherbst>
maybe something is not installed..
<anarsoul>
karolherbst: try headless weston?
<imirkin>
nah, it should either work or not
<ajax>
karolherbst: i'd say "should", but i've less confidence about that case
<imirkin>
like with mesa
<imirkin>
karolherbst: i use deqp surfaceless + pbuffer
vivijim has quit [Remote host closed the connection]
LexSfX has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
pendingchaos_ has quit [Ping timeout: 480 seconds]
rcf has quit [Quit: WeeChat 3.2.1]
rcf has joined #dri-devel
lemonzest has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
sdutt has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
camus1 has joined #dri-devel
<pq>
robclark, devcoredump sounds interesting, I wonder if that could be used to fetch the DRM flight recorder logs too...
<imirkin>
i don't think it's meant for a stream
oneforall2 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kevina has quit [Quit: Leaving]
idr_ has joined #dri-devel
kevinx has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
mlankhorst has joined #dri-devel
mszyprow has joined #dri-devel
idr_ has quit [Ping timeout: 480 seconds]
dllud has quit [Remote host closed the connection]
dllud has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<pq>
imirkin, what stream? The point of the flight recorder is to dump a big buffer when something fails. Though with flight recorder, the trigger is in userspace, not in kernel or hardware.
<pq>
The problem with the existing flight recorder plans is that dumping the buffer involves using debugfs and root privs, I believe.
tursulin has joined #dri-devel
reductum has quit [Quit: WeeChat 2.8]
pnowack has joined #dri-devel
jkrzyszt has joined #dri-devel
tzimmermann has joined #dri-devel
rasterman has joined #dri-devel
danvet has joined #dri-devel
rgallaispou has joined #dri-devel
<MrCooper>
is there any point using Marge for piglit ATM? Not seeing contention trying to merge multiple piglit MRs at the same time, so it's not really needed, but delays merging of Mesa MRs
Testmantor has joined #dri-devel
Testmantor has quit [Remote host closed the connection]
<pq>
Looks like it's unlikely I'll be resposive on dri-devel@ this year anymore. Looking forward to the 10k email backlog after holidays... >_<
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<emersion>
is there any chance we could maybe have a drm-uapi mailing list?
<emersion>
or even drm-core would be nice
<emersion>
i guess now that lore.kernel.org is a thing i could try to convert my email filters to a lore filter
<emersion>
wow, lei can filter based on edited files
<emersion>
that's pretty handy
<pq>
emersion, if I could bother improving my filters :-) Changing even a bad workflow needs an opportunity to do it.
<emersion>
the fear of the winter holidays email pile!
<pq>
emersion, the idea of a shared filter for all things DRM UAPI does sound attractive!
<pq>
unfortunately, KMS properties are part of the UAPI, and they don't have a header, do they? Or is simply disallowed to add a property that is not added in some generic "here are all properties" .c or .h files?
<jadahl>
so with dma feedbacks and all, scanout works beutifully, except for one thing: buffers with a non-opaque alpha channel assigned to the primary plane results in old content "bleeding through" (it looks like). is there some way to avoid that without having to e.g. allocate a empty opaque buffer and using an overlay plane?
<pq>
maybe something to technically forbid calling low-level property in-kernel API from elsewhere than these shared "here are all KMS properties" files?
<pq>
jadahl, er, what? That sounds like a driver bug.
<jadahl>
emersion: a drm-uapi list or at least less noisy than dri-devel would be nice imo
<jadahl>
pq: I hope it's a driver bug...
<jadahl>
but it happens here
<pq>
jadahl, I mean, KMS has no concept of "old contents". There is no way old contents could be, if there is no KMS plane with a FB with that old content.
<jadahl>
i run 'weston-simple-egl' (without -o) and make it fullscren. TEST_ONLY passes, I scan out from it, and I (sometimes) see an old version of the desktop "below"
<jadahl>
right, I would have assumed a non-opaque alpha hcannel on the primary plane would just end up being black
<jadahl>
but no, not according to testing
<pq>
jadahl, are you sure you don't have other planes still active?
<jadahl>
at most the cursor plane
<pq>
check e.g. drm_info
<pq>
jadahl, which driver and hw is this?
<jadahl>
i915 + iris
<pq>
if you get a drm_info dump from a time when you see the bad old stuff mixed in, we could say for sure
<jadahl>
i doubt it but I'll get a dump anyway
<pq>
I can't even understand how a driver/hardware could make that happen if the plane config really is what you expect. :-)
<jadahl>
its weston-simple-egl, so the non-opaque part is not fully transparent, so it doesn't seem like its making it darker and darker per frame, so given that, it is as if each frame the buffer I assign to the primary plane is "copied" or "composited" on top of some old primary plane
<emersion>
the format is XRGB8888…
<emersion>
that's pretty confusing
<jadahl>
thats... wierd
<emersion>
maybe ask danvet or vsyrjala
<pq>
are you sure the client buffer is on KMS and not going through your renderer?
<emersion>
good point
<pq>
I would also have suspected that simple-egl might not be clearing in render, but you said it's not cumulatively changing the semi-transparent area, so I think that's not it... or is it?
<pq>
nah, you should see something funny right around the triangle when it spins, so I guess not.
<pq>
and there is a glClear call
<danvet>
emersion, not seeing a question?
<jadahl>
pq: according to my printfs, it's being scanned out and no composite is happening
<emersion>
danvet: sorry for the early ping. the question is about an i915 issue jadahl is debugging
<emersion>
danvet: basically, mutter directly scans out an XRGB buffer and the previous contents of an old buffer shows up underneath
<danvet>
ah found it now
<danvet>
some bleedthrough it says
<jadahl>
yea
<jadahl>
sometimes, sometimes it work
<jadahl>
s
<danvet>
yeah double check with debugfs/state file or drm_info that there's really no other plane left
<jadahl>
there was only the primary plane and a cursor plane
<danvet>
not sure we have a tool for that, but vt switch + getfb + read the buffer
<emersion>
ffmpeg kmsgrab?
<emersion>
i've been meaning to write a simple "gimme FB pixels" tool
mclasen has joined #dri-devel
Company has joined #dri-devel
<jadahl>
hmm, this seems related... I had it to provide "MOD_INVALID" only. if I change it to send all the modifiers supported by primary plane, I can't reproduce anymore
<emersion>
maybe you're mixing up modifiers?
<emersion>
it's incorrect to accept a buffer with an explicit modifier and import it without a modifier
<emersion>
"modifier stripping"
<jadahl>
maybe. will double check
<emersion>
unlikely to be the issue, but do you set FB_DAMAGE_CLIPS?
<jadahl>
I do.. I'll see if not doing so helps
<jadahl>
it didn't
<pq>
damage should be totally irrelevant, because I would expect the hardware to re-composite the whole screen on every scanout cycle from scratch.
<emersion>
… you never know what the driver will use damage for :P
<pq>
which is why I said "old contents" simply does not exist in KMS - they would need to be stored somewhere to be present
<pq>
*however*
<pq>
CCS?
<emersion>
yeah
<emersion>
probably related to fast clear or something
<jadahl>
so it looks like it uses the right API. it checks modifier == INVALID on the linux-dmabuf, and uses old api, and if != INVALID, it uses new apis
<emersion>
that sounds good. does the modifier from WAYLAND_DEBUG=1 match what you see in drm_info?
<pq>
I mean if stripping modifiers causes this problem, then maybe the driver is guessing that this buffer comes with a CCS add-on plane, and uses that but actually the compression buffer contains garbage.
<emersion>
i don't think INVALID can ever do CCS
<emersion>
and drm_info shows X_TILED
<pq>
or maybe mutter forgets to forward the handle for the compression buffer?
<jadahl>
CCS?
<emersion>
jadahl: a buffer compression mechanism for intel
<jadahl>
ah
<emersion>
see the modifiers supported by the plane
<pq>
if simple-egl in rendering with CCS, and KMS is done without CCS, then I can imagine the FB containing old garbage if it's not cleared on allocation.
<pq>
*is rendering
<pq>
and this may well happen if both simple-egl and mutter are working in MOD_INVALID mode, right?
<jadahl>
in this case, the modifier in params.add() looks like INVALID
Lucretia-backup has quit []
<jadahl>
ah, think I found the issue. it was what emersion thought of, it didn't use drmModeAddFB2WithModifiers() in this case, but it should have, since the created gbm_bo had a modifier, but the code decided what to use later used the wrong condition (whether the linux-dmabuf was created with MOD_INVALID)
<emersion>
hm, in theory this should be fine…
<emersion>
if you client used MOD_INVALID, you should be able to completely ignore gbm_bo_get_modifier
ccr_ has joined #dri-devel
ccr_ has quit []
adjtm has quit [Quit: Leaving]
Lucretia has joined #dri-devel
<jadahl>
emersion: that was what the code assumed was the case, but changing that assumption to check the modifier of the imported gbm_bo fixes things
<emersion>
that's… weird
<emersion>
maybe there's a bug down the stack
<emersion>
which client is it again?
<jadahl>
weston-simple-egl
<emersion>
so would be a mesa bug
<emersion>
hm
<emersion>
why does mesa send INVALID instead of the modifier in the first place?
<emersion>
do you advertise only INVALID?
<jadahl>
so do I understand it correctly in that gbm_bo_get_modifier() can return a non-INVALID modifier when created without modifier APIs, but one should not need to use any modifier aware API when dealing with this buffer?
<jadahl>
emersion: yes, I only advertise INVALID (will change that, but trying different "modes")
<jadahl>
advertising explict modifiers made things work too
<emersion>
if a client sends a buffer with MOD_INVALID, the compositor can use the modifier-unaware codepath
<jadahl>
so there are two modes: modifier-on, and modifier-off.
<emersion>
okay. so maybe mesa doesn't properly allocate a buffer without a modifier when the compositor doesn't support them?
<emersion>
cc leandrohrb
<jadahl>
in the second, mutter sends format,MOD_INVALID only, and mesa sends params_add(format, MOD_INVALID), and then mutter uses non-modifier API
<emersion>
okay. mutter seems to be correct here
<jadahl>
the first mutter sends format,lots-of-mods and mesa sends params.add(format, some_mod) and mutter uses modifier aware API with that buffer
<jadahl>
one works, the other doesn't
<emersion>
maybe mesa allocates a CCS buffer then sends it as MOD_INVALID. that would be incorrect
<jadahl>
according to drm_info it uses I915_FORMAT_MOD_X_TILED
camus has joined #dri-devel
<jadahl>
i'll file a bug...
camus1 has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
adjtm has joined #dri-devel
camus has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
<emersion>
hmm
<emersion>
easy answer: just use modifiers lol
<emersion>
yea please file a bug :)
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
Danct12 has joined #dri-devel
pcercuei has joined #dri-devel
<jadahl>
emersion: thats the plan (use modifiers for client buffers), but there will be ways to disable those for debugging, and would be nice if they weren't broken :P
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
milkylainen has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
Daanct12 is now known as Danct12
FireBurn has quit [Read error: Connection reset by peer]
FireBurn has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
loki_val has joined #dri-devel
<jenatali>
MrCooper: Re: piglit+Marge, the one benefit I can think of is the Part-of tags, but I guess you could manually add those
crabbedhaloablut has quit [Ping timeout: 480 seconds]
cedric has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
kevinx has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
JohnnyonFlame has joined #dri-devel
robert_mader has joined #dri-devel
robert_mader has quit []
ddevault has quit [Remote host closed the connection]
vivijim has joined #dri-devel
ddevault has joined #dri-devel
<leandrohrb>
emersion, jadahl: on a quick look at the mesa egl code I've found nothing wrong
<leandrohrb>
please cc me when you file the bug
<jadahl>
leandrohrb: will do (been out for lunch so haven't yet)
Lucretia has joined #dri-devel
<leandrohrb>
thanks!
dllud has quit [Remote host closed the connection]
dllud has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<MrCooper>
jenatali: good point about Part-of
alyssa has left #dri-devel [#dri-devel]
<Venemo>
agd5f: Can you say how to dump the STB? Unfortunately I can't reproduce the hang locally but I'd like to help a user who reported a bug.
<agd5f>
Venemo, just read from the amdgpu_smu_stb_dump file in debugfs. The patches are pretty recent so you'll need a drm-next branch for now
<Venemo>
agd5f: ah, I don't have that unfortunately. Is this going to land in 5.16 or 5.17?
<agd5f>
5.17
<Venemo>
Good to know.
<Venemo>
How do you parse the contents of that file, BTW?
<Venemo>
Is there a tool we can use to get some info from it, or is it something that only AMD can analyze?
nchery has quit [Ping timeout: 480 seconds]
yk has quit [Remote host closed the connection]
<robclark>
pq: we do also have devcoredump rigged up for display errors (underflow, etc).. although would be nice to include flight recorder / drm_trace stuff
yk has joined #dri-devel
<pq>
robclark, I guess I should rtfm, but does devcoredump allow triggering the dump from userspace and what privileges are needed for that and accessing the dump? Is it still in debugfs?
<robclark>
pq: short answer, triggered from kernel, cleared from userspace.. shows up in sysfs.. I think there is a udev event or something like that to let userspace know there is a crash to scoop up (but hadn't looked closely at that part of things.. I just know somehow CrOS's crashreporter thing gets notified that there is a crash to package up and send back)
idr_ has joined #dri-devel
<pq>
sysfs sounds like an improvement already
<pq>
maybe DRM could have a master-only ioctl to trigger it
<robclark>
yeah, or sysfs file.. or one could do what we do for gpu state in drm/msm... we use drm_printer stuff so essentially same codepaths give you $debugfs/n/gpu to dump out gpu state on-demand
<pq>
debugfs is awkward because it's not meant to be used in production, but sysfs is
<emersion>
right, debugfs not subject to uAPI guarantees
<robclark>
sure, but my point was more that with drm_printer and a bit of care you can use the same code-paths to both feed data into userspace slurping out snapshotted state for devcoredump or for debugfs/sysfs/etc
<robclark>
that said, I kinda find kernel triggered dumps are more useful, because we can snapshot the hw state closer to the point in time where $something_bad happened
<pq>
Sure, that's good when the kernel knows something unexpected happened.
<pq>
I have a different use case where the kernel doesn't know that userspace is surprised something didn't work.
<pq>
like a mistake in emitting state for atomic commit
JohnnyonFlame has quit [Ping timeout: 480 seconds]
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
nchery has joined #dri-devel
glennk has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
drawat has quit [Quit: Leaving]
glennk has quit [Quit: Leaving]
glennk has joined #dri-devel
<agd5f>
Venemo, only AMD at the momnet
<Venemo>
agd5f: OK. Is this something I can recommend to users who are willing to build their own kernel?
<agd5f>
Venemo, yeah. For APUs, the interface is via the amd-pmc driver since the log is global for the entire APU
<Venemo>
agd5f: this user has a RDNA2 dGPU
mclasen has joined #dri-devel
mbrost has joined #dri-devel
idr_ has quit []
idr has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
fxkamd has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
mszyprow has quit [Ping timeout: 480 seconds]
rgallaispou has left #dri-devel [#dri-devel]
mclasen has quit [Ping timeout: 480 seconds]
milkylainen has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<agd5f>
robclark, does devcoredump only come into play when there is a kernel panic or can the driver decide when it needs to happen?
<robclark>
driver decides when it happens
<agd5f>
thanks
<robclark>
agd5f: fwiw, see msm_gpu_crashstate_capture().. that is triggered from (for example) a6xx_fault_detect_irq() which kicks recover_worker
<robclark>
if there is already a devcoredump that userspace hasn't read out, we skip it.. which kinda throttles the # of devcoredumps generated if things go "really wrong"(TM)
<robclark>
dev_coredumpm() is the thing that makes it visible to userspace
mszyprow has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
mclasen has joined #dri-devel
iive has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
jhli has joined #dri-devel
<robclark>
danvet, vsyrjala: how does i915/intel_dp_compliance deal with multiple dp connectors.. for msm we were talking about moving the debugfs files into per-connector subdirs to handle this, but looking at i915 I notice that you don't seem to do that.. yet must have the same problem?
<vsyrjala>
no idea. the whole compliance thing is a bit of a mess
<robclark>
ok.. yeah, it is about to be a bit of a mess for us when we start introducing multiple dp connectors..
<robclark>
so I guess I'll come up with something
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<vsyrjala>
at some point i was pondering if we could just not have any debugfs junk for this and do it all from userspace via /dev/drm_dp_aux
ella-0_ has joined #dri-devel
jbarnes has quit [Read error: Connection reset by peer]
<robclark>
from looking at how it works, it seems like it needs some out-of-band communication between userspace and driver
jkrzyszt has quit [Ping timeout: 480 seconds]
<vsyrjala>
the test requests/etc. userspace could perhaps just read directly from dpcd. but maybe there needs to be some way for userspace to tell the kernel how to respond to certain events
jbarnes has joined #dri-devel
<vsyrjala>
assuming the normal uapi is not enough to do that
ella-0 has quit [Read error: Connection reset by peer]
<danvet>
robclark, vsyrjala yeah needs some out-of-band and we'd need to wire up short/long pulse to /dev/drm_dp_aux too
<danvet>
iirc there's some special funny test patterns you can't do with just a correctly done fb
<danvet>
robclark, I think whacking it into per-connector debugfs sounds like a good enough idea
<danvet>
not sure how much we should then share interfaces with drivers and code
<robclark>
AFAIU what we did should be pretty close to how it works on i915.. just s/i915/msm/ in the debugfs file names
<robclark>
hmm, well there are some other difference.. but that might be as much about which dp tester box is supported as anything else
gouchi has joined #dri-devel
LexSfX has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
The_Company has joined #dri-devel
tonyk9 has joined #dri-devel
leandrohrb9 has joined #dri-devel
hikiko_ has joined #dri-devel
Thymo_ has joined #dri-devel
ickle_ has joined #dri-devel
pjakobsson_ has joined #dri-devel
CME_ has joined #dri-devel
mlankhorst_ has joined #dri-devel
karolherbst_ has joined #dri-devel
dllud_ has joined #dri-devel
calebccff_ has joined #dri-devel
mmind00_ has joined #dri-devel
pendingchaos_ has joined #dri-devel
mmind00_ has left #dri-devel [#dri-devel]
dos11 has joined #dri-devel
mwk_ has joined #dri-devel
Terman_ has joined #dri-devel
jadahl_ has joined #dri-devel
debian has joined #dri-devel
dllud has quit [charon.oftc.net helix.oftc.net]
pendingchaos has quit [charon.oftc.net helix.oftc.net]
mlankhorst has quit [charon.oftc.net helix.oftc.net]
tursulin has quit [charon.oftc.net helix.oftc.net]
gouchi has quit [charon.oftc.net helix.oftc.net]
karolherbst has quit [charon.oftc.net helix.oftc.net]
Thymo has quit [charon.oftc.net helix.oftc.net]
hikiko has quit [charon.oftc.net helix.oftc.net]
ickle has quit [charon.oftc.net helix.oftc.net]
Company has quit [charon.oftc.net helix.oftc.net]
rawouF has joined #dri-devel
YaLTeR[m] has quit [charon.oftc.net helix.oftc.net]
danylo has quit [charon.oftc.net helix.oftc.net]
Vin[m] has quit [charon.oftc.net helix.oftc.net]
halfline[m] has quit [charon.oftc.net helix.oftc.net]
nielsdg has quit [charon.oftc.net helix.oftc.net]
robertmader[m] has quit [charon.oftc.net helix.oftc.net]
moben[m] has quit [charon.oftc.net helix.oftc.net]
zzoon[m] has quit [charon.oftc.net helix.oftc.net]
gnustomp[m] has quit [charon.oftc.net helix.oftc.net]
doras has quit [charon.oftc.net helix.oftc.net]
unrelentingtech has quit [charon.oftc.net helix.oftc.net]
Namarrgon has quit [charon.oftc.net helix.oftc.net]
neobrain[m] has quit [charon.oftc.net helix.oftc.net]
Tooniis[m] has quit [charon.oftc.net helix.oftc.net]
dcbaker has quit [charon.oftc.net helix.oftc.net]
apinheiro[m] has quit [charon.oftc.net helix.oftc.net]
shadeslayer has quit [charon.oftc.net helix.oftc.net]
ppascher has quit [charon.oftc.net helix.oftc.net]
bbrezillon has quit [charon.oftc.net helix.oftc.net]
robertfoss has quit [charon.oftc.net helix.oftc.net]
pjakobsson has quit [charon.oftc.net helix.oftc.net]
bnieuwenhuizen has quit [charon.oftc.net helix.oftc.net]
rawoul has quit [charon.oftc.net helix.oftc.net]
xantoz has quit [charon.oftc.net helix.oftc.net]
alarumbe has quit [charon.oftc.net helix.oftc.net]
lanodan has quit [charon.oftc.net helix.oftc.net]
calebccff has quit [charon.oftc.net helix.oftc.net]
CME has quit [charon.oftc.net helix.oftc.net]
lplc has quit [charon.oftc.net helix.oftc.net]
Adrinael has quit [charon.oftc.net helix.oftc.net]
tonyk has quit [charon.oftc.net helix.oftc.net]
Terman has quit [charon.oftc.net helix.oftc.net]
jadahl has quit [charon.oftc.net helix.oftc.net]
dv_ has quit [charon.oftc.net helix.oftc.net]
dos1 has quit [charon.oftc.net helix.oftc.net]
JoshuaAshton has quit [charon.oftc.net helix.oftc.net]
pq has quit [charon.oftc.net helix.oftc.net]
leandrohrb has quit [charon.oftc.net helix.oftc.net]
mmind00 has quit [charon.oftc.net helix.oftc.net]
FLHerne has quit [charon.oftc.net helix.oftc.net]
jcristau has quit [charon.oftc.net helix.oftc.net]
el0y has quit [charon.oftc.net helix.oftc.net]
mwk has quit [charon.oftc.net helix.oftc.net]
Ristovski has quit [charon.oftc.net helix.oftc.net]
pepp has quit [charon.oftc.net helix.oftc.net]
samuelig has quit [charon.oftc.net helix.oftc.net]
swick has quit [charon.oftc.net helix.oftc.net]
APic has quit [charon.oftc.net helix.oftc.net]
karolherbst_ is now known as karolherbst
tursulin has joined #dri-devel
debian is now known as Guest8005
xantoz has joined #dri-devel
Ristovski has joined #dri-devel
camus1 has joined #dri-devel
rcf has quit [Quit: WeeChat 3.2.1]
camus has quit [Ping timeout: 480 seconds]
robertfoss has joined #dri-devel
pq has joined #dri-devel
mszyprow has joined #dri-devel
APic has joined #dri-devel
Adrinael has joined #dri-devel
ppascher has joined #dri-devel
bbrezillon has joined #dri-devel
gouchi has joined #dri-devel
samuelig has joined #dri-devel
swick has joined #dri-devel
zzoon[m] has joined #dri-devel
Vin[m] has joined #dri-devel
apinheiro[m] has joined #dri-devel
gnustomp[m] has joined #dri-devel
doras has joined #dri-devel
alarumbe has joined #dri-devel
el0y has joined #dri-devel
nielsdg has joined #dri-devel
shadeslayer has joined #dri-devel
robertmader[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
FLHerne has joined #dri-devel
JoshuaAshton has joined #dri-devel
jcristau has joined #dri-devel
dcbaker has joined #dri-devel
moben[m] has joined #dri-devel
halfline[m] has joined #dri-devel
lanodan has joined #dri-devel
danylo has joined #dri-devel
Tooniis[m] has joined #dri-devel
bnieuwenhuizen has joined #dri-devel
YaLTeR[m] has joined #dri-devel
lplc has joined #dri-devel
<kisak>
4 independent merge requests to fix building swr with llvm 13, none reviewed, all closed now that swr is amber status. Kinda sad that abandon was chosen instead of redirect to the release branch.
dv_ has joined #dri-devel
<ajax>
we can reopen them and retarget them
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
pendingchaos_ is now known as pendingchaos
Guest8005 has quit []
pepp has joined #dri-devel
Namarrgon has joined #dri-devel
Haaninjo has joined #dri-devel
rcf has joined #dri-devel
mmind00 has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<Kayden>
is frontbuffer rendering still a thing?
<Kayden>
I guess it would be, though rendering to the actual buffer that's being scanned out is super uncommon these days..
leandrohrb9 has quit []
mclasen has quit [Ping timeout: 480 seconds]
leandrohrb has joined #dri-devel
<anholt>
Kayden: EGL_KHR_mutable_render_buffer is a pretty big deal in frontbuffer rendering.
<anholt>
android and chrome os both need it
<robclark>
yeah, pretty must-have for stylus use-cases
<robclark>
and yes, we render directly to scanout buffer (with some minigbm flags that tell things it will be frontbuffer scannout so we don't try to use UBWC)
<Kayden>
okay, so yes. looks like iris doesn't support that extension, so probably some fun to do there in the future
<Kayden>
is there a good way to determine that a pipe resource might be used for front buffer rendering?
<Kayden>
PIPE_BIND_DISPLAY_TARGET seems wholly unused these days, and PIPE_BIND_SCANOUT can be a pageflipped backbuffer
<Kayden>
apparently the intel docs have some excellent text saying that using the blitter on a front buffer with FBC enabled "is not supported", whatever that means
<Kayden>
I think the likelihood of that occuring is approximately 0, but I can't say it -is- 0, so... :/
<robclark>
For CrOS in particular, I think you shouldn't need to do anything special, since buffer is allocated outside of driver and dma-buf imported with appropriate modifiers
<robclark>
FBC for front buffer rendering is a bad idea, because hw doesn't write pixel and meta data atomically, so you are racing with scanout engine
<robclark>
resulting in fun artifacts
<Kayden>
yep
<robclark>
ie. not just tearing, but what looks like corruption
<Kayden>
thinking the blitter doesn't write that metadata
<robclark>
for cases where mesa is allocating the buffer, we might want something similar to minigbm GBM_BO_USE_FRONT_RENDERING flag
<anholt>
for Xorg, expect GL ops on frontbuffer for anything allocated with SHARED.
<anholt>
though modesetting does try to dodge compression by avoiding multi-plane formats.
<anholt>
(whoops, not all compressed formats are multi-plane)
<robclark>
hmm, that won't actually work for us.. since we have single plane for UBWC
<robclark>
right
<Kayden>
__DRI_IMAGE_USE_SHARE is on all backbuffers, but I guess those also have __DRI_IMAGE_USE_BACKBUFFER
<anholt>
we used to pass a GBM_BO_USE_SCANOUT flag in the pre-modifiers world
<anholt>
I think my vote would be that you have your FBC format have its own modifier (same as we do), then Xorg can blacklist it.
<anholt>
(I'm assuming that this is fbc where producers are writing metadata, not the old intel fbc where some engine periodically compressed your stuff?)
<Kayden>
I have no idea
<Kayden>
I assume it's the old intel stuff
<Kayden>
I have one sentence in a doc saying not to do something
<anholt>
ok, so you don't have to tell your 3d engine about space for fbc metadata, for example
<Kayden>
we don't, no
<anholt>
ok. that makes the modifier option make less sense
<Kayden>
I think I'm pretty inclined to leave this broken until someone actually runs into an example case where it's a problem
<anholt>
I think at this point you want some patches floating around for "what if we had modifiers *and* flags?" because it turns out life is hard and you do want to pass the "this modifier, plus scanout"
<anholt>
given how rare front buffer rendering is in xorg these days...\
<anholt>
though, huh. who makes the policy decision to enable fbc?
<Kayden>
kernel
<Kayden>
I think
<anholt>
it just does it to you, hmm.
<anholt>
modifier does sound more reasonable, again.
<anholt>
(so you can actually get EGL_KHR_mutable_render_buffer going)
<Kayden>
sigh, and PIPE_BIND_DRI_PRIME / __DRI_IMAGE_PRIME_LINEAR_BUFFER is a specific punchthrough that isn't even the case for many PRIME setups
<robclark>
is MRB actually supported w/ x11 winsys? IIRC we added some bits in platform_android.c for it (since android apps that use stylus want it).. and for CrOS native side of things, it is all surfaceless so only minigbm knows
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<emersion>
> <anholt> I think at this point you want some patches floating around for "what if we had modifiers *and* flags?" because it turns out life is hard and you do want to pass the "this modifier, plus scanout"
<emersion>
we have this already
<anholt>
maybe my xorg checkout is too old?
<emersion>
hm, i'm just talking about GBM here
<emersion>
i don't know about Xorg
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
mszyprow has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
adjtm has quit [Ping timeout: 480 seconds]
mlankhorst_ has quit [Ping timeout: 480 seconds]
<zackr>
ajax, MrCooper: do you guys know why xorg-video-fbdev would return "(EE) No devices detected." on a system with efifb loaded and working? i got that question from someone trying rhel9 on arm64 without a gpu and rhel installer and xorg won't start and i guess fbdevhw says it can't find devices
rasterman has quit [Quit: Gettin' stinky!]
mszyprow has quit [Ping timeout: 480 seconds]
<anholt>
imirkin: so, how did you use drm-shim? for me, screen cleanup stalls out waiting for a fence.