simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
vliaskov has joined #dri-devel
<airlied>
tzimmermann: ack from me, getting rid of it ftw
<javierm>
mairacanal: your convert a DRM driver to rust LPC talk was awesome :)
<soreau>
tzimmermann: Does this mean anything for kernel options `nomodeset` and `driver.modeset=0`? Would the nomodeset cases try to use fbdev where it used to use UMS or what will happen?
<javierm>
soreau: it will use any driver that relies on the system provided framebuffer (e.g: efifb, vesafb, simpledrm)
dviola has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
itoral has quit [Remote host closed the connection]
<tzimmermann>
soreau, this change has no effect on nomodeset.
<tzimmermann>
airlied, thanks
cmichael has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
<sima>
tzimmermann, also ack from me
<sima>
tzimmermann, I guess just needs an ack from ppc maintainers for merging through drm-misc and I guess intel folks for the one i915 bit and then go land it all and celebrate :-)
<sima>
airlied, agd5f given all the agp disabling, I also wonder whether we shouldn't just nuke all that too?
<sima>
or do we need the drivers just to make sure agp mode is off?
<sima>
but I guess nuking the uapi is really the thing that matters
<emersion>
maybe it is, but if it isn't, please reply :P
<sima>
uh no
<emersion>
yeah, i think i remember something about… not doing this lol
<sima>
git doesn't realize it's the same patch, which means the 3-way merge gets extremely confused by the changed context and makes an absolute mess of it at merge time
<sima>
hwentlan__, agd5f ^^
<sima>
I'll reply on-list too
<emersion>
ty
<tzimmermann>
sima, thanks
<sima>
hwentlan__, we should have a patch to dim docs that any kind of cherry-picking is for maintainers only, somehow this came up a few times recently
<sima>
something like "Any non-linear actions (like cherry-picking, backmerges, merging topic branches and sending out pull requests) ..."
<sima>
if you could do the patch&mr?
<javierm>
sima: what about backports from let's say drm-misc-next to drm-misc-next-fixes ? Should we ask maintainers to do that if is needed?
<sima>
javierm, yeah, there's dim cherry-pick for that which helps with making sure you have dependencies and stuff like that
<sima>
and subsequent bugfixes, if there's any
<javierm>
sima: yes, I know. But was a question do your comment "any kind of cherry-picking is for maintainers only"
<sima>
javierm, yeah imo cherry-picking to multiple trees or from -fixes to -next is just wrong, and cherry-picking from -next to -fixes has enough warts that you should inform maintainers anyway, so might as well put it on their shoulders
<javierm>
sima: makes sense
<sima>
it's also why dim cherry-pick is documented under the "cmds for maintainer" section
<sima>
just that we have a few gaps in the docs where it's not clear enough
<javierm>
got it
<sima>
javierm, there's also some details like you must sob that cherry-pick and you really should put a full reference to the commit in -next in so it's less confusing for -next and cc: stable people
<sima>
*linux-next I mean
<javierm>
sima: but dim cherry-pick already does that IIRC
<sima>
yeah it takes care of all that
<sima>
but you need to know it exists :-)
<javierm>
but still makes sense for me that should be on maintainers' shoulders. They may decide that is OK to wait for the next release, or that should really be part of the -rc cycle, etc
<javierm>
so definitely seems to be something that is for them to weight in and decide the course of action
<sima>
it's more that cherry-picks tend to create really entertaining conflicts
<mairacanal>
javierm: thanks! now, i'm starting to work on upstreaming the dependencies of DRM (like Xarray)
<sima>
in practice at least
<javierm>
sima: yeah, and that's why maintainers can decide whether to cherr-pick to -fixes (and possibly cause a conflict) or just wait for the next release (if the fix is not critical or for a patch in this merge window, etc)
<javierm>
sima: anyway, just wondered if your comment also applied to cherry-picking fixes and why I asked. Thanks for the confirmation :)
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
yyds has joined #dri-devel
HaikuUser has joined #dri-devel
HaikuUser has quit []
hansg has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
Aura has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
hansg has joined #dri-devel
fluix_ is now known as fluix
agd5f has joined #dri-devel
<agd5f>
sima, AGP in amdgpu has nothing to do with traditional AGP. The driver uses uses the AGP aperture for direct access to system memory (without going through a GPU page table) as an optimization. That got broken with a recent rework, so we disabled it, but we did finally fix it.
<agd5f>
The on GPU AGP aperture just forwards requests directly to the bus
<agd5f>
that said, I don't object to getting rid of AGP in general
fxkamd has quit []
Peuc has quit [Quit: Peuc]
Peuc has joined #dri-devel
heat has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
macromorgan_ has quit []
macromorgan_ has joined #dri-devel
fab has quit [Quit: fab]
macromorgan_ has quit []
macromorgan has joined #dri-devel
<kusma>
Did someone force-push to main recently?
<kusma>
(mesa main, I mean)
<jenatali>
kusma: the Marge problem was being discussed in #freedesktop
<jenatali>
"oh, I should've check sooner: the error marge is giving ("these changes already exist in branch main") is actually correct, so this MR should be closed"
<agd5f>
airlied, sima any objections to me including Felix' revert in my -fixes PR today?
<sima>
agd5f, I'm still a bit confused since everyone is talking about the follow up in -next but the revert in -fixes, which is why I suggested to backport when actually needed
<sima>
but also meh, just send it :-)
<sima>
when/if actually needed
<sima>
(there's some pretty simple syntax that you can add to the cc: stable for the first patch that needs the revert so it's not really any more work than other cc: stable)
<sima>
airlied, ^^
<sima>
agd5f, oh I've just seen christian's reply
yyds has quit [Remote host closed the connection]
<sima>
agd5f, a-b: me for the revert in your -fixes pull today, that's very much a reason I can get behind :-P
flom84 has quit [Quit: Leaving]
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
kts has joined #dri-devel
hansg has quit [Quit: Leaving]
idr has joined #dri-devel
<idr>
Ugh. So... my MR failed debian-testing-asan. As far as I can tell... it detects a leak in fclose called from a unit test. :facepalm:
donaldrobson has quit [Ping timeout: 480 seconds]
<idr>
cmarcelo: Actually... the open_memstream(&my_string, ...) parameter has to be freed after the stream is closed.
<idr>
But asan blames fclose because... it had the last pointer to it? It seems like it should blame open_memstream. That would have made the real problem more obvious.
fxkamd has joined #dri-devel
rgallaispou has quit [Quit: Leaving.]
<bwidawsk>
melissawen: Any chance to look into modifiers for vkms?
<melissawen>
bwidawsk, yeah, forgot to get back with findings. So, VKMS already supports MOD_LINEAR since it's added by DRM by default.
<melissawen>
I also checked the IGT tests that use this modifier, and it's working as expected
<bwidawsk>
melissawen: hmm, I guess I need to dig more than as to why I get back INVALID
<bwidawsk>
thanks for looking
<melissawen>
the only thing I found is that VKMS is not rejecting the MOD_INVALID properly
<bwidawsk>
well, it's some gbm/vkms combo here, and I just sort of guessed it was vkms' fault
<melissawen>
do you think it would be the case for your gbm case? a bad handling of MOD_INVALID from vkms?
<melissawen>
I'm not used to gbm, so I'd need much more time to debugging the stack.
hansg has joined #dri-devel
<bwidawsk>
no, iirc it uses the regular bo_alloc without modifiers because modifiers2 interface isn't supported
<melissawen>
let me know if you have any news from your side. I'll try to find a time to investigate the bad management of MOD_INVALID anyway
<bwidawsk>
so this falls back to MOD_INVALID
<bwidawsk>
melissawen: okay, I'll let you know if I find anything new
<bwidawsk>
Is there a way to limit drm.debug to only a specific card?
<emersion>
melissawen: KMS drivers can't indicate that INVALID is not supported
<emersion>
IOW, INVALID must always be supported
<emersion>
in general, drivers assume LINEAR in trhat case
DodoGTA has quit [Quit: DodoGTA]
<daniels>
idr: asan blames fclose because, unless you explicitly flush, the file only gets flushed on close
DodoGTA has joined #dri-devel
<bwidawsk>
emersion: so I guess the ultimate question is should I able to allocate a LINEAR buffer from vkms
<bwidawsk>
because it doesn't seem to work (for reasons I haven't debugged)
<zamundaaa[m]>
bwidawsk: it's not vkms, llvmpipe is the issue
vliaskov has quit [Remote host closed the connection]
<bwidawsk>
zamundaaa[m]: in my case I am not using llvmpipe
<bwidawsk>
this is with a pixman renderer
<zamundaaa[m]>
Okay, that's unrelated then
<bwidawsk>
it /seems/ like it should be an easy thing to fix
<bwidawsk>
but I also vowed not to write any more kernel patches, so it's a stalemate
bmodem has quit [Ping timeout: 480 seconds]
<melissawen>
emersion, I can inspect better but I don't think the missing CAP is the case, since when running IGT kms_addfb_basic VKMS always pass the `igt_require_fb_modifiers` requirement
martin19 has quit [Read error: Connection reset by peer]
luben has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
airlied has quit [Ping timeout: 480 seconds]
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
martin19 has joined #dri-devel
airlied has joined #dri-devel
<illwieckz>
Do someone knows a bit about glvnd? What problems is it trying to solve? Unless we do something wrong with the Dæmon game engine, accumulated experience over two years is that building an OpenGL application with GLVND ABI instead of LEGACY one 1. breaks compatibility with legacy Nvidia drivers, 2. breaks compatibility with AMD OGLP driver, 3. breaks compatibility with Wayland with Prime…
<illwieckz>
Is glvnd expected to be backward compatible and all of these problems are bugs, or is it considered OK that maybe only current Nvidia drivers on Xorg is expected to work and we are just lucky if current Mesa drivers are compatible with it on Xorg too ?
<Kayden>
so there are two aspects to glvnd
<Kayden>
first is just the new vendor neutral dispatch library. glvnd provides libGL.so, and it loads the vendor drivers (libGLX_mesa.so, libEGL_mesa.so, libGLX_nvidia.so, etc)
<Kayden>
that should be fully backwards compatible, and is meant as a way to let you parallel install mesa drivers, nvidia proprietary drivers, fglrx (not that that's a thing anymore) & whatever else
<Kayden>
as long as you're linking against libGL.so it should not matter whether it's glvnd or mesa or nvidia directly
<illwieckz>
I guess I never seen backward compatibility to be working, then
<Kayden>
but it sounds like you may be running into the second aspect
<Kayden>
which is...glvnd decided to define a new ABI for OpenGL, libOpenGL.so
<Kayden>
which is not backwards compatible
<illwieckz>
yes, that's my concern
<Kayden>
IIRC it only has OpenGL core profile support. It also does not contain GLX
<Kayden>
libGL has both OpenGL core, OpenGL compatibility (legacy), and GLX
<Kayden>
which is awkward if you're trying to do, say, EGL only, on a non-X11 windowing environment
<illwieckz>
so, does it mean that I can build an app with -DOpenGL_GL_PREFERENCE=LEGACY
<illwieckz>
but use a glvnd libGL.so ?
<Kayden>
I've not heard of that flag, but yes, it should be possible
<Kayden>
you shouldn't have to target libOpenGL.so as an app / engine author unless you -want- to
<illwieckz>
that's the cmake flag for selecting either LEGACY ABI or GLVND ABI
airlied has quit [Ping timeout: 480 seconds]
<illwieckz>
ok, good to know
<illwieckz>
because CMake defaults to -DOpenGL_GL_PREFERENCE=GLVND
<illwieckz>
even if the developer has no idea this will break backward compatibility if I understand it right