<mattst88>
unclear, passing '&dag_node' as the first argument to container_of (instead of 'dag_node') compiles with gcc, but the unit test fails then
<mattst88>
I'm seeing stuff that suggests that some versions of MSVC don't like offsetof when applied to non-POD types, and one of my structs has an operator overload
<mattst88>
but I can't reproduce the problem with godbolt
<mattst88>
I can't get clang or gcc to warn, with or without -Winvalid-offsetof
<robclark>
mattst88: if it is just for a unit test, maybe just skip it for MSVC builds? We have enough CI coverage with other compilers, and I guess it isn't the sort of thing that is likely to uncover an actual bug in the code being tested with compiler==MSVC
<robclark>
(ofc, if jenatali has a better suggestion, or disagrees, listen to him.. but I guess there isn't much extra value in spending a lot of time figuring out how to make the unit test work on MSVC)
<mattst88>
agreed
<jenatali>
I'm not in front of a computer at the moment but I can take a closer look later/tomorrow. But yeah disabling it seems fine unless you want MSVC coverage
<robclark>
it's really just the unit test doing tricky things.. I don't think the dag code itself has anything that would be sensitive to which compiler.. and not even sure if it is used by any code that is used in MSVC builds
<mattst88>
I'm just surprised that we have container_of() defined for non-GCC, but it doesn't work in what appears to be a very simple case
<robclark>
container_of() does, IIRC, have a gcc vs non-gcc version.. but not sure if the non-gcc version works with msvc..I vaguely remember hitting issues with that in the past
<jenatali>
IIRC the problems there are just around getting the type of variables in C using GCC extensions. MSVC only supports that using decltype in C++
<alyssa>
Oh no... a batch can migrate across contexts can't it....
rcf has quit [Quit: WeeChat 3.3-dev]
<alyssa>
or, er, worse..
<alyssa>
what happens if two contexts set_framebuffer_state the same framebuffer and draw to it simultaneously and flush simultaneously? who wins?
<alyssa>
undefined?
<robclark>
alyssa: that is UB if there isn't some sort of flush type barrier
<alyssa>
hmm
slattann has quit []
<airlied>
alyssa: this might be a naive q, but are your batches per screen not per context?
mattst88 has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
<alyssa>
airlied: ...TBD.
<alyssa>
I don't see how per context can possibly work when multiple contexts + multithreading are in use
<airlied>
alyssa: per context makes most sense, you just record all the work for a context and submit it on flush
<airlied>
unless there is some hw reason that doesn't work of course, which there might be
<alyssa>
No hardware reason
<robclark>
per-ctx makes more sense.. I over-designed it with freedreno to deal with texture uploads on 2ndary contexts
<alyssa>
but "submit it on flush" is complicated by batch tracking
<alyssa>
robclark: as an aside, I keep wondering if all this batch tracking stuff should really be comon code.
<alyssa>
it's complicated in every driver and .. subtly broken in almost every driver.
<robclark>
I suppose when I started, there was precisely one driver that would have benefited from it..
<alyssa>
nods.
<airlied>
robclark: does tiler make this more complicated?
<alyssa>
airlied: infinitely
<robclark>
airlied: sorta.. you really want to minimize tile passes.. but otoh most android games seemed to realize this and don't do silly things.. and there aren't too many challenging open src games on arm linux.. the one that benefitted a lot from it early was stk but they have since fixed a lot of their tiler anti-patterns
<alyssa>
robclark:...hmm
<robclark>
but random stuff designed without tilers in mind can benefit
<alyssa>
I do wonder what a "good enough" common impl would look like
<robclark>
I suppose if you are getting u_blitter at random points, then reordering can help
<alyssa>
since now fd/vc4/v3d/lima/panfrost/etnaviv/asahi all want this.
<alyssa>
and everything on that list except fd has issues in the impl, if it exists at all
<HdkR>
robclark: Don't worry, I'm bringing Proton/Wine games to ARM Linux :>
<robclark>
alyssa: I did initially try a shim pipe driver thing that did the re-ordering.. similar to idea of threaded-ctxt.. but overhead was too much.. but maybe if it were split across threads like threaded-ctxt it would be less
<alyssa>
hm..
<robclark>
HdkR: hehe, ok, bring on the interesting workloads.. it is the main reason I deal with play store (well, that, and being paid to care about those games :-P)
<alyssa>
HdkR: wait if this is combined with the steam dec promise does that mean in jan 2021 every steam game is supposed to work on arm64 linux?
<alyssa>
this is my driver developer's nightmare scenario.
<HdkR>
hah. Plenty of games break still. I can't fulfill that promise of "Every" :P
<Sachiel>
jan 2021 is not soon enough, try jan 2020
<robclark>
is this integer underflow day?
<alyssa>
what do you mean
<HdkR>
Hundreds, maybe thousands of games. Might be able to promise that :Thonk:
<alyssa>
it's march 2020
<robclark>
bring on Jan -1
<airlied>
someone needs to bridge a mali to an pcie bus and plug it into x86 :-P
<alyssa>
airlied: Nooooooooo
<robclark>
airlied: presumably someone can bolt that onto virtio/virgl?
<alyssa>
why must you pick on me so
<airlied>
robclark: should just work with panfrost
<airlied>
:-P
<alyssa>
i already look like enough of a fool with my apple pcie patches
mxvin[m] has joined #dri-devel
<robclark>
I guess fex is an easier way.. or danylo's trickery ;-)
<alyssa>
please don't add mali pcie patches on top of the fool stack
<HdkR>
Maybe someone can dig one of those Intel+Mali chips out of the grave
<airlied>
robclark: just bridge PCIE BARs to RAM and the Mali registers
<airlied>
PCIE<->AHB bridge ftw :-P
<robclark>
heheh
<robclark>
HdkR: I wonder with fex, if you have similar lolz with games making decisions based on GL_VENDOR/GL_RENDERER?
<HdkR>
robclark: There have been a few games not understanding what FD650 is. Or a game saying it doesn't understand what a "FEX-2108" CPU is
<robclark>
heheh
<robclark>
well, I did at least recently add a way to spoof GL_RENDERER for you
<robclark>
the CPU.. well, that is up to you ;-)
<HdkR>
Easy enough to spoof in the future if needed :)
<HdkR>
There are definitely a few games that barf immediately if they don't see `GenuineIntel` or `AuthenticAMD` in the basic CPUID field though
<HdkR>
That one's pretty annoying
<robclark>
`GenuineIntelNotReallyLolz`
<HdkR>
:D
<robclark>
I suppose if necessary `GenuineIntel\0NotReallyLolz\0\0`
<alyssa>
lolol
<alyssa>
robclark: I think the other issue is.. are any of the batch tracking designs in any of our drivers perfect?
<alyssa>
well, not "perfect" but
<alyssa>
fd you said is overcomplicated, most of them it looks like are racy, etc.
<alyssa>
if one were to try to add common helpers for batch tracking, what driver would you even port from?
<alyssa>
(Panfrost's tracking is some ugly mix of fd and v3d... getting better lately though.)
<robclark>
fd is overcomplicated.. but has been beaten into submission in the path towards productization.. but yeah, I guess the other implementations are simpler but haven't gone thru that trial-by-fire yet
<HdkR>
robclark: Sadly CPUID only gives you 3 32-bit values for that. The model field is what gives you...48bytes?
<alyssa>
v3d has the point of being simple but I'm not convinced it handles important cases (correctly or efficeintly or at all)
<alyssa>
robclark: nod.
<alyssa>
I think common helpers could work, not a full shim pipe doing reordering but just u_transfer_helper type thing
<robclark>
alyssa: anholt has been working on moving batch cache to ctx to simplify it.. but it is kinda hard to do it without regressing since it is.. well.. complicated.. maybe she has a wip branch that is worth looking at?
<alyssa>
happy to look
<robclark>
but current fd batch-cache-in-screen has a lot of beating-with-hammer-until-bugz-are-fixed
<alyssa>
Yeah.
<alyssa>
If I'm going to do any nontrivial work to panfrost bc I want a test plan for how not to horribly regress things
<alyssa>
unfortunately this is hard code to test other than "play store go brr"
<robclark>
I think deqp-egl and piglit surfaces the majority of the bugs, tbh
<alyssa>
fair ... I'm fighting deqp-egl this week.
<alyssa>
hich i didn't realize existed a week ago
<robclark>
you think deqp-egl is fun.. add running android cts deqp-egl into the mix when chrome is sitting there looking for context-lost and deciding to restart itself for other-context-lost ;-)
<alyssa>
computers were a mistake.
<robclark>
(where chrome is the compositor)
<robclark>
hmm, true.. or maybe sw (not written by us) was the mistake.. I lost track
<HdkR>
Delete computers, let humanity's hunter-gatherer instincts thrive
<HdkR>
No wait, that's too far
ngcortes has quit [Ping timeout: 480 seconds]
gpoo has quit [Remote host closed the connection]
gpoo has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
mattrope has quit [Read error: Connection reset by peer]
slattann has joined #dri-devel
jessica_24 has quit [Quit: Connection closed for inactivity]
Duke`` has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
mattst88 has joined #dri-devel
idr has quit [Quit: Leaving]
YuGiOhJCJ has joined #dri-devel
vivijim has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
thellstrom1 has quit []
pochu_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
thellstrom has joined #dri-devel
dongwonk has quit [Remote host closed the connection]
* ccr
tries to rub two stones together to produce pixels
danvet has joined #dri-devel
<airlied>
just have to oscillate at the correct frequency
<ccr>
indeed
gouchi has joined #dri-devel
gouchi has quit []
vyivel has joined #dri-devel
shfil has joined #dri-devel
dongwonk has joined #dri-devel
Ahuj has joined #dri-devel
lynxeye has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
pnowack has joined #dri-devel
rasterman has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<danvet>
sravn, another divergence in bridge users is whether they're using component.c or not
<danvet>
and component.c seems to be mostly to work around issues in drm_bridge.c for which fixes have been discussed, but not landed
<danvet>
stuff like module reloading
<pq>
emersion, nah, it's an unlucky special case, because it leads so many people first to the wrong track for a long time and they get used to it, then struggle really hard trying to change their views to something that works in general.
illwieckz has quit [Remote host closed the connection]
<emersion>
ahah
<emersion>
fair
bcarvalho has quit [Remote host closed the connection]
<pq>
haasn, there is no shortcut I'm afraid, you have to fully understand the pixel format defition before you can convert another definition to/from it. :-)
<emersion>
would be nice to add a table in pixel-format-guide
<pq>
haasn, so if you see that 8 bpc formats work in "reverse order", you can't assume the same applies to non-8 bpc formats. Or to 8 bpc formats defined in other than GL_UNSIGNED_BYTE convention in OpenGL. Or anything that is any way different other than only the order of channels.
<pq>
emersion, hmm... maybe the tool can already print some tables?
<pq>
ISTR it can at least tell what the format is in another definition
<emersion>
which tool?
<pq>
the tool in pixel-format-guide
<emersion>
oh.
<pq>
isn't there a python program included?
<emersion>
i didn't even realize there was a tool
<emersion>
there's a find-compatible subcommand which would be handy, yes
<daniels>
emersion: that repo has a link to its web UI tbf
<emersion>
daniels: yeah but the web UI is just prose, it doesn't expose the CLI
<daniels>
ah, iswym
<emersion>
nbd
<mslusarz>
shfil: it's not part of any MR; does it "fix" the clang analyzer issue?
hansg has joined #dri-devel
<shfil>
mslusarz: it does
Ahuj has joined #dri-devel
<mslusarz>
ok, I'll open new MR in a moment
jkrzyszt has joined #dri-devel
<hansg>
Hi All, can someone help me with a review of some kernel drm patches ? The first patch-set is a set of panel-orientation DMI quirks, so really trivial. These have been waiting for an Ack since May, if someone can review these that would be great: https://patchwork.freedesktop.org/series/90767/
<hansg>
The second patch-set is for sending hotplug notifies from the kernels Type-C code to DisplayPort connectors which are routed through a Type-C port using an external mux: https://patchwork.freedesktop.org/series/89605/
<emersion>
maybe ping Lyude for the second one?
<hansg>
There were some remarks on an earlier version of this patch-set but these have all been addressed after which things got quiet. The Type-C subsys patches have already been reviewed and the entire set has been tested by both me as well as by the the Type-C folks.
<emersion>
hanetzer: have you cc'ed people usually invoplved with these things?
<emersion>
err
<emersion>
hansg: have you cc'ed people usually invoplved with these
<emersion>
things?
<hansg>
Actually danvet did the earlier review of the Type-C hotplug event notification patch-set, so I was planning on pinging him, danvet ?
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
<hansg>
emersion, yes, although for the panel-orientation quirks I'm the person who is usually involved in that... I'm actually tempted to just push them since 8/10 last commits to that file were mine anyways, but a quick sanity check by anyone would be nice ...
<hansg>
(and I don't want to abuse my drm subsys commit rights)
<emersion>
nit: "drm: panel-orientation-quirks: Add quirk for the Samsung Galaxy Book 10.6" is misisng a period at the end of the last sentence
<emersion>
otherwise this looks ok to me, but note i'm not familiar with the drm panel orientation quirks
<emersion>
Acked-by: Simon Ser <contact@emersion.fr>
<hansg>
Thanks, I'll fixup the missing period in the commit message when applying them (and add your Ack).
<emersion>
np :)
rasterman has joined #dri-devel
<danvet>
hansg, uh I'm burried in i915-gem stuff
jkrzyszt has quit [Ping timeout: 480 seconds]
<hansg>
danvet, I understand any suggestions who else might be able to review this ?
<danvet>
hansg, the idea behind the ack is to do a bit of cross review with something else
<danvet>
there's plenty of patches floating around
<danvet>
hansg, for the dp/type-c stuff Lyude or jani come to mind
<hansg>
With cross-review you mean swapping reviews ?
<danvet>
I think both have/had tons of patches floating around meanwhile
<danvet>
hansg, yeah, that's kinda how drm-misc is supposed to work
<danvet>
instead of offloading all the approaval to airlied + me for misc random stuff with a pull request
<hansg>
Makes sense. I'm also planning on rebasing the LCD privacy screen series, so I'm going to need to swap reviews on that one too...
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
rcf has quit [Quit: WeeChat 3.3-dev]
rasterman has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
rcf has joined #dri-devel
<karolherbst>
what are the formal reqs for patches to drm-misc-fixes though? I see that most/all patches have a "Link:" line in them, is this a hard req or would it be fine if e.g. Ben has some patches on his git repo I'd cherry-pick and push? Or do we really want every patch to be on some ML somewhere?
<emersion>
my take: please send patches for the common code to the ML. this allows other to comment.
<emersion>
others*
<emersion>
i monitor the mailing list, not the git log
<karolherbst>
ohh sure
<karolherbst>
this is about nouveau only patches though
<emersion>
oh, didn't realize nouveau was using drm-misc
<karolherbst>
we might want to use it for fixes
<karolherbst>
trying out things atm
<emersion>
ok ok :) then disregard my take
<karolherbst>
so instead of Ben having to create a pull against drm-fixes with like 5 patches, we just push them to drm-misc-fixes onve they arrive at the ML or so
<karolherbst>
emersion: also.. do you know if "enable this GPU" is valid for fixes or do people want to see those going through next?
<karolherbst>
or ehh.. if others have comments on that :)
<emersion>
hm, i have no idea. i'd assume this has to go through -next because it's not a bugfix, but…
<karolherbst>
yeah....
<karolherbst>
it can cause regressions, because "chipset is different" or so
<karolherbst>
but I think in the past it was fine still
rcf1 has joined #dri-devel
rcf has quit [Quit: WeeChat 3.1]
rcf1 has quit []
rcf has joined #dri-devel
rcf has quit []
rcf has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
nirmoy has joined #dri-devel
flto has quit [Remote host closed the connection]
pochu has quit [Ping timeout: 480 seconds]
flto has joined #dri-devel
JohnnyonFlame has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
thellstrom has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
slattann has quit []
Gates has joined #dri-devel
ella-0 has joined #dri-devel
pjakobsson_ has quit []
ella-0 has quit [Remote host closed the connection]
ella-0 has joined #dri-devel
Gates has quit [Remote host closed the connection]
<karolherbst>
mlankhorst, mripard: in regards to patches going into drm-misc, atm we have most/all of the times a Link: thing in the commit message. How do we want to deal with it once patches come in through something like gitlab?
<karolherbst>
but I guess we would configure marge doing the same thing as we do for mesa and it is just adding those references or so?
vivijim has joined #dri-devel
mattrope has joined #dri-devel
<mripard>
karolherbst: if we ever move to gitlab, I think we should still require the mails to be sent on the ML somehow
<mripard>
so the link is easy to add after that as some kind of commit / merge hook
xexaxo_ has joined #dri-devel
<karolherbst>
mripard: what's the point of gitlab then? or do you mean before merging into drm?
<mripard>
I haven't raised the gitlab discussion, so I can't argue what's the point of gitlab
<mripard>
my guess would be linters/CI?
<mripard>
but we don't work in a silo and we can't expect each and every linux developer and maintainer to look at our gitlab
<mripard>
(at least without some kind of transition period)
rcf has quit [Quit: WeeChat 3.1]
<danvet>
mripard, you're way ahead, but also the way this worked for mesa is that it was handled on a team/driver basis
<danvet>
trying to bridge it with tools doesn't really work
rcf has joined #dri-devel
<danvet>
so if you want m-l review, then some dim script to do the merge request and arm it so it gets auto-merged when CI approves is roughly the best
<danvet>
karolherbst, wrt the link: use marge bot
xexaxo_ has quit [Ping timeout: 480 seconds]
<danvet>
which adds a full Part-of: link
<danvet>
maybe if we can bikeshed marge-bot to use Link: instead would be even better
<danvet>
oh you mentioned that already
xexaxo_ has joined #dri-devel
<karolherbst>
anyway.. atm I am still with the situation, that Ben has patches without any of that info, but I assume we want every patch to go through some public review process anyway :p
<mripard>
danvet: Konstantin (at the LF) seems to have a bot to bridge github and the ML, maybe we could just ask nicely? :)
<danvet>
mripard, it's not a question of writing a bot
<danvet>
there's plenty of that
<karolherbst>
I think the point is, if the process involes ML and gitlab then we can also just do ML
<danvet>
I was more going for "just gitlab"
<karolherbst>
in the end it's up to us to decide where we want to accept patches and developers choosing whatever they want to use
<danvet>
and treat the ML thing as the extra step if needed
<karolherbst>
if they now have to use both, then that's helpful
<danvet>
we clearly need gitlab CI minimally for build testing, because that goes wrong fairly often
<karolherbst>
yeah
<karolherbst>
so.. I am looking at this from a practical point of view
<karolherbst>
some person submit patches to nouveau against nouveau-fixes (or something)
<karolherbst>
gitlab CI does all the checks
<karolherbst>
we merge it
<karolherbst>
end of story
<karolherbst>
for the person submitting the patches it should be the end
<karolherbst>
no ML or anything
<danvet>
yeah
<karolherbst>
if we decide to send that bunch of patches to some ML in order to push it into drm-misc-fixes?
<karolherbst>
fine
<karolherbst>
whatever
<karolherbst>
then we have those links to the ML
<danvet>
well same for ml really, it shouldn't be too tricky to teach dim to open an MR and assign it to marge for merging
<karolherbst>
but we lose the link to the MRs
<karolherbst>
danvet: why use dim if we can just assign to marge?
<danvet>
nah going gitlab->ml makes no sense imo
<danvet>
karolherbst, I'm talking about patches that show up on the ml only, because they got submitted there
<danvet>
which will happen
<karolherbst>
danvet: well.. it still has to go to drm-mist some way... either me using dim/git to push it directly or whatever
<karolherbst>
ohh sure
<karolherbst>
then we can use the old process
<danvet>
karolherbst, imo if you do MR then just do that MR directly against drm-misc
<karolherbst>
or somebody creats and MR with collected patches
<karolherbst>
*creates
<danvet>
there's no point in putting another repo in at that point
<karolherbst>
danvet: sure.. but we don't accept MRs yet, do we?
<danvet>
like mesa doesn't, and drm-misc is not like 10x bigger (not at all)
<danvet>
karolherbst, once we have a reasonably well-working CI that implements the same checks dim does
<danvet>
why not?
<karolherbst>
then yes, but what if I want to accept nouveau patches through gitlab now?
<karolherbst>
I mean... I see the thing how it should look like in the end
<danvet>
well sure for a bit of prototyping that makes sense, but imo we should extend this to drm-misc as soon as it makes sense
<karolherbst>
I just don't think we can just flip the switch, or maybe we could?
<karolherbst>
there is another problem though
<danvet>
the only thing we need to do a bit of special care imo is the gitlab ci files
ella-0 has quit [Remote host closed the connection]
<karolherbst>
there are two repos for submitters
<danvet>
that should be a separate pull to linus I feel like
<karolherbst>
but maybe nouveau is a special project here which atm does pulls against drm directly
<danvet>
once we have that stake, there's nothing besides per-team consensus to switch
<danvet>
karolherbst, yeah most other smaller drivers moved into drm-misc
<karolherbst>
maybe we should do the same
<danvet>
maybe :-)
<karolherbst>
anyway.. I think it is fine for a driver to have its own repository.. we could just do MRs of next/fixes branches against drm-misc-fixes or we just have one bug tracker/repository for all drivers under drm-misc
<karolherbst>
or we just use drm/nouveau for issues and drm-misc for MRs
<karolherbst>
anyway.. my original question is answered anyway: we want references of the source, no "private" commit pushes or the likes
<karolherbst>
what's the process of enabling marge for other repos btw?
<karolherbst>
just assign it or do we have to enable stuff somewhere?
thellstrom has joined #dri-devel
<danvet>
karolherbst, imo if you do pull requests after review and all, just send to drm.git
<danvet>
it's just a detour at that point
<danvet>
the thing with that is that an entire forest of trees becomes a tangled mess when you do anything cross subsystem
<danvet>
plus a bit a silo tendency
<danvet>
karolherbst, I think it needs to be set up somewhere
<danvet>
also iirc when I discussed it, the idea was tossed around to have a separate marge for drm stuff
<karolherbst>
ahh
<danvet>
so that we can get Link: instead of part-of
<danvet>
#freedesktop essentially
mbrost has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
<karolherbst>
danvet: ehh... sure, the issue which brought this up was essentially Ben has a branch of fixes without reviews which he originally would send a pull for against drm.git but I was thinking I could also just review those and push through drm-misc-fixes. But.. there are on no ML and there are no gitlab MRs or anything :)
shfil has quit [Quit: Konversation terminated!]
<danvet>
karolherbst, ah yes that works too
<karolherbst>
right.. just wondering how strong people are with those link: tags and everything :)
<karolherbst>
*opinions of
<karolherbst>
I mean.. I simply don't want to push some patches to drm-misc which were never seen by anybody besides the author and me :D
<danvet>
if it's two people it's imo good
<danvet>
and the idea behind the Link: tag is to link to the discussion
<danvet>
wherever that is
<mripard>
danvet: it completely bypasses the usual system of maintainership and greatly reduces the review opportunity. I'm really not convinced we should go all-in on gitlab
<mripard>
it might make sense for the big drivers / companies like Intel that have dedicated teams
<mripard>
but it just won't work on all the smaller drivers where you usually have ~5-10 people working on the entire platform support
<mripard>
and none of them will look at gitlab
<karolherbst>
mripard: why shouldn't a driver team decide where they accept patches? drm-misc could always accept on both ends, just that drivers not using gitlab won't get those CI benefits
kurufu has quit []
kurufu has joined #dri-devel
<karolherbst>
danvet: also I guess marge should do all the drm-tip stuff and what not as well once we have one for drm
<karolherbst>
and why would gitlab reduce the review opportunity?
<mripard>
I'm not really concerned about the contribution side, but the review side
<karolherbst>
I feel like missing less patches on gitlab then those sent to a mailing list
<mripard>
probably, I trust you on that
<karolherbst>
on gitlab I have my labels and everything shows up in a special folder
<mripard>
sure
<karolherbst>
ehh.. subscribed labes
<mripard>
but how many linux maintainers (in general) do you expect to join and monitor MR in gitlab on a regular basis?
<karolherbst>
simple patches are never the problem, but what about patches abondened by the submitter which we still want to have etc... at least with gitlab you find that stuff easily
<karolherbst>
mripard: well... people don't want to do emails forever
<karolherbst>
I am already sick of doing patch reviews on MLs
<karolherbst>
younger people probably even more so
<mripard>
let's not start that debate :) I'm not sure it's a consensus in Linux
<karolherbst>
but we can also do emails in 50 years and linux being already dead, because we wanted to do emails forever :)
<mripard>
but just going all in in gitlab without any mean to bridge the gap isn't going to work
<karolherbst>
honestly? I don't see sticking with MLs as an long term option at all
<karolherbst>
that won't fly
<MrCooper>
mripard: the decision to use GitLab would be made by the people which monitor the patches anyway
<mripard>
karolherbst: I agree?
<karolherbst>
yeah.. but maintainers have to adapt
<karolherbst>
they can't live in their email only world forever
<mripard>
MrCooper: we're not working in a silo though?
<alyssa>
i didn't read backlog but I am 100% in favour of GitLab for kernel
<alyssa>
and this is coming from someone who had to be dragged off the mesa-dev mailing list kicking and screaming
<karolherbst>
treating "gitlab" as an addon won't work
<karolherbst>
it's either gitlab (or whatever other software we have in the future), or nothing long term
<mripard>
karolherbst: the bot I was mentionning is doing the opposite, it sends an email when an MR is done on github
<alyssa>
mripard: "I'm not sure it's a consensus in Linux"
<karolherbst>
mripard: and what's the point of that?
<alyssa>
the consensus for MLs comes from the fact that everyone else is pushed out very quickly
<MrCooper>
mripard: meaning? Why would people who are not monitoring patches have a say on how the people who do choose to do it?
ella-0 has joined #dri-devel
<karolherbst>
just so that some people get emails once an MR is... opened/closed/whatever? we already have that, gitlab can do that :)
<karolherbst>
I honestly don't care about people with their "there is only email" thinking
<mripard>
MrCooper: let's assume you are part-time maintaining that DRM driver (so, like, 90% of the drivers in drm-misc)
nchery has joined #dri-devel
<mripard>
and you maintain the whole platform it sits in
iive has joined #dri-devel
<karolherbst>
I don't want to make it harder for them, but they have to adjust sooner or later
<mripard>
you probably get to have a say on the patches coming in for that driver?
<mripard>
the opposite is true, you probably would want to have the opinion of the one working on this full-time
<MrCooper>
if there's no consensus to use GitLab for drm-misc, it won't happen
<mripard>
seriously, I never said that gitlab was a bad thing, I'm all for it
<karolherbst>
we can also have a drm-misc-old-world and a drm-misc-cool-world using gitlab :p
<mripard>
karolherbst: then the old-world will keep doing stupid things because the new world will not even care for what they are doing.
<karolherbst>
so?
<karolherbst>
the cool world has CI
<karolherbst>
the old one doesn't
<karolherbst>
if the break stuff, it's on them
<karolherbst>
*they
<mripard>
they don't have to break stuff to be painful
<karolherbst>
but I think we need a path forward somehow, and it can't be "bridging"
<mripard>
just being in the path of a refactoring is painful already
<alyssa>
as an aside--
<karolherbst>
I think there is just one way: just doing it
<karolherbst>
otherwise we'll bikeshed for 200 years
<alyssa>
this is making me ruminate on just how special Mesa is, the community we've built for ourselves
<mripard>
you know what, I'm not sure why I'm in this discussion, and you don't really seem to listen, so I'm not going to continue
<mripard>
do whatever you want
<mripard>
it's going to be great
<karolherbst>
yeah.. never claimed I have a _good_ solution
<karolherbst>
it will be messy one way or the other
<karolherbst>
just tired of people not wanting to change anything, that's all
<karolherbst>
and why accepting to getting hold back by those
gpiccoli has joined #dri-devel
<karolherbst>
and MrCooper is right, if we want to have a consensus and it never happens, then it won't happen
<karolherbst>
heck
<karolherbst>
we didn't even had one for mesa
<karolherbst>
so....
<karolherbst>
¯\_(ツ)_/¯
<mripard>
and yet it happened?
<karolherbst>
sure
<alyssa>
karolherbst: I still have issues with gitlab mesa
<alyssa>
and it was still objecitvely the right move
<karolherbst>
obviously it did :)
<mripard>
so much for the "if we don't have one it's not going to happen"
<alyssa>
karolherbst: I do nontrivial review over a bespoke script I have that consumes the gitlab api and gives me an email-like review workflow.
<karolherbst>
yeah... the MR UI isn't the greatest
<alyssa>
It's a little annoying for me, it's a little annoying for the reviewee, but as far as compromises go, it seems to work o
<karolherbst>
having CI is awesome
<karolherbst>
for that alone I am willing to accept those compromises
<karolherbst>
worst case I can always pull the branch and look locally
<alyssa>
sr.ht does CI for mailing lists, never used it myself
<alyssa>
emersion: ^
<karolherbst>
ohh sure
<alyssa>
(Not saying we should use sr.ht. Just that it shouldn't be a deciding factor.)
<karolherbst>
but it sucks in other ways. patches have to apply somewhere
<mripard>
alyssa: with that automated, I'm all for it.
<karolherbst>
sometimes you send out from a older state and CI breaks
<karolherbst>
but gitlab would be fine
<alyssa>
mripard: "that"?
<karolherbst>
alyssa: right
<emersion>
karolherbst: --base-commit
<karolherbst>
but I think there is merrit to use gitlab for everything and not deal with different systems :D
<karolherbst>
emersion: yeah.. I am aware you can make it work with patches from a ML
<mripard>
alyssa: your gitlab to email script
<alyssa>
mripard: It's not actually email, just "email-like"
<ajax>
here's what you do
<MrCooper>
mripard: there was a small (but relatively vocal) minority in the Mesa developer community which resisted the move to GitLab; by now, they've either come to terms with it (or left, I suppose), and I think there are very few people left who'd seriously claim it was a bad move overall (and know what they're talking about :)
<ajax>
you do the magic trick to make the merge requests show up as a new remote
<mripard>
MrCooper: I'm convinced that moving to Gitlab is the way forward
<alyssa>
I invoke it as `lab 1234 pr` and it'll open the .patch for the series in MR#1234 in my $EDITOR, respond as if email, and when I save from my $EDITOR, it'll automatically post as comments to gitlab
<emersion>
alyssa: interesting
<ajax>
and every night you fetch from there and if any heads updated you dump out their patch serieseses as mboxes
<alyssa>
(pr = patch reply)
<ajax>
and you point your mua at that
<karolherbst>
we just need this gitlab CLI tool doing all that fancy shit
<mripard>
just not at the expense of shutting us off the rest of Linux.
<karolherbst>
gitlab show mrs
<alyssa>
for actually discovering new patches relevant, I'm subscribed to the relevant labels on gitlab so I get the email
<karolherbst>
or wahtever
<alyssa>
and the email has the ID right there in subject IIRC
<karolherbst>
mripard: ohh.. linux will have to move sooner or later
<alyssa>
(and if I want to read the whole thread, `lab 1234`)
<karolherbst>
somebody just needs to start
<ajax>
i think a lot of the resistance to things-like-gitlab is the expectation that web site means not scriptable
<alyssa>
(and if I just want the gitlab merge request home page `lab`)
<alyssa>
ajax: gitlab is super scriptable
<ajax>
as if curl wasn't a thing
<alyssa>
there are really nice python bindings for the gitlab bindings, that's what my awful script does
<karolherbst>
MLs are scriptable?
pochu has joined #dri-devel
<ajax>
karolherbst: in the sense that if you're using them you've already rolled your own tooling and no longer think of that as a cost, maybe
<karolherbst>
ajax: I guess
<ajax>
i mean. patchwork.
<karolherbst>
hence me wanting this awesome gitlab CLI tool
<karolherbst>
but I assume we already have those
<karolherbst>
distributions just don't package those
<ajax>
there's several. would be nice if fedora picked a favorite and ran with it, yeah
<karolherbst>
there are also tons of really cool replacments for coreutils, but if they are not packages I don't want them :D
<ajax>
but the api is so simple i often end up writing my own bash wrappers around curl for specific things
<mripard>
karolherbst: again, I agree. I'm not sure how that's answering what I'm saying though. It's not gitlab that concerns me, it's the shut off.
<MrCooper>
mripard: not seeing how that could happen, I rather expect GitLab will spread from us to other parts of the kernel :)
<karolherbst>
ajax: there is a special web client for json APIs :D
<mripard>
Ultimately, it boils down to how much you value the reviews of people that won't join Gitlab
<mripard>
I do, a lot.
<karolherbst>
jq
<karolherbst>
ohh.. that just uses curl then anyway
<karolherbst>
nvm
<ajax>
yeah, jq is more like grep/xslt for json
<karolherbst>
mripard: yeah... it's the problem with people not wanting to change a system, because "it works" or something, but if you care tooo much about those, we will never progress
<mripard>
I gave you a reasonable path forward
<mripard>
I'm not sure why it's considered as holding back.
<mripard>
(or why we just can't do that).
<karolherbst>
I think it boils down to how much of it stays within the process. If the core process doesn't involve emails, then sure, we can have bridges for people rather having emails from bridges than gitlab or to notify MLs of new MRs
<karolherbst>
but I don't think integrating bridges into a workflow makes sense at all
Daanct12 has joined #dri-devel
<karolherbst>
I mean.. you can even reply to MLs by replying to the emails you get
<karolherbst>
*MRs
<karolherbst>
but if the maintainers/reviewers are not commited to gitlab it won't work, as you will have those people ranting about gitlab all the time and that's annoying tbh
<jenatali>
alyssa: The problem with that script is that your comments don't get added as source-level comments, just overall comments on the MR, so you don't get the handy context that makes responding to reviews much simpler
Daanct12 has quit [Remote host closed the connection]
Danct12 has quit [Ping timeout: 480 seconds]
<danvet>
karolherbst, mripard hence per team decision more or less
<danvet>
for some value of "team"
Daanct12 has joined #dri-devel
<alyssa>
jenatali: Yeah, sadly so. I don't know if there's a sane fix to that.
<emersion>
is this a limitation of the GitLab API?
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<alyssa>
emersion: doubt it, but not sure what UX would look like for proper gitlab style review.
<emersion>
hm, probably not, drew has a ML → GitLab converter which works fine for code comments
<alyssa>
jenatali: It's selfish but the extra overhead of GitLab web UI reviews versus this script seems significantly higher than the higher overhead of looking up the context in the patch.
<alyssa>
and with 10kloc diffs floating around ...
<jenatali>
alyssa: Eh, maybe. If it were me, I'd prioritize other people's review effort and I'd find the context in the web myself to make the comment there, even if I'm reviewing the code externally
<jenatali>
But that's just me :)
<karolherbst>
danvet: ohh, btw.. what was the consensus on hw enablement through fixes if the code is already there? like adding PCI IDs?
<danvet>
if it's small it's ok
<danvet>
if it's more like an entire new driver, not so much
<karolherbst>
fixes are annoying if they are that huge
<karolherbst>
especially if they disable ioctls which were never used (tm)
<danvet>
seems fine with fixes
<danvet>
we've fixed a bunch of bugs/exploits by just disabling uapi
<karolherbst>
okay :) I mean you would have accepted Bens pull anyway :p
<karolherbst>
(probably)
<danvet>
the last one is maybe a bit big, but that's like the actual bugfix?
<danvet>
yeah as if we're looking
<karolherbst>
yeah.....
<karolherbst>
so
<danvet>
that's just for plausible deniability for everyone involved
<karolherbst>
this super field was global state more or less
<karolherbst>
and clients raced on the value of that
<karolherbst>
and if you timed it right you went in the the "privileged" path but with wrong data or so
<karolherbst>
it might even have sec implications
<karolherbst>
although maybe limited to one process
<karolherbst>
the two patches before just makes it easier to fix :)
xexaxo_ has joined #dri-devel
<alyssa>
__aarch64_ldadd4_acq_rel -- this isn't a single instruction on arm64? :(
orbea1 has joined #dri-devel
orbea1 has quit []
orbea has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
<alyssa>
Oh.. depends on CPU...
<alyssa>
ARMv8.1 and newer
gpoo has quit [Read error: Connection timed out]
<alyssa>
If I pass `-march=armv8.1-a` it generates the expected code. Wonder if I should use that in my mesa builds :P
<imirkin>
do you frequently swap the CPU inside of your SoC?
<imirkin>
if not, using -march=the-right-thing is generally a good move
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
nod
<lynxeye>
alyssa: Sure, if you don't care about the army of Cortex A53...A73.
<alyssa>
lynxeye: ...Do I care?
* alyssa
runs lscpu
<imirkin>
(more realistically, if you use the same mesa build on multiple SoC's, pick the "lowest" cpu of those)
<alyssa>
lynxeye: I guess I do have to care about A53. Ugh.
tzimmermann has joined #dri-devel
<alyssa>
Guess I didn't realize that ARMv8.1 is still somehow new.
<zmike>
emersion: hey any chance you'd be able to give the zink dmabuf MR a read sometime? not really sure who else to ask
<lynxeye>
alyssa: Isn't that new, but it takes a looong time from architecture revision to actual CPU IP cores and then to actual SoCs. Takes even more time to phase out a core as popular as A53.
<alyssa>
lynxeye: Yeah, makes sense
<alyssa>
I guess I'm more surprised that ldaddal wasn't in armv8.0
Daaanct12 has joined #dri-devel
rasterman has joined #dri-devel
<lynxeye>
alyssa: It needed some guys to actually build large core count SoCs for everyone to figure out that maybe those dumb loops bouncing cache lines around might not be the smartest idea. Which is how LSE was born. ;)
<haasn>
10:16 <pq> haasn, so if you see that 8 bpc formats work in "reverse order", you can't assume the same applies to non-8 bpc formats. Or to 8 bpc formats defined in other than GL_UNSIGNED_BYTE convention in OpenGL. Or anything that is any way different other than only the order of channels. <- you're the one making assumptions, here, not me
Daanct12 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
gouchi has joined #dri-devel
Daanct12 has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Ping timeout: 480 seconds]
Danct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #dri-devel
<jekstrand>
bnieuwenhuizen, hakzsam: Mind acking the two RADV patches in !12023? They *should* be pretty trivial.
<bnieuwenhuizen>
looking
Danct12 has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
jekstrand: done
<jekstrand>
thanks!
<jekstrand>
dj-death: Could you take one more look at the anv_image_view patch in !12023?
Danct12 has quit [Ping timeout: 480 seconds]
<dj-death>
jekstrand: sure
lynxeye has quit [Quit: Leaving.]
<alyssa>
ohh, this bug is insidious
shfil has joined #dri-devel
nchery has quit [Remote host closed the connection]
idr has joined #dri-devel
slattann has joined #dri-devel
<jekstrand>
Ugh... Why does drm_fourcc.h include drm.h? *sigh*
<jekstrand>
Means you can't #include "drm_fourcc.h" on windows just for the #defines
<alyssa>
jekstrand: Also affects macOS, but I care little about that now :)
<jekstrand>
emersion: I pinged it
<emersion>
there was a long discussion before this patch, with lots of alternatives considered
<jekstrand>
Meanwhile, I need to throw my own DRM_FORMAT_MOD_INVALID #define in a fhile
<MrCooper>
jekstrand: why would you need DRM format definitions when building for Windows?
<sravn>
danvet: As reply to your comment about bridges and component framework
<alyssa>
jekstrand: I did it :3
<sravn>
danvet: I would love to have the time and understanding required to fix all this
<MrCooper>
IMHO this means the winsys abstraction is leaky
<jekstrand>
MrCooper: It lets us avoid #ifdef the universe
<jekstrand>
It's not about wanting drm_fourcc on Windows. It's about drivers being able to just say "if I have a modifier, do X, else do Y" without having a pile of #if surrounding it so it builds on Windows.
<sravn>
danvet: mripard posted a nice series that starts to address some of this, but lacks the device_link required. And I dunno if this is enough to handle the dependency issues
<danvet>
sravn, device_links have been fixed to handle the reload/rebind issue
<MrCooper>
jekstrand: there are never modifiers on Windows, are there?
<danvet>
I can try and dig out the series if you need it
<jekstrand>
MrCooper: No, there aren't
<MrCooper>
there you go :)
<jekstrand>
MrCooper: But I want to be able to initialize something to DRM_FORMAT_MOD_INVALID
<sravn>
danvet: lacks tims for now :-(
<jekstrand>
It's that or put #ifndef _WIN32 around every line of code that ever touches that field.
<sravn>
danvet: Moved to an older house that require renovation, lots to do in garden, silver wedding etc. So not much spare time to fun linux projects atm
<jekstrand>
Which could be done but ugh
<MrCooper>
jekstrand: define a winsys abstraction for it then, though I'm pretty skeptical it makes sense to compile such code for Windows at all
slattann has quit []
<sravn>
danvet: I hope mripard will take the bait and update his series
<jekstrand>
MrCooper: The code will never execute in a meaningful way on Windows but having it compile there means fewer #ifdef which means fewer weird build issues.
xexaxo_ has joined #dri-devel
ella-0 has quit [Ping timeout: 480 seconds]
<MrCooper>
#define SOME_WINSYS_TOKEN DRM_FORMAT_MOD_INVALID for DRM platforms, to whatever value for Windows, and s/DRM_FORMAT_MOD_INVALID/SOME_WINSYS_TOKEN/g in the code
<danvet>
plus the entire series of commits leading to that from c8d50986da5d74ddfc233b13b91d0a13369fa164
<danvet>
mripard, ^^
lemonzest has quit [Quit: Quitting]
ella-0 has joined #dri-devel
<alyssa>
...this is also racy. ok
<alyssa>
thanks helgrind...
frieder has joined #dri-devel
<karolherbst>
alyssa: you will come to the conclusion that all code is racy :)
<alyssa>
resources can be accessed concurrently so any mutable state on panfrost_resource is a data race waiting to happen?
<alyssa>
karolherbst: only all code touching mutable shared state.
<karolherbst>
alyssa: yes
<karolherbst>
alyssa: which by default is all state unless you took care it isn't :)
<alyssa>
well, I just refactored batch tracking so now none of that is shared state
<karolherbst>
yay
<karolherbst>
alyssa: be aware that shaders are also shared, but I think you were there already
<alyssa>
at the expense of an 8% hit in drawoverhead test 1 but meh
<alyssa>
I feel like worth it.
<karolherbst>
yeah.... tracking gets super expensive once you allow multiple threads
frieder has quit [Remote host closed the connection]
<alyssa>
this way there is no way to get a panfrost_batch without first having the owning panfrost_context
<alyssa>
so Gallium not sharing contexts means batches will never be shared.
<alyssa>
so this makes my CTS test pass
xexaxo_ has quit [Ping timeout: 480 seconds]
<mripard>
danvet: nice, thanks
ella-0 has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
<imirkin>
alyssa: there is no "owning" context
<imirkin>
alyssa: that context can be destroyed, for example.
<alyssa>
imirkin: Hum?
<imirkin>
resources aren't owned by contexts
<alyssa>
not the resource
<alyssa>
the batch
<imirkin>
oh
ngcortes has joined #dri-devel
<imirkin>
then nevermind :)
<sravn>
danvet: so display driver is consumer and bridge drivers are suppliers in out scenario?
<alyssa>
but previously my resource had a rsrc->writer field which gave the writing batch
<alyssa>
but actually multiple contexts can each be writing simultaneously and like
<alyssa>
Bad Idea(TM)
<imirkin>
alyssa: yeah, that's dangerous without additional tracking
<alyssa>
but then if you just did flush_writer(rsrc) you end up fighting another thread
<alyssa>
but now that writer is gone, instead ther'es a ctx->writers hash table mapping rsrc -> batch and you have flush_writer(ctx, rsrc) which will flush "your" writer
<alyssa>
which means you're not racing whatever happens in another context
<danvet>
sravn, I paged out everything, only remembered that the bits are there :-)
<danvet>
but sounds about right
<anholt_>
alyssa: for draw overhead stuff, check out my open MR for moving freedreno's batch cache to the context
<alyssa>
anholt_: this is lifted from v3d fwiw
gpoo has joined #dri-devel
<alyssa>
The big behaviour change is that "context A binds a texture as a framebuffer and writes to it but doesn't flsuh it, context B does a glTexImage from it"
<alyssa>
under the old logic, panfrost would 'helpfully' flush the writes
<anholt_>
yep
<alyssa>
under the new logic, there's no implicit flush
<anholt_>
which was unnecessary and caused all sorts of raciness
<anholt_>
and extra locking
<alyssa>
yep yep.
<alyssa>
the only 'problem' is that hash table access is a lot more expensive than directly storing stuff on the rsrc
<anholt_>
thus pointing you at the tricks in my mr
<alyssa>
got it
* alyssa
shuts up and reads the code
<anholt_>
BO bitset is the main thing
<alyssa>
pre hashed, clever.
<alyssa>
anholt_: I see fd still has the recursive dep management
<anholt_>
I really wish we had some nice fancy btrees for things like pointer sets/tables, should be better than hashing our pointer values. but sigh, C.
<alyssa>
panfrost had that, but it was super complicated and brittle and then we realized removing it was strictly better in what we tested? so i'm curious what win fd is extracted that panfrost/v3d isn't
<anholt_>
yeah, I didn't gut that out. I don't know why rob did that, but presumably he was optimizing something?
<alyssa>
bbrezillon and i realized that once you add a dependency, you have to freeze the dependent batch anyway. so you're not winning anything
<alyssa>
actually it's strictly a loss since if you just submit it right away, you decrease the latency
<alyssa>
I guess you could reduce roundtrips to the kernels by coalescing ioctls, although at the time panfrost could only submit one(half) batch per ioctl anyway
<anholt_>
alyssa: I came to the same conclusion about things getting frozen
Ahuj has joined #dri-devel
agd5f has quit [Remote host closed the connection]
<alyssa>
[As for reducing roundtrips .. my gut says it doesn't matter, and if it does it's probably better to do it in freedreno/drm ]
agd5f has joined #dri-devel
<anholt_>
we do coalesce submits into one ioctl, though it's done in a drm abstraction layer for reasons I'm not entirely clear on.
<alyssa>
nod
<alyssa>
would be curious if anything in the play store is hurt if you just rip out the code.
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
<alyssa>
dumb question -- what's the difference between p_atomic_read and non-atomic reads?
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
<alyssa>
(and if you just replace your `uint32_t` with `_Atomic uint32_t` can all the p_atomic_ go away?)
<jekstrand>
alyssa: ordering guarantees, most likely.
<jekstrand>
So, on x86, nothing. On ARM.....
<pendingchaos>
IIRC atomic reads are volatile and don't have race issues (no locks needed around reads/writes)
<alyssa>
Mumble. Alright, thank you
jessica_24 has joined #dri-devel
ella-0 has joined #dri-devel
xexaxo_ has joined #dri-devel
hansg has quit [Quit: Leaving]
<jenatali>
mattst88: Sorry I took so long to look at your compile fail, it was a simple fix :(
<mattst88>
jenatali: oh, no problem at all
<mattst88>
happy to have someone look into it
<alyssa>
anholt_: Using pre_hashed variants throughout is actually regressing perf for me by about 1%
<anholt_>
suspicious.
<mattst88>
jenatali: ugh, wow
<jenatali>
Yeah
<jenatali>
I think MSVC supports offsetof(variable, member) in addition to offsetof(type, member)
<jenatali>
Or maybe it's just a stupid bug, I dunno
<alyssa>
Maybe the extra memory lookup is no faster than computing the hash if there's a cache miss?
<mattst88>
well, that certainly explains why I couldn't reproduce it in godbolt :)
<jenatali>
Yep, mystery solved at least
<mattst88>
thanks a bunch for taking a look
<jenatali>
Anytime
nchery has joined #dri-devel
<robclark>
alyssa: the submit ioctl coalescing was actually a big win in some games, although a part of that was that it was just avoiding idle time on the gpu and so convincing devfreq to actually ramp up gpu freq.. otherwise with blits and compute jobs we could be generating ioctls that generate very little work for the gpu..
<robclark>
(it was done at the freedreno/drm level mostly because we need to merge bo tables after we decide which order batches get flushed.. and the bo table is all at the freedreno/drm level)
<alyssa>
robclark: ack
<alyssa>
Just typed ./glcts, let's see what dumb thing it fails over after 60 hours of up time :V
<mdnavare>
emersion: agd5f: For testing extended mode and mirror modes with xrandr where one display is connected to igpua nd one to dgpu, what commands should be used ?
<alyssa>
Is this an actual bug or just helgrind noise?
<alyssa>
==135613== Thread #4: pthread_rwlock_destroy with invalid argument
<alyssa>
==135613== at 0x6917794: simple_mtx_destroy (simple_mtx.h:87)
<alyssa>
I think noise but...
<mdnavare>
agd5f: But do we need to use the setprovider with xrandr some places it says its not required with DRI PRIME
<Lyude>
haasn: I will try to review your patches soon. right now there's not really anything I need reviewed though. The one thing I could use would be if someone could write up the DPCD backlight PWM mode patches that sataduru from google has been asking for
<haasn>
wrong highlight?
<Lyude>
but that's totally optional, as I have no idea if you'd even have the hardware for that :P (if you are interested I could forward you the email-
<Lyude>
apparently yes
<Lyude>
if you are not hans lol
<Lyude>
ah they went offline, will send this to them via email then :P
<agd5f>
mdnavare, I think the X server automatically sets the providers in most cases.
<jekstrand>
bnieuwenhuizen: Any idea why I'm seeing these fails:
<jekstrand>
bnieuwenhuizen: I can't repro so I don't know what's going on.
<jekstrand>
bnieuwenhuizen: I don't see why it'd fail with my patch but it is
<mdnavare>
agd5f: Okay so then I can just set both outputs together with xrandr --output DP-1 --output DP-2 where DP-1 connected to igou, DP 2 connected to dGPU
<jekstrand>
airlied: But without a backtrace, that doesn't help me much
<bnieuwenhuizen>
time to add asserts with backtrace to mesa?
<jekstrand>
bnieuwenhuizen: I'd love it if asserts in Mesa dumpped a backtrace!
<agd5f>
mdnavare, yeah, I think so
<anholt_>
or we could have deqp-runner capture some coredumps, which would be generally useful.
<mdnavare>
agd5f: how to tell that this should be in extended mode not mirror mode
<agd5f>
mdnavare, --right-of or --above
<agd5f>
etc
<agd5f>
you can also specify x, y coordinates directly IIRC
<bnieuwenhuizen>
jekstrand: oof figured it out. happens in an ImageToBuffer. Because we don't support S8 for buffers we use R8, which obviously fails when we try to create a STENCIL aspect image view ...
<bnieuwenhuizen>
now the second question is "how did this ever work for D+S images"
Ziemas has quit [Server closed connection]
ngcortes has quit [Ping timeout: 480 seconds]
Ziemas has joined #dri-devel
<emersion>
zmike: last time i looked at it i didn't understood what was wrong with it
<zmike>
ah :/
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
shfil has quit [Quit: Konversation terminated!]
<mdnavare>
agd5f: Any idea why the extended mode would show output and can move widnows around properly through vnc viewer but dont see anything on the second monitor when I look through the actual camera pointed to it?
nirmoy has quit []
<mdnavare>
agd5f: This is because our extended mode set up is in the lab and we are using the camera to look at the output and also checking with vnc viewer
<agd5f>
mdnavare, is the timing running properly on the GPU running the monitor?
<mdnavare>
agd5f: Monitors are connected to both GPUs and through vnc viewer it looks fine
<mdnavare>
but on direct camera output, only see cursor on the monitor connected to DGPU
<agd5f>
mdnavare, do you have a compositor running?
<mdnavare>
Yes its running X11
<agd5f>
just a bare xserver?
<mdnavare>
Yes
<mdnavare>
tried switching to Wayland in the config file but that switch not working
<agd5f>
I think you might need an X compositor for this to work
<agd5f>
something like xcompmgr or the desktop compositor running on X
<imirkin>
the compositor thing is only needed for offloading accel i think, with dri2
tzimmermann has quit [Quit: Leaving]
<mdnavare>
agd5f: imirkin: Do I need to explicitly run the xcompmgr ? Or like get a Gnome desktop or something
vup has quit [Server closed connection]
<alyssa>
anholt_: Oh, re BO bitmap -- I wonder if we want a util/u_dynbitset.h
vup has joined #dri-devel
<alyssa>
It seems like a common pattern
<imirkin>
mdnavare: you don't need anything
<imirkin>
it's a moderately common issue
<alyssa>
(I'll write the code if you want to rebase on it)
<imirkin>
the GPU thinks that it's driving the screen
<imirkin>
but the screen disagrees
<imirkin>
and the screen is the one with final say over the situation :)
<mdnavare>
imirkin: well in syslog I see both the GPUs are trying to do a modeset on the respective CRTCs
<imirkin>
oh
<anholt_>
alyssa: util-bitset-resizing of my tree may be useful
<mdnavare>
imirkin: Also when I see this through vncviewer it does show extended display correctly
<mdnavare>
but with direct camera its just a black screen on dgpu display
Moiman has quit [Server closed connection]
Moiman has joined #dri-devel
<agd5f>
mdnavare, well there is always a desktop large enough for both displays, but part of it gets copied to the other GPU for display
<imirkin>
mdnavare: so like i said ... the computer thinks everything is working
<imirkin>
but the screen disagrees
<imirkin>
have you ever seen that second screen display anything?
<mdnavare>
imirkin: agd5f: When the system is booted, the boot screen is seen on both monitors but when GUI takes over thats when second monitor goes blank
<alyssa>
anholt_: yeah, that looks good
<agd5f>
mdnavare, whichever GPU is the render GPU renders the entire desktop and then parts get copied to other GPUs for display if necessary
<imirkin>
mdnavare: that's rather surprising that boot is seen on both
<imirkin>
mdnavare: normally it'd only show up on primary gpu
<mdnavare>
agd5f: So the vncviewer is just showing the entire desktop? Whereas when we see it on the displays second is blank because its not able to probably copy things over to vram for displaying through dgpu screen?
<alyssa>
anholt_: Though I was envisioning a 'managed' variant. I.e. that patch plus `struct util_dynbitset { uint32_t size; BITSET_WORD *data; } \n #define DYNBITSET_TEST(bitset, x) BITSET_TEST_SIZED(bitset->data, &bitset->size, x) \n #define DYNBITSET_SET(bitset, x) BITSET_SET_RESIZING(&bitset->data, &bitset->size, x)`
<imirkin>
mdnavare: vncviewer shows everything as expected because the computer is doing everything it thinks is fine. the screen is blank because something is not.
<imirkin>
that's really all one can say with the extent of information available
<anholt_>
alyssa: yeah, I wasn't sure what to do about this. C macros get so painful
<mdnavare>
imirkin: agd5f: I do have the syslogs and dmesg logs I could share
<mdnavare>
I am not able to make sense where things are breaking
<imirkin>
mdnavare: can you press buttons on the monitor?
<agd5f>
mdnavare, try a compositor. IIRC it's required for this to work correctly
<anholt_>
hmm. virgl-on-gl seems to be very slow now.
<mdnavare>
agd5f: And how should I try the compositor with Xorg?
<agd5f>
DISPLAY:0.0 xcompmgr &
<imirkin>
probably DISPLAY=:0.0
<agd5f>
whoops, yes
<imirkin>
i remember that was definitely needed for DRI2 + offloading
<imirkin>
don't remember it for output slaving. but i'm also not certain it wasn't.
<alyssa>
anholt_: agreed in general, what's the issue in the specific case here?
<imirkin>
certainly won't hurt to try.
<daniels>
anholt_: crosvm …
<mdnavare>
imirkin: agd5f: So from the control panel select the join displays and then run this DISPLAY=:0.0 xcompmgr & on command line?
<anholt_>
daniels: yeahhhhh
<daniels>
but Rust makes everything faster?
<alyssa>
brrrrrr.rrrrrrrs
<daniels>
tomeu did rebalance a week or two ago but maybe not enough?
<agd5f>
mdnavare, what control panel? Are you already running gnome shell or something like that?
<anholt_>
so !12196 made it so we only use 3 deqp processes in the guest, but deqp runtime is all about guest CPU time.
<anholt_>
it felt like some papering over of driver bugs where things timed out when they shouldn't.
<anholt_>
but also if that MR only reduced these runners from 8 to 3 deqps in parallel, and raised the jobs from 2 to 6, then I don't know why we're so slow.
<mdnavare>
agd5f: Nope I mean just with the display settings where I see 2 displays, selecting join displays
<agd5f>
are you just running that app on a bare xserver or as part of the whole desktop environment?
<agd5f>
mdnavare, probably easiest to just start a standard desktop environment running on X
<agd5f>
that should include a compositor
<mdnavare>
agd5f: Yes so right now we are just doing this on plain Ubuntu 21.04 so that should be bare Xserver no desktop env running
<agd5f>
mdnavare, plain ubuntu 21,04 loads a gnome by default
<mdnavare>
agd5f: Yes so this should be Gnome running on X
<agd5f>
ok, then that should have a compositor already, so nothing extra to do
<mdnavare>
agd5f: Hmm so not sure why it only does cursor plane on dgpu display and primary plane 1A on igpu display
<mdnavare>
thats what i see from logs
<agd5f>
mdnavare, my guess is that there is some problem dealing with dma-bufs in your kernel driver
<mdnavare>
agd5f: So with single display on iGPU the offload render on dgpu and scanout on igpu works fine
<mdnavare>
jekstrand: Do you think this might be related to the migrate code fixes in gem?
<daniels>
anholt_: that makes two of us then …
sneil has quit [Quit: Leaving]
<mdnavare>
agd5f: So can you clarify one thing: When I am booting and just selecting joind isplays, just displaying the gnome desktop by default its not rendering anything on dgpu, so its using igpu for rendering the full desktop and now it needs to move parts to vram for scanning on dgpu display right?
<mdnavare>
jekstrand: Do you think this is the issue we talked about where its unable to migrate to lmem after pinning the buffer to smem?
sneil has joined #dri-devel
<agd5f>
mdnavare, likely.
<mdnavare>
agd5f: But like we discussed last time, if we switch to wayland that should just create 2 separate buffers for 2 displays, then this migration issue should not occur right?
<mdnavare>
jekstrand made some fixes to the dma buf migrate code, any thoughts?
<agd5f>
mdnavare, probably the iGPU exports a buffer and the dGPU needs to import it and possibly copy it to something suitable for display
<agd5f>
mdnavare, there is no migration of a shared buffer
cef has quit [Quit: Zoom!]
<mdnavare>
agd5f: So in this case we are saying its one shared buffer in smem that just gets exported to lmem (part of it) for displayfrom vram
dviola has quit [Ping timeout: 480 seconds]
<agd5f>
mdnavare, export exports a buffer. Importer imports a buffer. It's the same buffer. If the importer can't scanout from the buffer directly, it needs to copy it to somewhere suitable
<agd5f>
the exporter is still potentially using the buffer
<mdnavare>
agd5f: If thats the problem, we should also see the problem when there is only one display that is connected to dGPU but iGPU still active so thats probably doing the composition
<mdnavare>
agd5f: Yes so in this case it wont be able to scanout on display connected to dgpu unless its copied to lmem/vram
<mdnavare>
wont this need migration once at attach time
shfil has joined #dri-devel
<agd5f>
mdnavare, there is no migration. the dGPU don't own the buffer
<mdnavare>
agd5f: But now if we force render on dgpu wont it own the buffer?
<agd5f>
if you render on the dGPU, you allocate memory on the dGPU and export it to the iGPU for import
<agd5f>
iGPU driver can either scan out directly or needs to copy it to suitable memory
<mdnavare>
yes in our case it needs a copy to smem
<mdnavare>
but i thought it will also need to be migrated to smem
<mdnavare>
since the buffer would have been allocated and owned by LMEM before since render was happening on dgpu
<agd5f>
The kernel driver probably forces buffers to smem when they are exported
dviola has joined #dri-devel
gouchi has quit [Remote host closed the connection]
nchery is now known as Guest4652
nchery has joined #dri-devel
<shfil>
bonjour, I like to do dumb refactoring. I'm not sure how critical are casts for mesa, so if they don't cause problems, then I can concentrate on something else.
<zmike>
anholt_: any idea when #5242 might have started? nothing has been merged for zink for a couple weeks, so there's kind of a big window
mbrost has quit [Ping timeout: 480 seconds]
Guest4652 has quit [Ping timeout: 480 seconds]
<anholt_>
I just noticed it happening today, didn't come up with any ideas
<zmike>
huh
<zmike>
weird since it's just softpipe and not llvmpipe too, which has seemingly similar rules
<zmike>
maybe MrCooper knows
cef has joined #dri-devel
<anholt_>
softpipe-rules at the top vs bottom of the list of extends?
<anholt_>
only guess I've had s ofar
<zmike>
don't think that's changed in a while though
<zmike>
or maybe I'm looking at the wrong one
mbrost has joined #dri-devel
<jekstrand>
bnieuwenhuizen: Oh, you do that too?
mbrost has quit [Remote host closed the connection]
<bnieuwenhuizen>
is it that surprising :)
<jekstrand>
bnieuwenhuizen: itoral asked for a tweak to my vk_image_view code to handle that case.
<jekstrand>
bnieuwenhuizen: We don't because we don't meta anymore
vup has quit []
vup has joined #dri-devel
<jekstrand>
bnieuwenhuizen: So not suprising but I didn't exactly expect it either.
<bnieuwenhuizen>
anyway, fix should allow you to move forward
dviola has quit [Remote host closed the connection]
<karolherbst>
ehhh
dviola has joined #dri-devel
mbrost has joined #dri-devel
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
ngcortes has joined #dri-devel
Plagman has quit [Server closed connection]
Plagman has joined #dri-devel
<alyssa>
cts-runner finished dEQP-GLES2 in 62 minutes.
<imirkin>
successfully, one hopes?
<alyssa>
Yes
<alyssa>
imirkin: Note that my `run-deqp` script finishes in 90 seconds on the same board.
<alyssa>
Single thread explains a 6x slow down, where is the other 7x slowdown coming from
<imirkin>
so you can extrapolate for gles3
<alyssa>
srsly.
<alyssa>
At these rates.. probably ~24h for a single config
<alyssa>
Not sure how many configs it will test
<imirkin>
i guess 7x slowdown from running 7 configs?
<imirkin>
(i dunno how many it runs. but many.)
<alyssa>
no, the tests themselves are running 7x slower than my surfaceless build from sept 2020
<imirkin>
oh. probably the window size is bigger?
dviola has quit [Ping timeout: 480 seconds]
<alyssa>
possible
pochu has joined #dri-devel
dviola has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
iokill has quit [Server closed connection]
iokill has joined #dri-devel
<mdnavare>
agd5f: Alex, you had mentioned earlier that with Wayland, it would just create device specif buffers and then we wont have this issue where same buffer needs to be pinned on smem and lmem in extended mode case for scanning out?
* airlied
has knocked 1/4 of the runtime off my CL conversions tests, I think that means maybe 4 days instead of 5 now :P
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa>
airlied: who wrote those tests exactly
<karolherbst>
alyssa: you have no idea how many tests those are
<karolherbst>
but CL also has like.... 400 conversion ops?
<airlied>
alyssa: someone interested in gatekeeping opencl against newcomers :-P
<karolherbst>
convert_T was a mistake
<karolherbst>
:D
<alyssa>
airlied: i just want my sticker so I can move on
<jenatali>
airlied: What'd you do?
alanc has quit [Remote host closed the connection]
mbrost has joined #dri-devel
alanc has joined #dri-devel
<karolherbst>
alyssa: if you want I can send you stickers
<alyssa>
karolherbst: do they say "conformant driver" and "Panfrost" on them? :-p
<karolherbst>
they can if you want them to be
<karolherbst>
s/be//
<airlied>
jenatali: rewrote the llvmpipe compute shader threadpool was step one, it was naive when you submitted 49000 work items to 8 threads
<jenatali>
That'll do it
<karolherbst>
alyssa: know they envytools logo?
<airlied>
yeah mutex lock/unlock overhead was quite high
<airlied>
jenatali: but also I used llvm coroutines to implement barriers in compute shaders, and it hits malloc/free really hard on each coroutine launch
<karolherbst>
I can give you something in a similiar style :D
<mwk>
it's a very fitting logo
<airlied>
llvm has in theory a pass to "fix" that, but the way I'm using coroutines won't allow it to trigger
<jenatali>
Yeah and that'll give you another set of lock/unlock ovehread
<airlied>
esp when it's 24 bytes per malloc/free :-P
<karolherbst>
the heck
<karolherbst>
maybe we should have written a CL to nir parser afterall
<airlied>
I can do a workaround in mesa by preallocating, but I have to hard code the size and hope llvm doesn't change it
<alyssa>
karolherbst: :v
<alyssa>
airlied: is this llvm on the way in or llvm on the way out
<karolherbst>
alyssa: well apparently MS figured out that JITs aren't that great so they disable JITing in edge :D
<airlied>
alyssa: way out
<jenatali>
Yeah we built a service that runs our JIT for WARP
<karolherbst>
but I guess for GL it is still good enough?
<karolherbst>
jenatali: ahh :D
mbrost has quit [Remote host closed the connection]
<karolherbst>
I hope nobody sees nir and thinks they can use it for CPUs
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
HdkR: Watching linux boot in verbose mode on an odroid go advance is such a weird experience
pcercuei has quit [Quit: leaving]
<HdkR>
alyssa: oh?
<HdkR>
Because of the screen rotation?
xexaxo_ has quit [Ping timeout: 480 seconds]
<alyssa>
HdkR: Just the game consoleness :-p
<HdkR>
ah
dj-death has quit [Server closed connection]
dj-death has joined #dri-devel
fahien2 has quit [Server closed connection]
<mdnavare>
daniels: You mentioned that Wayland compositor unline X should be able to handle per CRTC buffers in case of extended mode on Hybrid Gfx system?
fahien2 has joined #dri-devel
dviola has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
dviola has joined #dri-devel
<mdnavare>
daniels: Apparently our driver is failing to do the import on dgpu from igpu in this case but we are trying with X11 compositor , do you think this will be fixed with Wayland or we need some kernel driver changes here to handle this?
shfil has quit [Quit: Konversation terminated!]
<Sachiel>
even if it works in wayland, I suspect we still want it to work in X11 for the foreseeable future
dongwonk has quit [Remote host closed the connection]
iive has quit []
<jekstrand>
Did gitlab just go down?
<icecream95>
it seems to have
jhli has joined #dri-devel
<alyssa>
aw, now I can't procrastinate by reviewing other people's drivers
<airlied>
just go review all the kernel patches in your email :-P
* jekstrand
was just about to send a comment that even included a fancy table!
<icecream95>
airlied: But if the kernel migrates to using Gitlab too, then...
<airlied>
I think it cmae back
<HdkR>
Is the kernel talking about switching to Gitlab?
<airlied>
HdkR: no we are talking about switching piece of it to gitlab
<jenatali>
"The CL CTS conversions test is horrible" - couldn't agree more
ella-0 has quit [Read error: Connection reset by peer]
robertfoss has quit [Server closed connection]
robertfoss has joined #dri-devel
<mdnavare>
daniels: Sachiel: agd5f: airlied: Does this use case work on AMD iGPU + AMD dGPU where displays are connected on both igpu + dgpu and the extended/ clone mode works?
craftyguy has quit [Remote host closed the connection]