<siddh>
I've been getting dmarc error messages on posting to dri-devel. I don't think that should have been the case as there seems to be no change to message. Can the mail admin look at it?
<siddh>
LKML works fine
lemonzest has joined #dri-devel
aravind has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<airlied>
zmike: arrgh, my hate for pipeline libraries is now a lot larger :-P and also you need to ref count betterer :-P
ice9 has joined #dri-devel
agd5f_ has joined #dri-devel
Danct12 has quit [Quit: Quitting]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
rmckeever has quit [Quit: Leaving]
agd5f has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Duke`` has joined #dri-devel
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
kts has joined #dri-devel
tzimmermann has joined #dri-devel
ahajda has joined #dri-devel
BobBeck has quit [Quit: Ping timeout (120 seconds)]
padovan has quit []
sergi has quit [Quit: Ping timeout (120 seconds)]
opotin has quit []
italove has quit [Quit: Ping timeout (120 seconds)]
leandrohrb has quit []
opotin has joined #dri-devel
BobBeck has joined #dri-devel
italove has joined #dri-devel
bgs has quit [Remote host closed the connection]
sergi has joined #dri-devel
padovan has joined #dri-devel
leandrohrb has joined #dri-devel
frieder has joined #dri-devel
fab has quit [Quit: fab]
Leopold has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
aravind has quit [Remote host closed the connection]
cphealy has quit [Read error: Connection reset by peer]
cphealy has joined #dri-devel
<daniels>
eric_engestrom: dockerd is dead again :(
rasterman has joined #dri-devel
<tanty>
daniels: I saw eric_engestrom already took care. For any RPi CI related issue, he is your default contact at Igalia.
MajorBiscuit has quit [Read error: Connection reset by peer]
<daniels>
tanty: thanks - do you mean that dockerd was already fixed in the last 3h?
nchery has joined #dri-devel
tursulin has joined #dri-devel
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest1061
swalker__ has joined #dri-devel
Didgy has joined #dri-devel
Guest1061 has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
MajorBiscuit has joined #dri-devel
maxzor has joined #dri-devel
chema_ has joined #dri-devel
chema_ has quit []
txenoo has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.6]
pcercuei has joined #dri-devel
chema has joined #dri-devel
<chema>
daniels: Rpi CI should be working fine with only half of the runners, we have disabled the system having issues to run some test on the disk used in the system.
<javierm>
tzimmermann: exactly, so for !x86 it will always be 0 and sysfb_disable() won't ever be called if we check if (primary)
<javierm>
danvet: haha
<javierm>
I don't know... I think that my opinion is still that this should be done unconditionally
<javierm>
if a driver calls remove_conflicting_framebuffers(), is because it will set-up its own fbdev and so fbcon should bind to that instead of efifb/simplefb/simpledrm
<danvet>
yeah but if the igpd isn't actually connected to a screen the user looks at
<danvet>
but the boot-vga devices is
<danvet>
then this breaks something
<danvet>
and we get a bug report
<javierm>
danvet: I see. So when the igpu isn't connected to the screen? Is that a BIOS setup or ?
<javierm>
and shouldn't the igpu driver check that and not attempt to remove conflicting framebuffers and create an fbdev ?
<danvet>
uh that's what we have the pci version for
<danvet>
so it can internally check this
<danvet>
with the primary thing
<javierm>
danvet: ahh, I see...
<javierm>
why there is both a vga arbitrier and vga_switcheroo. I think that need to understand how all this works first
<danvet>
ah
<danvet>
do you want to be entertained?
<danvet>
they're entirely different things really
<danvet>
vga_switcheroo is more like gpu_switcheroo
<danvet>
also switcheroo only has a debugfs interfaces and some fundamental locking issue at the design level :-)
<javierm>
danvet: I see. So the vgaarb is the only thing that is used without user intervention then?
<danvet>
not really
<danvet>
it's more like was
<danvet>
back when userspace modesetting was all the rage
devilhorns has joined #dri-devel
<danvet>
and userspace drivers needed legacy vga to be routed correctly
<danvet>
nowadays it's really just informational only, so userspace knows which pci device is the boot one
<danvet>
and can smash the login screen on the right display
<javierm>
everything in gfx is a rabbit hole and leads to a history lesson :)
apinheiro has joined #dri-devel
devilhorns has quit []
devilhorns has joined #dri-devel
<danvet>
argh
<danvet>
I think I overlooked something
<javierm>
danvet: right now the primary in aperture_remove_conflicting_pci_devices() is only used to remove the vga16 device, that hardcodes the base to VGA_FB_PHYS_BASE
<danvet>
yeah I think we need to shuffle things a bit more
Didgy has quit [Ping timeout: 480 seconds]
<danvet>
javierm, I have an idea, but it's like an entire patch series
<danvet>
with a pile of cleanups
<danvet>
but since all we broke is the nv blob, I think that's ok :-)
<danvet>
lunch time here now, I'll simmer this while I'm cooking some stuff
<javierm>
danvet: Ok, enjoy!
Haaninjo has joined #dri-devel
<danvet>
it's always a good day when you end up patching fbdev drivers in staging
<javierm>
heh
maxzor has joined #dri-devel
wv has quit [Ping timeout: 480 seconds]
<mareko>
alyssa: we split GL into 2 threads: GL frontend (glthread) and the driver (TC), radeonsi also has a kernel submission thread to hide kernel overhead, so in total we could get 400% CPU load
<javierm>
IOW, the i915 shouldn't attempt to remove conflicting frambuffers (and disable sysfb) if is not connected to the display and doesn't setup an emulated fbdev
kts has joined #dri-devel
<javierm>
tzimmermann: having said that, I agree with you that checking for primary properly in x86 makes sense
<tzimmermann>
javierm, yeah
<tzimmermann>
in the bug report, there was an amd user as well
gbelgurr has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: maybe AMD does something similar?
<javierm>
that's what lead me to type the patch above
<danvet>
javierm, yeah that might be another one
<danvet>
otoh if we wire through the boot vga stuff correctly, it shouldn't be needed
elongbug has quit [Remote host closed the connection]
<danvet>
and it's imo better to not push this kind of stuff to drivers
elongbug has joined #dri-devel
<tzimmermann>
danvet, yeah with the vga-switcheroo. do we really need that?
<danvet>
iow the series I'm working on entirely removes primary from all aperture helpers, and tries to dtrt instead just be default
<javierm>
danvet: yeah, makes sense. But the good thing is that this could be backported to stable
<danvet>
javierm, tbh I'm not super enthusiastic about backporting fixes for the nv blob :-)
<javierm>
because the patch is trivial. But up to you really, I'm happy to just ignore the nvidia blog :)
<javierm>
*blob
<danvet>
I mean if aaron wants the upstream fix backported (assuming it work all) then he can ...
<javierm>
tzimmermann: the AMD driver is really complex :) and since danvet doesn't want to push these to drivers, I stopped looking
<danvet>
what's the switcheroo to do here again?
<danvet>
javierm, I'm lost on your comment
<javierm>
danvet: which one? I mean that you don't want drivers to check if display is enabled to decide whether to call to drm remove conflicting framebuffers
<javierm>
e.g: the i915 patch I shared above and prefer to handle properly in the aperture core
<tzimmermann>
aaron, the nvidia dev, wants to use its own emulated console. nice
<javierm>
tzimmermann: yup, he said that's a work around but it's really to correct thing to do :)
<javierm>
*the
<tzimmermann>
yeah, my thoughts
<tzimmermann>
the fbdev emulation is the solution to a nubmer of problems
<javierm>
danvet: because I was looking if a similar patch was needed for the amdgpu driver
<danvet>
javierm, oh there's an amdgpu bug report for this too?
<javierm>
danvet: ah, I see. Couldn't follow that BZ in details, too many comments
<shadeslayer>
mareko: At least the iris commit hasn't been Rb'd on the util cleanup yet and I know one of the traces fails on freedreno
Didgy has joined #dri-devel
<shadeslayer>
so it needs one last round of fixes
gbelgurr has joined #dri-devel
<javierm>
danvet: so to recap, I shouldn't post that i915 patch then and you have an idea on how to properly check the primary VGA device in the aperture helpers?
<javierm>
which should be more like a refactoring / patch series but we are OK for this to not be backported because the nv blob should had created its own fbdev anyways
<danvet>
javierm, yeah I think I have an idea
<danvet>
whether it's a good one is a different question :-)
<javierm>
danvet: Ok :)
<javierm>
then I'll leave it in your capable hands and go out for lunch
<danvet>
enjoy!
<danvet>
mine is still simmering, but should be ready any minute
* danvet
rather later than usual ...
<APic>
Phew
<APic>
Nobody kicked me out
* APic
thanks to You all 😌
<APic>
s/to //
* APic
really made a bad Mistake yesterday. So sorry.
jkrzyszt has quit [Remote host closed the connection]
Didgy has quit []
Didgy has joined #dri-devel
<Venemo>
anyone planning to go to FOSDEM this year?
<DavidHeidelberg[m]>
Venemo: me and myself + also daniels what I'm aware of
<Venemo>
nice
<Venemo>
I wanted to go too, but I'm on the fence. they don't have a graphics devroom anymore and the technical talks this year don't seem to be too interesting
Didgy has quit [Ping timeout: 480 seconds]
<daniels>
not that you can ever get into the talks anyway ...
<Venemo>
lol
<shadeslayer>
DavidHeidelberg[m]: hey, so I was trying out your branch, but looks like the coredump doesn't like my x86 system :(
<DavidHeidelberg[m]>
It always fails if you put the core dump file before loading the rootfs. Sadly all HOWTO are usually using core dump as a gdb argument
<DavidHeidelberg[m]>
Also Hi :)
<shadeslayer>
oh I didn't see the docs
<shadeslayer>
thanks!
Didgy has joined #dri-devel
itoral has quit [Remote host closed the connection]
Didgy has quit []
<siddh>
Sorry for being offtopic, but why do sometimes people refer to them in third person? For eg. "* user <the message>". Is it auto replacement of "I", and if so, why?
<DavidHeidelberg[m]>
shadeslayer: after you finish debugging if you find time, please give me feedback (most interested in the doc part, if it's well comprehensible etc.)
<DavidHeidelberg[m]>
Siddh: it's use of command `/me`
<siddh>
oh
<siddh>
thanks for informing!
macromorgan has joined #dri-devel
zarast has quit [Read error: Connection reset by peer]
<shadeslayer>
DavidHeidelberg[m]: I'm looking at the "Root filesystem, link located at the beginning of the failed job." instruction and I don't see a link
<shadeslayer>
DavidHeidelberg[m]: getting closer, though I see no apitrace dir in my container or the mesa tar I downloaded, for this instruction : gdb-multiarch ./apitrace/build/eglretrace
<DavidHeidelberg[m]>
shadeslayer: mesa tar doesn't have it; it's in the rootfs (container)
<shadeslayer>
ahh I see it now
<shadeslayer>
hm warning: Can't open file /builds/shadeslayer/mesa/install/lib/libgbm.so.1.0.0 during file-backed mapping note processing
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ahajda has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
<shadeslayer>
I still don't have symbols in the bt
Akari has quit [Quit: segmentation fault (core dumped)]
<DavidHeidelberg[m]>
shadeslayer: you did run the `find ./install/lib/ -name "*.so*" -print -exec ln debug.dwp '{}'.dwp ';'` ?
<shadeslayer>
yeah
<DavidHeidelberg[m]>
in general it look ok, if you run bt, what does it produces?
<siddh>
<macromorgan> "so I hate to keep asking for..." <- Since fxn signatures are same, If CONFIG_OF is not set, then it will result in redefinition (you have a definition in drm_of.h, then also in drm_of.c), which is what is happening. GCC tells to add static (like static inline int in cases above), and that I guess is so that the definition with ERR_PTR stays only in header file and that is included everywhere.
<siddh>
So in the else case in header file, it should be like static inline struct mipi_dsi_host, or static inline int mipi_dsi_host with return being _EINVAL.
<siddh>
s/_E/-E
<siddh>
Probably return type being int would be better in case static doesn't affect signature.
<shadeslayer>
I think it can't find the msm driver? warning: Can't open file /builds/shadeslayer/mesa/install/lib/dri/msm_dri.so during file-backed mapping note processing
<shadeslayer>
DavidHeidelberg[m]: ahh works now :)
<DavidHeidelberg[m]>
🎊
<shadeslayer>
DavidHeidelberg[m]: though I think the url is wrong, it's uploaded to mesa-arm64.tar.zst-unstripped.tar.zst
<DavidHeidelberg[m]>
shadeslayer: let me fix that :)
ybogdano has joined #dri-devel
zehortigoza has joined #dri-devel
<shadeslayer>
s,url,filename, but hey, it works :)
fab has quit [Quit: fab]
<DavidHeidelberg[m]>
shadeslayer: ugly bash variable got updated with .tar.zst prefix and re-used later. Fixed. Now the docs.
<tzimmermann>
mripard, done for now
<shadeslayer>
DavidHeidelberg[m]: I think the arguments are optimized out though :(
<shadeslayer>
warning: Could not find DWO CU src/gallium/drivers/freedreno/libfreedreno.a.p/a5xx_fd5_emit.c.dwo(0x2e19b5a9c0022477) [in DWP file msm_dri.so.dwp] referenced by CU at offset 0xc9ac [in module ./install/lib/dri/msm_dri.so]
<shadeslayer>
#5 0x0000ffffb4dd099c in u_upload_alloc () at ../src/gallium/auxiliary/util/u_inlines.h:89
<DavidHeidelberg[m]>
but with full debug it would be too slow to execute test (I assume)
maxzor has quit [Read error: Connection reset by peer]
<shadeslayer>
yeah, I mean, it's good enough to narrow down things down for me for now, but just thought I'd point it out :)
fab has joined #dri-devel
<DavidHeidelberg[m]>
shadeslayer: .gitlab-ci/build/gitlab-ci.yml : 383 to debug should be enough, but won't be applicable for flakes :(
<danvet>
javierm, sent out my nice little tour through a few drivers :-)
dcz_ has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
ybogdano has joined #dri-devel
kxkamil has quit []
<mripard>
tzimmermann: awesome, thanks
kts has quit [Quit: Leaving]
alyssa has left #dri-devel [#dri-devel]
<macromorgan>
siddh: thank you, that appears to fix all the errors
<siddh>
np :)
<macromorgan>
v9 inbound once I test the change... I'll get it right eventually...
Duke`` has joined #dri-devel
<javierm>
danvet: hmm, I don't think we can merge patch #11 without breaking one of the bug reported...
<javierm>
I'll comment on the ML
Cyrinux has quit []
jkrzyszt has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Cyrinux has joined #dri-devel
kxkamil has joined #dri-devel
<danvet>
javierm, hm
srslypascal is now known as Guest1087
<javierm>
danvet: ah, no I misread and thought you were moving the sysfb_disable() call but tzimmermann pointed out that you kept the other one too
srslypascal has joined #dri-devel
Guest1087 has quit [Ping timeout: 480 seconds]
<danvet>
javierm, yeah for everything !pci I think we can safely assume that either a) no other gpu involved (I should clarify that panels over spi and similar wont participate in this so wont cause a problem) or b) really old vga/mga stuff that goes direct to console driver and bypass all this
<danvet>
I need to clarify the commit message more I just realized, forgot a few thoughts I had while cooking
<javierm>
danvet: panels over spi et al won't be a problem because those drivers don't call drm_aperture_remove_conflicting_framebuffers()
<javierm>
same for render only GPU drivers
<dj-death>
do NIR expert know how to make uint computations?
<dj-death>
I have some operations with a 0xb0000000 that gets turned into another number, assuming that it's an int vs an unsigned int
<danvet>
javierm, yeah but I forgot to put that into the commit message
<javierm>
danvet: right
nroberts has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<cwabbott>
dj-death: you're going to need to give more context for someone to help you
<jenatali>
dj-death: What operations?
<cwabbott>
NIR doesn't have unsigned/signed integers in its type system, it's the operation (e.g. ilt vs ult) which determines the signedness
<javierm>
danvet: r-b patch #11. I disagree with tzimmermann that we should make aperture_detach_devices() aware of primary, it's much easier to understand and leads to simpler code by duplicating the call as you did IMO
<cwabbott>
values only have a bitsize and number of channels
<javierm>
danvet: besides what you mention, that will be called for each PCI BAR but only once will be a no-op
<danvet>
javierm, one thing I noticed ... nothing in aperture.c uses @name
<danvet>
not sure how that happened or whether that's a problem for debugging stuff
<javierm>
danvet: yup, I noticed that too and was going to suggest to add a cleanup
<javierm>
danvet: I think that was used for debugging at some point but that got removed at some point
<danvet>
javierm, you mean like drop it?
<javierm>
danvet: yeah
<danvet>
it feels like it's something we should have a debug printk for tbh
<danvet>
but not sure where we lost that
<javierm>
danvet: I think we lost because at some point had the previous driver name and said something like "switching from foo to bar"
<javierm>
danvet: but yeah, something like "name asks for conflicting drivers with aperture base + size to be removed" as debug printout makes sense
<danvet>
javierm, could even pretty print the device now that we have that
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
<javierm>
danvet: right, specially since that function will be only for pdev now, so we could pass that instead of base + size
<javierm>
in the past just shared between pdev and pci_dev but you decoupled that in patch #11
<javierm>
*was shared
<javierm>
danvet: which would be more consistent because drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const struct drm_driver *req_driver) but
<javierm>
that could be drm_aperture_remove_conflicting_framebuffers(struct platform_device *pdev, const struct drm_driver *req_driver)
djbw has joined #dri-devel
alanc has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
<danvet>
javierm, I had a moment rn because I read pdev and thought what are you mixing up with pci and not using the pci functions
<danvet>
then spotted the platform_dev
<danvet>
maybe throwing a platform in there can't hurt, not sure
<javierm>
danvet: just for consistency and to allow the pretty name that you mentioned
dcz_ has joined #dri-devel
swalker__ has quit []
<javierm>
danvet: in any case all can be done later, I think your series are the way to go (if ast and others work with the helper and don't need to open code it)
<javierm>
danvet: thanks for taking a look to that!
<javierm>
and sorry for sending you on a trip down the memory lane again :P
<dj-death>
cwabbott: thanks, I'm seeing a nir_isub(some_value, 0xb8000000) being turned into a nir_iadd(some_value, 0x38000000)
<dj-death>
cwabbott: maybe it's a backend thing :/
<dj-death>
no sorry, turned into nir_iadd(some_value, 0x48000000)
<anholt>
NIR_DEBUG=print and see where it shows up?
<pendingchaos>
I think those two instructions do the same thing
<pendingchaos>
opt_algebraic unconditionally does this to all subtractions
<javierm>
danvet: so I think aperture_detach_devices() should get the name and then print what device is detached due conflicting with what driver
<danvet>
yeah maybe
pallavim__ has joined #dri-devel
<javierm>
danvet: anyways, I can type a patch on top of your series once it lands
tzimmermann has quit [Quit: Leaving]
junaid has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
frieder has quit [Remote host closed the connection]
the_sea_peoples has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<siddh>
Hello everyone, I want to participate in XorgEVoC and contribute to DRM. Motivation for this is my liking and inclination towards kernel stuff (I started my kernel journey in June 2022 and am a long-time Linux enthusiast), and I have academic requirements to do some work for 3 months.
<siddh>
I am thinking of doing some TODO tasks. While I'm not sure what would be acceptable, I made an initial list to get started in making the proposal and get it through by Feb. You can view it at: https://gist.github.com/siddhpant/91c5e528083a68eefd0d01b971e2b48d
<siddh>
Please give your inputs, like whether some TODO tasks need more priority or attention according to you, or if there is any problems with list, or if I should punch more above my weight. It would be very helpful in polishing up and finalising things. Thanks!
ybogdano has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
djbw has quit [Read error: Connection reset by peer]
nchery has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Read error: Connection reset by peer]
iive has joined #dri-devel
ybogdano has joined #dri-devel
djbw has joined #dri-devel
ngcortes has joined #dri-devel
nchery has joined #dri-devel
nchery is now known as Guest1097
nchery has joined #dri-devel
Guest1097 has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Read error: Connection reset by peer]
srslypascal is now known as Guest1106
srslypascal has joined #dri-devel
Guest1106 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
cuolcp^ has joined #dri-devel
rsalvaterra_ has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
rsalvaterra has joined #dri-devel
agd5f has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
<airlied>
zmike: okay I think I got em all on that leak MR, just letting it the pipeline run to confirm
mbrost has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
fab has quit [Quit: fab]
mvlad has quit [Remote host closed the connection]
<mattst88>
we're struggling to reproduce a hang on Google Meet, but users are seeming to trigger it easily, but the batch buffer isn't being captured :(
MajorBiscuit has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
ice9 has quit [Ping timeout: 480 seconds]
<rodrigovivi>
mattst88: I'm going to sync tomorrow morning with tursulin on this... I believe he was involved with the reviews already and have a much better context to review it quicky
<mattst88>
okay, thanks!
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
dcz_ has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]