alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
thelounge90 has quit []
thelounge90 has joined #dri-devel
thelounge90 is now known as alatiera
xexaxo_ has joined #dri-devel
lemonzest has quit [Read error: No route to host]
lemonzest has joined #dri-devel
gpoo has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
<jani>
airlied: in a word, yes
<jani>
airlied: the main decision to make is whether it's header cleanup i.e. struct declarations moved under display/ and they're included from i915_drv.h, or add a pointer to an allocated substruct so everything doesn't need to know what's inside
<jani>
we have liked to avoid pointer chasing
rasterman has joined #dri-devel
shfil has joined #dri-devel
<airlied>
jani: yeah I was leaning towards the latter, is the a major reason toi avoid pointer chasing, not like display is a major hotpath even for modesetting
<pinchartl>
emersion: you're absolutely right, I was not looking at the kernel code properly
<pinchartl>
each dmabuf gets its own inode
<emersion>
ah cool!
<pinchartl>
but also its own struct file
<pinchartl>
so I don't really understand how kcmp could fail
<pinchartl>
do you recall the condition that failed kcmp but worked with fstat ?
<emersion>
hmm, so no matter how many times i import/export a dmabuf, it'll still pass the kcmp test?
<emersion>
another rerason why i changed it is (1) kcmp is linux-specific (2) kcmp requires using raw ioctls
<emersion>
what happens if i have a dmabuf with FD 32, and then i open("/proc/self/fd/42")?
<emersion>
42*
<emersion>
this is supposed to give a new file descript**ion**
adavy has quit [Ping timeout: 480 seconds]
<pinchartl>
that's an interesting question, I'll give it a try :-)
<pinchartl>
fstat is indeed more portable
<pinchartl>
but dmabuf is Linux-specific :-)
<emersion>
it's not :P
<MrCooper>
imirkin pinchartl: kcmp answers the question "do both fds reference the same file description (aka struct file)?", which is stronger than "do both fds reference the same dma-buf?"
<emersion>
BSDs have DRM and DMA-BUFs too
<MrCooper>
there can be an arbitrary number of separate file descriptions for the same dma-buf
<pinchartl>
emersion: good point
<emersion>
MrCooper: ah, interesting. so in the end kcmp not reliable?
<pinchartl>
MrCooper: how do you create a separate struct file for the same dmabuf ?
<emersion>
does this happen if you drmPrimeFDToHandle then drmPrimeHandleToFD?
<pinchartl>
both the inode and the struct file are created together by dma_buf_getfile()
<MrCooper>
pinchartl: ah, actually not sure for dma-buf specifically, I was thinking in more general terms
<pinchartl>
which is a static function called by dma_buf_export() only
<pinchartl>
dma_buf_export() is also what creates ths struct dma_buf instance
<pinchartl>
and it stores the struct file point in struct dma_buf
<emersion>
yeah, i was thinking in more generals terms as well, and decided kcmp was not the right tool for the general case :P
<emersion>
but maybe it happens to be fine
<MrCooper>
emersion: in general, kcmp just answers a different question than "same file?"; both just happen to give the same answer for dma-bufs
Lucretia has joined #dri-devel
<emersion>
yup
<emersion>
tl;dr i'd still favor inodes, if only for the semantics
<MrCooper>
since there's no way to create multiple file descriptions for a dma-buf
tursulin has joined #dri-devel
<pq>
so there is no way a dmabuf could have multiple different inodes?
<MrCooper>
no, seeing as a dma-buf is essentially a file description?
<emersion>
pq, no, a dmabuf has a single inode *and* a single file description in the kernel
<pinchartl>
MrCooper: agreed. the checks are equivalent for dma_buf, so it's about portability and performance (if there's even any meaniningful performance difference)
<pq>
ok - and your open("/proc...") trick, what does that do?
<emersion>
pq, it's a magic linux thing
<pq>
yes
<emersion>
but i haven't checked
<emersion>
would be interesting to know
<MrCooper>
I was just wondering what happens with open() on a dma-buf fd in /proc or /sys
<pq>
right, so best to avoid doing that I guess :-)
<MrCooper>
does that not create a separate file description for the dma-buf?
<pinchartl>
I'll give it a try
<pq>
hmm, maybe I didn't ask correctly... there is no way the same buffer could be exported into multiple separate dmabufs therefore having separate inodes?
<MrCooper>
maybe pinchartl needs to clarify if he's after the same dma-buf specifically, or really after the same underlying BO
<pinchartl>
pq: that depends on DRM, if it caches the dmabuf in the GEM object or creates a new on on each export. I haven't checked
<pq>
wouldn't everyone be always interested in the identity of the underlying BO anyway?
<MrCooper>
I'd tend to agree, but from experience it's better not to make that kind of assumption :)
<MrCooper>
pinchartl: if you really want to know if two dma-buf fds reference the same underlying BO, not sure there's any other way than importing both into the same DRM file description and comparing the resulting GEM handles
<pq>
so far I've been thinking that while fd:dmabuf can be N:1, dmabuf:BO is always {0,1}:1... at least when talking about these which might cause fun problems if the latter can be N:1.
<emersion>
note: be careful about GEM handle ref'counting
<pinchartl>
MrCooper: I'm working on the camera side, so there's not necessarily a DRM device involved
<pq>
haha, oh boy - but the reason the GEM handle comparison works if the very reason why refcounting must be done :-D
<pq>
*is
V has quit [Ping timeout: 480 seconds]
<emersion>
pq, no, it would work perfectly if the kernel did ref'counting, too
<pq>
...somewhere
<emersion>
as in, expect as many "open" ioctls as "close"
<pq>
maybe dmabuf fd should have a new ioctl "is this the same BO as that fd points to?" :-)
<emersion>
the dmabuf wouldn't know
<emersion>
only the backing kernel module would
<pq>
the dmabuf fd is the only fd at hand though
<pq>
strictly from UAPI perspective
<emersion>
i think it
<emersion>
'd make sense to just expose the same inode instead
<emersion>
when the kernel module creates a new dmabuf
<danvet>
at least in drm we guarantee that there's at most 1 dma_buf per buffer
<danvet>
it might not always be the same one, e.g. if you close all references to a dma-buf and then re-export, it's a new dma-buf
<danvet>
but as long as it exists it's unique
<emersion>
pinchartl: ah, cool!
<emersion>
danvet: nice
<pq>
danvet, thanks!
<emersion>
was slightly worried about multiplanar getting different inodes
<pinchartl>
so I think we can conclude that kcmp and fstat will both work, assuming there's no other magic way to create a new file for the same dma_buf
<pinchartl>
well, for multiplanar, you have different GEM objects for the different planes
<pinchartl>
so you do get different inodes
<pinchartl>
this is exactly why I was looking at all this
<emersion>
it depends :)
<emersion>
some drivers use the same BO with a different offset
<pinchartl>
yes
<MrCooper>
danvet: any pointers to where that's handled? Can't seem to find it
<emersion>
and it matters when importing into vulkan
<emersion>
(disjoint images etc)
<pinchartl>
I get a userspace framebuffer object in my code, with an array of fd + offset, and I was looking at a way to check if they all correspond to the same dmabuf, to find out whether or not planes were contiguous
pcercuei has joined #dri-devel
<danvet>
MrCooper, drm_prime_lookup_buf_by_handle
<danvet>
plus code to just give you back the imported dma-buf if it's not a native bo
<pinchartl>
danvet: I think other subsystems that export dmabufs should also guarantee that a given BO will not be exported through different dmabuf instances
<danvet>
pinchartl, dma-buf heaps only has the fd, no other handle
<danvet>
so you can't export twice
<danvet>
v4l only imports
<danvet>
drivers/misc is a dumpster fire
<danvet>
but yeah
<MrCooper>
k, then conceptually, fstat makes more sense to me for this than kcmp
<MrCooper>
thanks danvet
<pinchartl>
V4L2 exports
<danvet>
pinchartl, uh that's new?
<danvet>
does it get it right, or happily just reexports?
<pinchartl>
nope, been there forever
<danvet>
hm oh well
<pinchartl>
looks like it reexports :-(
<danvet>
:-(
<pinchartl>
*sigh*
gouchi has joined #dri-devel
mriesch has quit [Remote host closed the connection]
mriesch has joined #dri-devel
V has joined #dri-devel
Hi-Angel has joined #dri-devel
<MrCooper>
airlied: not a fan of automatically retrying CI jobs for possibly genuine (but not 100% reproducible) failures
<pinchartl>
danvet: looks like an oversight in V4L2, will likely get fixed
shfil has quit [Ping timeout: 480 seconds]
boistordu has quit [Remote host closed the connection]
jhli has quit [Read error: Connection reset by peer]
<daniels>
(GitLab is down yes, coming straight back up, in an attempt to try to fix the flakiness)
mlankhorst has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
V has quit [Ping timeout: 480 seconds]
<danvet>
pinchartl, cool
xexaxo_ has quit [Ping timeout: 480 seconds]
boistordu_ex has joined #dri-devel
<jani>
airlied: (sorry for the delayed responses) I guess the main problem is when you have to check for i915->display != NULL
<jani>
airlied: we could of course ensure it's always non-NULL, but then you kind of lose one of the benefits. could just not allocate when there's no display
<jani>
airlied: in any case, it's a long road
mlankhorst has joined #dri-devel
heat has joined #dri-devel
<airlied>
jani: yeah refactoring might at least get an api betwrrn disp and gt/core
<jani>
airlied: yeah I've been trying to axe the direct access to data via i915 ptr
<jani>
airlied: as well as reduce static inlines in headers that require knowledge of drm_i915_private internals
pendingchaos has joined #dri-devel
xexaxo_ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
shfil has joined #dri-devel
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
lynxeye has quit []
cedric has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
tzimmermann__ has quit [Remote host closed the connection]
tzimmermann__ has joined #dri-devel
Net147_ has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
Net147_ has quit [Read error: Connection reset by peer]
gpoo has joined #dri-devel
bcarvalho has quit [Ping timeout: 480 seconds]
robher has quit []
robher has joined #dri-devel
pjakobsson has joined #dri-devel
itoral has quit [Remote host closed the connection]
Net147_ has joined #dri-devel
Net147 has quit [Remote host closed the connection]
Net147 has joined #dri-devel
Net147_ has quit [Ping timeout: 480 seconds]
Net147_ has joined #dri-devel
Net147 has quit [Remote host closed the connection]
camus has quit []
daniels has quit []
daniels has joined #dri-devel
jonmason has quit []
jonmason has joined #dri-devel
jstultz has quit []
jstultz has joined #dri-devel
sdutt has joined #dri-devel
Net147 has joined #dri-devel
Net147 has quit [Read error: Network is unreachable]
Net147 has joined #dri-devel
Net147_ has quit [Read error: Connection reset by peer]
ogabbay has quit []
ogabbay has joined #dri-devel
camus has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
bcarvalho has joined #dri-devel
JohnnyonFlame has joined #dri-devel
italove has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
Company has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mattrope has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
whald has joined #dri-devel
vivijim has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
<robclark>
pinchartl, danvet: not sure if this has been fixed since then, but at least at one point v4l2 would free the exported buffers when the v4l2 device was closed, even if an importer still has a reference.. which predictably ends in tears..
nchery has joined #dri-devel
<pinchartl>
robclark: that's been fixed a long time ago
<pinchartl>
and in v5.0, V4L2 got the ability to become a generic memory allocator
<pinchartl>
you can open a device, allocate buffers, export them, close the device, and keep using the buffers, importing them in a different device
<pinchartl>
without ever capturing any image from V4L2
<pinchartl>
libcamera uses this to implement a generic dmabuf allocator helper for applications that don't have dmabufs available from somewhere else
<robclark>
ahh, nice.. glad that is fixed, it was kinda a mess
<pinchartl>
because dmabuf heaps are too new, and not necessarily enabled by distributions
<pinchartl>
(we were looking at udmabuf too)
<pinchartl>
this is why libcamera requires v5.0 or newer
<robclark>
tomeu: cool, yeah, that makes sense.. otherwise you really need a couple seconds (and low enough replay overhead) to get cpufreq/gpufreq to settle down
xexaxo_ has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
Daanct12 has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<dcbaker>
kusma, airlied: I'm not seeing that test fail consistantly on lavapipe on the staging/21.2 branch. I can't seem to bisect it back to anything on the stable branch either: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/13313446
<dcbaker>
Do you have any suggestions about what to do about it?
heat has joined #dri-devel
achrisan has joined #dri-devel
jbarnes has quit []
jbarnes has joined #dri-devel
bcarvalho has joined #dri-devel
shfil has joined #dri-devel
cedric is now known as bluebugs
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #dri-devel
<kusma>
Add it to the skip list, perhaps?
heat has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
camus has quit []
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
jkrzyszt has quit [Ping timeout: 480 seconds]
APic has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
achrisan has quit []
achrisan has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
leandrohrb27 has joined #dri-devel
tomeu has quit [Quit: Ping timeout (120 seconds)]
leandrohrb2 has quit []
tomeu has joined #dri-devel
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
agners has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
markus has quit [Ping timeout: 480 seconds]
markus has joined #dri-devel
rsalvaterra_ has quit []
rsalvaterra has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
<shfil>
imirkin: imirkin_: can you also assign marge to these two?