fab has quit [Read error: Connection reset by peer]
frieder has quit [Ping timeout: 480 seconds]
majosa has joined #dri-devel
<mripard>
lumag: did you end up having the time to look into the msm legacy_cursor removal regressions?
<mripard>
we have a bad bug on vc4 that is caused by it, and I was ping'd about it again
frieder has joined #dri-devel
CME has quit [Read error: Connection reset by peer]
oneforall2 has quit [Read error: Connection reset by peer]
oneforall2 has joined #dri-devel
CME has joined #dri-devel
majosa has quit []
vliaskov has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
clamor has quit [Ping timeout: 480 seconds]
clamor has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
parthiban has quit [Ping timeout: 480 seconds]
parthiban has joined #dri-devel
pcercuei has joined #dri-devel
Surkow|laptop has joined #dri-devel
YuGiOhJCJ has quit []
siak_ has joined #dri-devel
siak has quit [Remote host closed the connection]
guludo has joined #dri-devel
haaninjo has joined #dri-devel
agd5f has joined #dri-devel
nerdopolis has joined #dri-devel
agd5f has quit []
agd5f has joined #dri-devel
<lumag>
mripard: no...
<lumag>
mripard: is it about dropping legacy_cursor interface and only using planes for it?
JLP has joined #dri-devel
JLP_ has quit [Ping timeout: 480 seconds]
<mripard>
lumag: yes
epoch101 has joined #dri-devel
<lumag>
mripard: do you have a pointer to VC4 issue?
alarumbe has joined #dri-devel
JLP has quit [Read error: Connection reset by peer]
JLP has joined #dri-devel
<lumag>
mripard: I'm asking, because I remember an AI/TODO on me to drop legacy cursor from the MDP5 driver, but I don't have anything else related in my memory.
digetx is now known as Guest22951
digetx has joined #dri-devel
digetx has quit [Read error: Connection reset by peer]
<mripard>
lumag: but tl; dr: if you move the cursor along the edges of the display, you get a corrupted frame that looks pretty much random
digetx has joined #dri-devel
kzd has joined #dri-devel
davispuh has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
digetx is now known as Guest22954
digetx has joined #dri-devel
Guest22954 has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
Peuc has joined #dri-devel
warpme has quit []
clamor has quit [Read error: Connection reset by peer]
clamor has joined #dri-devel
helmhotz_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
bolson has joined #dri-devel
kts has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
phryk has joined #dri-devel
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
<phryk>
Heya, I'm (slowly) getting into low level graphics programming on *nix and am considering adding inline docs to some things so people doing the same in the future hopefully have to struggle less than me. Is there an inline documentation tool already used for freedesktop projects (ideally already used in the CI pipeline)?
<phryk>
pq: for docs to be available through LSP they will have to be written inline tho, or am i misunderstanding something?
<pq>
No, there are just several kinds of docs. Some projects integrate inline docs with other docs.
<pq>
Targeting LSP is a good detail.
<pq>
..to mention.
<pq>
and which exact API you want to document
<phryk>
right, from other languages i'm used to, inline docs for stuff you can access from LSP and docs directory for "full" documentation including things like architectural overviews.
<pinchartl>
in my experience, when you start with no documentation at all, high-level documentation that explains the architecture and overall operation is more important than detailed API documentation. the latter is what LSP usually needs, and that can come in a second step if your time is limited
<phryk>
well, first off GBM becaus that's the thing i have to figure out currently. after that probably libdrm because the lack of good up-to-date docs there was a major source of frustration for me.^^
<phryk>
pinchartl: yeah, but i'm only slowly getting to know it. i simply do not have the knowledge to write the higher-level overviews – but i can work things out function by function.
<pinchartl>
phryk: you'll need to understand the overall architecture to use it properly, so you'll get there :-)
<phryk>
pinchartl: yeah, *after* i worked myself through the actual functions. if this was a project i'd written from scratch, i'd definitely start with the high-level overview because specific APIs are more likely to change. :)
<pq>
...mainly look at kernel docs to understand how stuff works, in order to write the API docs
Duke`` has joined #dri-devel
parthiban has quit [Remote host closed the connection]
parthiban has joined #dri-devel
frieder has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
siak_ has quit []
<phryk>
the mesa repo seems to contain references to doxygen and hawkmoth (and sphinx). docs/codingstyle.rst only references doxygen, but it's rst, which implies sphinx which seems to imply hawkmoth… so would i write inline docs as rst or doxygen notation?
<zmike>
jenatali: any plans to address deprecation warnings?
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
jamesjones1 has quit [Ping timeout: 480 seconds]
<jenatali>
zmike: eventually, sure
<jenatali>
Is there an urgent need for it?
<zmike>
well I'm hoping I can delete the pipe surface interfaces in finite time
<zmike>
and everyone who drags their feet on this makes that impossible
<zmike>
as it is we have a number of effectively unmaintained drivers that I guess I'll have to refactor since somehow we are not able to eject them from the tree
<jenatali>
zmike: make it a local function and call it directly within the driver? I.e. really copy and paste the macro code instead of having the preprocessor do it?
<jenatali>
That's what I'd do in the short term anyway
<zmike>
I'm talking about util_framebuffer_init
<zmike>
which is not a macro
<jenatali>
Oh right, I was thinking it was. My point still stands though, give the lagging drivers a copy of that with a specialized function call
<zmike>
that's not really how things work though
<zmike>
the point is to remove pipe_surface as an object
<zmike>
so there is no way to give drivers a copy since they would then have to continue using that interface
<jenatali>
Yeah ok I see what you're getting at
<jenatali>
I'll try to get to it this week
<zmike>
you could go the nouveau route and: copy the function into your driver, make the driver surface functions public, and then call them directly
<zmike>
but that kinda misses the point if you are not a dead driver
<zmike>
thx
<jenatali>
I mean that's more or less how our driver would have to work though I think?
<jenatali>
I dunno, need to take a closer look
<zmike>
I was able to extend an existing cache I had for image view objects for this case, but that might be non-trivial if you don't already have something like that in place
epoch101 has joined #dri-devel
<jenatali>
Yeah I don't
<zmike>
yeah okay so maybe you need to go the nouveau route for now
<jenatali>
Each surface allocated a unique descriptor
epoch101_ has quit [Ping timeout: 480 seconds]
<jenatali>
Maybe I'll see if I can unify with nouveau and do a u_surface instead of pipe_surface
fab has quit [Ping timeout: 480 seconds]
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
epoch101_ has quit [Read error: Connection reset by peer]
epoch101 has joined #dri-devel
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
pjakobsson has quit [Remote host closed the connection]
ryanneph has joined #dri-devel
<mattst88>
zmike: emil velikov has been the closest thing to a maintainer we have for waffle
<zmike>
not sure how I could split this differently to be more reviewable
krushia has quit [Quit: Konversation germinated!]
kasper93_ has joined #dri-devel
kasper93 is now known as Guest22965
kasper93_ is now known as kasper93
jamesjones1 is now known as jamesjones
croissant_ has quit []
croissant has joined #dri-devel
Guest22965 has quit [Ping timeout: 480 seconds]
helmhotz_ has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
rasterman has quit [Quit: Gettin' stinky!]
Guest22963 has quit [Ping timeout: 480 seconds]
<dcbaker>
dwfreed: ^
<Sachiel>
matrix spam? I'm seeing nothing
<dcbaker>
yeah, matrix spammer that are apparently unregistered, but I see them across a bunch of different channels
<HdkR>
+M is nice.
archon has quit [Remote host closed the connection]
clamor has joined #dri-devel
parthiban has quit [Remote host closed the connection]
jessica_24 has joined #dri-devel
olivial has quit [Read error: Connection reset by peer]
olivial has joined #dri-devel
FANTOM has quit [Read error: Connection reset by peer]
<majosa>
Hi, chat. I would like ask if anyone knows about problems with fragment interpolation being lower precission on AMD drivers (RADV for example) compared other implementation like Nvidia or Llvmpipe ones. Thanks for your attention
fab_ has joined #dri-devel
fab_ is now known as Guest22976
clamor has quit [Remote host closed the connection]
majosa_ has joined #dri-devel
majosa has quit [Ping timeout: 480 seconds]
mmarchini_ has left #dri-devel [#dri-devel]
<anholt>
daniels: I'm working on getting a common closed shader-db set up, with permissions matching gfx-ci/tracie/traces-db-private, and I was thinking of making a group for gfx-ci/private-access to make the membership common between the two. But I suspect I need to be an owner of gfx-ci in order to make a subgroup.
<anholt>
(I was going to put the group under mesa/, but that means that all mesa members get access. Which I think would be good for the project, but it's not what we decided when we did traces-db-private)
mmarchini has joined #dri-devel
<gfxstrand>
Is there a good/easy way in kernel space to go from a client pointer to the BO and offset that it maps to?
iive has joined #dri-devel
<airlied>
somewhere in the vma manager probably
<airlied>
drm_vma_offset_lookup_locked
<gfxstrand>
But that's in offset space, not the client's address space
<airlied>
you should be able to work it back from address space
<airlied>
DRM_FILE_PAGE_OFFSET_START?
* airlied
is pre caffiene, so I might be missing a step here
<airlied>
oh yeah that is just the fd, you'd have to probably lookup the vma offset in mm
<gfxstrand>
Yeah
<gfxstrand>
I don't think I want to descend into that madness
<airlied>
gfxstrand: I think find_vma would do it
<airlied>
then just check it's a gem va, and grab the private data
Guest22976 has quit []
<gfxstrand>
I think I'm just going to give up on my crazy arm cache flushing plan. :cry:
jewins has joined #dri-devel
<HdkR>
What's wrong with arm cache flushing?
<HdkR>
Aside from the mess of 32-bit, but that can be ignored :P
haaninjo has quit [Quit: Ex-Chat]
<sima>
yeah find_vma + upcast should do this trick, and the upcast should be generic if you look at the vma_ops->open/close hooks
<gfxstrand>
HdkR: Sadly, 32-bit can't be ignored. :'(
<HdkR>
Wha
<zmike>
can't it tho
<gfxstrand>
"What's wrong with XYZ? Except the part that makes it hard"
<gfxstrand>
That's some real math professor "the details are left to the reader" energy right there. :P
<sima>
I thought even on 32bit arm cpu it's fairly reasonable on v7
<gfxstrand>
No
<sima>
at least we vendored a bunch in drm_cache.c
<gfxstrand>
It's reasonable on ARMv8 but only for 64-bit userspace
<HdkR>
cache clear instructions aren't available in userspace in 32-bit arm.
<sima>
oh yeah that part is funny
<HdkR>
So you need to do cache clears in kernelspace, which is spicy.
<sima>
why spicy? I mean aside from the entire part that it's a syscall
<gfxstrand>
sima: You say "we vendeored a bunch in drm_cache.c" but then that's only for x86 and a bit of ppc
<sima>
hm right, that patch never landed
<HdkR>
buffer_storage coherency ensuring visibility on 32-bit is definitely where you don't want a syscall :D
<sima>
it did float around
<sima>
might only be vendored in msm perhaps, robclark should know
<gfxstrand>
Writing the panfrost patch shouldn't be hard. And I'll do roughly the same thing in nouveau.
<gfxstrand>
It's just a giant PITA
<sima>
yeah robclark defo had patches for drm_cache.c once
<gfxstrand>
And it's very unclear what (if any) safety requirements there should be. Presumably Arm made cache ops privileged for a reason so I shouldn't just add a Linux cache flush syscall. (Not that I'd want to spend a year of my life arguing with core MM about it.)
<sima>
oh userspace cache flushing just makes all the nasty attacks easier, from rowhammer to all the spectre stuff
<HdkR>
But also arm64 can do it from userspace, so..huh?
<gfxstrand>
I mean, it makes sense that Arm doesn't give you a proper invalidate from userspace
<sima>
I don't think there's anything more, we've exposed fine-grained flushing for bo since forever
<gfxstrand>
On AArch64, it does a flush+invalidate when run from EL0
<gfxstrand>
Which is fine
<sima>
well, that's the same fun for gpu invalidates we have with xe
<HdkR>
ah, the pure invalidate without flush? yea...
<gfxstrand>
Pure invalidate without flush is definitely unsafe
<gfxstrand>
x86 clflush is always flush+invalidate
<sima>
either the pte caching bits enforce the flush (or snoop) or you need to flush it all before you hand the memory to userspace
<gfxstrand>
But Arm has separate invalidate and flush
<HdkR>
Windows even blocks some of these on arm64 in addition to what Linux allows.
<sima>
after that the pure invalidate is just a very funny write
Duke`` has quit [Ping timeout: 480 seconds]
<sima>
so yeah if you want to expose the raw invalidate you need to flush your bo on alloc (or at least once before the first pure invalidate)
jewins has quit [Ping timeout: 480 seconds]
<pinchartl>
zamundaaa[m]: I was thinking of rejecting commits with global alpha + alpha channel. I'm worried it would break compositors though :/
<pinchartl>
(sorry, didn't see your reply as the matrix bridge quoted a matrix user name)
sima has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Read error: Connection reset by peer]
<gfxstrand>
I don't want to expose pure invalidate. But I'm also not sure if I accidentally did. I'm fine with flush and flush+inval (which is what I get from userspace on AArch64)
<HdkR>
All the operations that matter are what. Fence (all, store, load), flush, flush+invalidate?
<HdkR>
and flush+invalidate with optional instruction barrier?
<HdkR>
If I'm remembering x86 and ARM mappings.
<HdkR>
and then for device to CPU coherency for non-coherent systems, you'd want in the kernel space an invalidate after job completion?
<HdkR>
Coherency domains suck :D
<zamundaaa[m]>
pinchartl: any compositor that does more than the bare minimum with KMS needs to be able to handle that
<zamundaaa[m]>
And fall back to the primary-plane-only configuration