ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rasterman has quit [Quit: Gettin' stinky!]
glennk has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
flynnjiang has joined #dri-devel
shoragan has quit [Quit: quit]
shoragan has joined #dri-devel
co1umbarius has joined #dri-devel
yyds has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
flynnjiang has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
tlwoerner__ has quit [Read error: Connection reset by peer]
tlwoerner_ has joined #dri-devel
<mareko>
I just noticed that zink has an exact copy of the some of the juicy amdgpu winsys code, including comments
<jenatali>
Oof
<mareko>
I don't mind that, sharing that code would make refactoring difficult for us, but the downside is that Mike will have more copying to do next year
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
simon-perretta-img has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
mwalle has joined #dri-devel
<MrCooper>
ChaosPrincess: if you mean libGL.so.1, that symbol isn't part of its ABI, you need to retrieve it using glXGetProcAddress
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
apinheiro has joined #dri-devel
jfalempe has joined #dri-devel
tursulin has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
lynxeye has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
tlwoerner_ has quit [Read error: Connection reset by peer]
kxkamil has quit []
tlwoerner_ has joined #dri-devel
lina__ has quit []
pekkari has joined #dri-devel
rasterman has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
pcercuei has joined #dri-devel
neniagh_ has quit [Read error: Connection reset by peer]
neniagh has joined #dri-devel
mripard has joined #dri-devel
pekkari has quit []
nektro has joined #dri-devel
<nektro>
is there any function i can call or env var i can set to make mesa panic when encountering an error instead of always requiring calls to glGetError?
<nektro>
> A context can be created in debug mode. This allows, among other things, debug output functionality to work more effectively.
<nektro>
is this referring to mesa being built in debug mode?
<nektro>
i have added glEnable(GL_DEBUG_OUTPUT); but am not sure if that's all
<HdkR>
You also want to use glDebugMessageCallback
vliaskov has joined #dri-devel
MTCoster has quit [Read error: Connection reset by peer]
TimurTabi has quit [Read error: Connection reset by peer]
jimjams has quit [Read error: Connection reset by peer]
nicolejadeyee has quit [Read error: Connection reset by peer]
nirmoy has quit [Write error: connection closed]
jbarnes_ has quit [Read error: Connection reset by peer]
bwidawsk has quit [Write error: connection closed]
jimjams has joined #dri-devel
TimurTabi has joined #dri-devel
nirmoy has joined #dri-devel
MTCoster has joined #dri-devel
nicolejadeyee has joined #dri-devel
bwidawsk has joined #dri-devel
jbarnes_ has joined #dri-devel
<nektro>
thank u :)
bmodem has quit [Ping timeout: 480 seconds]
xroumegue has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
Surkow|laptop has joined #dri-devel
bmodem has joined #dri-devel
pq has quit [Quit: brb]
<nektro>
got both hooked up and it found my issue super quick, thanks HdkR + ishitatsuyuki !
jsa has joined #dri-devel
pq has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Leopold has quit [Remote host closed the connection]
kts has joined #dri-devel
Leopold has joined #dri-devel
tlwoerner_ has quit [Read error: Connection reset by peer]
tlwoerner__ has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
masush5[m] has quit []
bmodem has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
illwieckz has quit [Remote host closed the connection]
<tomba>
I've been trying to understand what exactly DRM_PLANE_TYPE_PRIMARY and DRM_PLANE_TYPE_OVERLAY mean. Are they just hints to the userspace, or does a plane being primary/overlay imply some kind of specific behavior from that plane?
<tomba>
For a bit of context, the TI display subsystem has 4 identical generic planes. Currently the driver doesn't restrict those in any way, but there have been requests to artificially limit the planes a bit so that the userspace has it easier. I don't particularly like that idea, but if "everyone" is using that, it's good to be on the same train. However, I can't find any mention about the expected behavior.
<mripard>
tomba: the "artificial" restriction is at least what we're doing on sun4i and vc4 which are in similar situations
<tomba>
And to be more specific, the idea would be to dedicate one plane for each crtc, and mark those as primary. I'm not sure if additionally we need to restrict the zpos, so that the primary is always behind any possible overlay planes.
kts_ has joined #dri-devel
<mripard>
yeah, that's what I was refererring to too
kts_ has quit []
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<mripard>
sun4i has 4 planes with the same features, vc4 has... something else, but for that discussion is in the same situation :)
<mripard>
I don't think we can have the expectation that the primary plane is the background plane though
<tomba>
mripard: Yep. but is that good, or is it just the easy way out so that the userspace doesn't have to be fixed? =). In the embedded world not everyone uses X or weston, and I'm a bit hesitant to essentially remove planes from possible use cases. Then again, to be honest, I don't specifically _know_ anyone requiring the full plane configurability.
<javierm>
tomba: AFAIU the problem is that there are user-space that can't handle universal planes
<mripard>
tomba: I hear what you say about embedded, but also if your driver can't work with weston or X, your driver is broken
<mripard>
so yes, there will be embedded-specific problems and solutions
kts has quit [Ping timeout: 480 seconds]
<mripard>
but I think the general expectation is that its "standard" behaviour is the same than everyone else
<mripard>
but pq and emersion are the ones to poke on this :)
<tomba>
mripard: well, I agree but not fully. new features are being added to weston all the time. those weston features might be broken, even if they work on certain set of drivers but not all.
<tomba>
afaik, tidss used to work fine with weston, but doesn't anymore because... magic stuff that I'm not quite aware of. gpu hw recovery, overlay plane features, perhaps.
<tomba>
(I'm trying to get more information about the actual issues, so sorry my vagueness =)
<tomba>
javierm: I'm not sure that's the case, at least in the particular case I'm looking at. I think the related apps use universal planes (but I have to say I'm not sure). However, what's said there in a comment makes sense: "Once the client passes DRM_CLIENT_CAP_UNIVERSAL_PLANES, it should not bother with the primary vs cursor vs overlay planes". I'm not sure if that's a real rule, though.
frieder has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<emersion>
tomba: not sure if i have all context, but the driver can expose stuff differently if user-space doesn't announce support for universal planes
<mripard>
emersion: I think the main question is: is there any expectation wrt to primary planes, and whether or not they should be tied down to a given CRTC or can be moved between CRTCs
<tomba>
emersion: Hmm good point. But what is the "right" way for non-universal and universal cases?
<emersion>
primary planes do not need to be tied to a specific CRTC, no
<mripard>
emersion: and so it's "fine" if a CRTC doesn't have an available primary plane?
<emersion>
oh, no, that one is not ok
<emersion>
a primary plane needs to have >1 possible CRTC
<emersion>
a CRTC needs to have exactly 1 primary plane
<tomba>
mripard: "available" in what sense? in my cases there's always a plane for each crtc.
<mripard>
but if they aren't tied to a given CRTC, they can be assigned to another
<mripard>
so you could have a CRTC with a primary plane but currently being used on another
<mripard>
tomba: available == not currently used
frieder has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.1.2]
itoral has quit [Quit: Leaving]
<tomba>
A related question/point: I don't think drm drivers do any kind of reset when a drm application exits or starts. So, let's say we have app A, which uses universal planes, and moves all planes to crtc0 from the other crtcs. And then exits. App B starts, which doesn't use universal planes (well, actually, no app "uses" universal planes until they set the client cap). I think here the planes would still be assigned to the crtc0, and app B wouldn't be
<tomba>
able to cope with that.
<emersion>
yeah, that's kind of expected
<pq>
tomba, that KMS hand-off from complex to simpler app problem is already unsolved. You're nothing bringing anything new to it by the planes situation.
<emersion>
user-space A sets NEW_FANCY_PROP, user-space B doesn't understand it and can't unset it
<pq>
practically all KMS properties have the same problem: what if someone set it to something weird, and I don't even understand what it is
<pq>
today's solution to that is: don't leave weird state behind, if you want to play nice with others
<emersion>
indeed
<emersion>
we've requested multiple times a way to reset the KMS state in same way
<tomba>
right, been there, done that =).
<emersion>
but kernel devs don't like this for some reason
<pq>
It's a bit unfortunate, but not pressing enough that anyone would invest the effort to solve it.
<tomba>
I wanted to bring that point up, as I think that complex-simple switch is one part of the simplify-planes-argument.
<pq>
well, in production, when do you even switch between KMS apps?
<tomba>
the users, they do silly stuff...
kts has quit [Quit: Leaving]
<pq>
Firmware to Plymouth to graphical login compositor to session compositor. Often login and session compositors are the same, or at least cooperative.
donaldrobson has quit [Remote host closed the connection]
<pq>
I totally see the problem, and I can see how to trigger it, but somehow it still hasn't been important enough to solve. Not for me, either.
<tomba>
Anyway, looking at the discussion above, is my summary here correct: With universal planes, the app should be allowed to move primary planes around, and with universal planes the plane type doesn't really mean much. Switching between KMS apps goes into uncharted territory, and there can be problems.
<pq>
yeah
<pq>
you can mark a plane to be usable on more than one CRTC, so you'd probably mark all to be usable on all CRTCs
<pq>
what would be really nice towards userspace is to have enough primary planes so that every CRTC can get one.
<mripard>
how does zpos (and in particular immutable zpos) work in that case then?
<tomba>
pq: yes, that what the driver (tidss) does currently, and there's a primary plane for each crtc. but (reportedly) weston gets very confused in some cases (I'm trying to get more details).
<pq>
When userspace is looking to light up a CRTC+connector, it usually first looks for a primary plane for that CRTC, because that is the most probable configuration to work.
frieder has quit [Ping timeout: 480 seconds]
<emersion>
mripard: immutable zpos, but different zpos depending on CRTC>
<emersion>
?
<pq>
tomba, would be nice to have a Weston bug report filed, indeed.
<mripard>
emersion: I think most of the kernel drivers will set the immutable zpos of primary planes to 0
<emersion>
note, multiple drivers advertise multiple possible CRTCs per primary plane
<emersion>
i think some drivers are also lazy and set possible CRTCs to 0xFFFFFFFF
<pq>
mripard, probably those drivers do not mark the plane compatible with more than one CRTC - if they do, they could use some fixing.
frieder has joined #dri-devel
<emersion>
(ie, have bits in possible CRTCs that refer to non-existing CRTCs)
<pq>
IIRC, if zpos values are equal, the plane z-ordering is undefined, isn't it? That's what I'd expect in userspace anyway.
<emersion>
yes
<pq>
so if all planes have immutable zpos=0, userspace would just not use more than one plane on a CRTC, because it won't know what would happen.
<emersion>
pq, "of primary planes" only
gwaldron has joined #dri-devel
<tomba>
I don't think the zordering is undefined, exactly. With the zpos normalization, the normalized zpos (if zpos=0 for all planes) will be based on plane index. But if the userspace sets the same zpos on multiple planes and gets problems, I think it can only blame itself...
<mripard>
pq: the kernel will order them by plane index
<mripard>
but I'm not sure it's guaranteed, so it would fit under undefined :)
<pq>
mripard, kernel internals, not supposed to be relied upon.
xq has quit [Ping timeout: 480 seconds]
<pq>
as long as zpos exists, at least
<emersion>
the plane index thing is documented in case zpos doesn't exist
<emersion>
if zpos exists, the order is documented as undefined
xq has joined #dri-devel
<pq>
emersion, in the example, I understood there are 4 primary planes, each capable of all 4 CRTCs, and no other planes. Is there any rule that userspace should not attempt multiple primaries on the same CRTC? unless all have identical zpos.
<emersion>
no such rule
<emersion>
right
<emersion>
in that case, order is undefined
<emersion>
a helpful driver might try to come up with a device-wide unique zpos
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
<pq>
a driver should, indeed, or make zpos mutable
<emersion>
yea
<pq>
Userspace could choose to never use more than one primary plane per CRTC. This would make it much more likely that it can light up additional CRTCs easily. But if more complex logic is implemented in userspace, that's not necessary.
<emersion>
to light up more CRTCs, you'll need to start from scratch, basic configuration on all CRTCs
kts has joined #dri-devel
donaldrobson has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
gwaldron has quit [Remote host closed the connection]
<agd5f>
airlied, sima can we get a backmerge of 6.7-rc5 to drm-next? I need the drm/prime unexport revert for some kfd changes
macslayer has quit [Remote host closed the connection]
macslayer has joined #dri-devel
<gfxstrand>
dcbaker: What's the min python version we support?
cmichael has quit [Quit: Leaving]
<mattst88>
DavidHeidelberg: just curious if you know whether there's been any progress upstream in VK-GL-CTS on reducing the number of tests added in 1.3.7.0?
<mattst88>
gfxstrand: not definitive, but we reduced the required version to 3.6 in bca22a65781665054a7d9d964e548459c610593e 11 months ago
<mattst88>
since then ChromeOS has moved from 3.6 to 3.8 though, so we don't need older than 3.8
<mattst88>
that's the most recent Python version-related change I can find, so 3.8 seems plausible
frieder has quit [Remote host closed the connection]
gwaldron has joined #dri-devel
<DavidHeidelberg>
mattst88: about Python 3.6, there was some RHEL person who was fighting for this I think :D
<gfxstrand>
As long as we're okay with cpython || version >= 3.8, I think we're fine.
<gfxstrand>
karolherbst assumed ordered Dict in a patch
vliaskov has quit []
Leopold_ has joined #dri-devel
<mattst88>
DavidHeidelberg: did you see my question about VK-GL-CTS?
JohnnyonFlame has joined #dri-devel
<mattst88>
daniels: maybe you know?
mripard has quit [Ping timeout: 480 seconds]
<DavidHeidelberg>
mattst88: yup, but not sure (not from my side)
<karolherbst>
gfxstrand: list of tuples sounds like a good idea here though
<karolherbst>
gfxstrand: funny enough, it just works with the changes 🙃
<karolherbst>
mhh...
<karolherbst>
python is weird
<karolherbst>
now that I changed the default to `[]` it doesn't anymore...
<karolherbst>
ohh nvm.. I disabled nvk for $reasons
jbarnes_ has left #dri-devel [#dri-devel]
jbarnes has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]