Peste_Bubonica has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
curro has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Duke`` has joined #dri-devel
bcarvalho_ has quit []
vivijim has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
pekkari has joined #dri-devel
<ishitatsuyuki>
editorconfig says 4 space indent for *.py but nir_opt_algebraic.py is 3-space indent... i'm itched
camus has joined #dri-devel
gouchi has joined #dri-devel
blue__penquin has joined #dri-devel
vpandya has joined #dri-devel
danvet has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
rasterman has joined #dri-devel
gruetzkopf has quit [Remote host closed the connection]
iive has joined #dri-devel
gruetzkopf has joined #dri-devel
gruetzkopf is now known as Guest1346
Thymo has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
K`den has joined #dri-devel
Kayden has quit [Remote host closed the connection]
Duke`` has quit []
Duke`` has joined #dri-devel
blue__penquin has quit [Quit: Connection closed for inactivity]
<ishitatsuyuki>
anyone know whether using a buffer over 4GB has defined behavior in SPIR-V?
<ishitatsuyuki>
I know that RADV has known overflow issues with allocating large buffers (and therefore disables such allocation) but wonder whether the hardware side can handle that
<bnieuwenhuizen>
ishitatsuyuki: wrt AMD hardware, the bound for bounds checking of a buffer is a 32-bit register
<ishitatsuyuki>
:(
<ishitatsuyuki>
yeah just discovered that
minecrell has quit [Quit: :( ]
<ishitatsuyuki>
perhaps there are other ways to access the buffer without hitting this limit? I'm looking at VK_KHR_buffer_device_address right now
<bnieuwenhuizen>
yeah anything where robustness doesn't apply is ok
<bnieuwenhuizen>
though the difficulty is exposing that
<ishitatsuyuki>
i'll try and see, thanks
alyssa has left #dri-devel [#dri-devel]
minecrell has joined #dri-devel
NiksDev has quit []
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
heat has joined #dri-devel
tobiasjakobi has joined #dri-devel
GreaseMonkey has quit [Quit: No Ping reply in 180 seconds.]
greaser|q has joined #dri-devel
<jekstrand>
daniels: WFM. I assume this is in my e-mail somewhere? Lore link?
ickle has quit [Ping timeout: 480 seconds]
pochu has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
sarnex has quit [Quit: Quit]
sarnex has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
pekkari has quit [Quit: Konversation terminated!]
lemonzest has quit [Quit: Quitting]
vpandya has quit [Quit: Connection closed for inactivity]
<daniels>
danvet: ^
<danvet>
jekstrand, ?
<danvet>
daniels, thx :-)
<daniels>
:)
<robclark>
airlied, danvet: do you think we could get away with drivers/gpu/drm/<driver>/.gitlab-ci.yml and related bits? Or will we have to keep *all* CI bits somewhere else?
<danvet>
robclark, I guess depends, but I'd say we should stuff them into drivers/gpu
<danvet>
per-tree build testing and all that makes very little sense imo, the rules are already fragmented enough
<robclark>
yeah, I expect there will be some parts that could (at least eventually) be moved up a level and shared by all drivers
<robclark>
but need to start somewhere
<danvet>
imo start in drivers/gpu, but with the msm stuff
<danvet>
or whoever is first :-)
<danvet>
that way hopefully we can start collaborating and improving stuff from the start
<robclark>
ok, I suppose at least some of the build testing could be common.. I think some may be driver specific, like what happens when certain snapdragon related drivers are not enabled in config
<danvet>
also pretty simple to do build rules that only trigger on msm or include/drm changes
<robclark>
main question was more just whether I have to keep all ci stuff out of master and figure out how to fetch it somehow
<danvet>
robclark, the idea I had but never played with is we start with an arch defconfig
<danvet>
and then a list of kconfig to enable
<danvet>
and then maybe just try to enable everything under drivers/gpu or something like that
<danvet>
eventually
<danvet>
with the manual list just dependencies outside of drivers/gpu
<danvet>
robclark, karolherbst is also interested in this for nouveau
<danvet>
also, I think the first round should be a separate pull request
<danvet>
so that linus doesn't freak out, just in case
<robclark>
ok, would be interesting to see what nouveau is up to
<karolherbst>
robclark, danvet: I just merged the stuff for nouveau
<karolherbst>
at least that's what I had in mind on how to do kernel level CI for now
<karolherbst>
or at least do some testing on MRS
<karolherbst>
*MRs
<karolherbst>
and only the kernel config is really nouveau specific
<robclark>
ok, so you are going the route of having it all out of tree?
<danvet>
I mean a few years back I brought up the idea of gitlab CI at lpc
<karolherbst>
so we could have a global repo with all that stuff + driver specific configs
<danvet>
and people didn't freak out
<karolherbst>
robclark: how else?
<danvet>
karolherbst, drivers/gpu
<karolherbst>
mhhhh
<danvet>
I think we should be able to get away with that
<robclark>
yeah, in tree, but not at top level
<karolherbst>
danvet: yeah.. but then making changes is a bit annoying, but sure
<karolherbst>
we _could_ do that
<robclark>
so we could, for example, as we add new hw support, add new tests
<danvet>
well drivers/gpu/.gitlab-ci and .gitlab-ci.yaml
<danvet>
karolherbst, well plus side is that source and CI rules stick together
<karolherbst>
danvet: maybe we should focus on that for drm-misc?
<danvet>
so eventually when we add something, you can fix up ci too
<karolherbst>
but yeah.. that would help with CIing the CI script
<danvet>
karolherbst, I'm flooded, so I'm not going to be first
<karolherbst>
danvet: I already kind of agreed to looking into it although I am alsoa bit flooded with.. other stuff
<danvet>
but if you and robclark can get something started (even if it's just nouveau + msm and all hacked up)
<danvet>
we can do a topic pull for that and see
<karolherbst>
yeah
<karolherbst>
I mean.. the script itself is good enough
<karolherbst>
for msm you really jsut need to adjust the kernel config
<robclark>
I'd be down w/ merging CI stuff (at least initial stuff) via drm-misc.. that is jumping about 3 steps ahead (ie. need to get something working first).. just wanted to make sure the idea of having stuff in-tree wasn't a non-starter
<karolherbst>
robclark: right
<danvet>
yeah drm-misc is 3 steps ahead
<karolherbst>
if you got time you can play around with it
<danvet>
I'd say step 1) get something going step 2) merge it with topic branch to linus under drivers/gpu or so
<karolherbst>
I just focused on getting at least some CI working
<robclark>
anholt: jfyi, so you don't miss it in scrollback (since we were talking about this the other day) ^^^
<danvet>
step 3 get drm.git to use that so airlied & me stop failing at compile testing so much :-)
<danvet>
then maybe step 4 drm-misc
<karolherbst>
second step would be to allow driver specific configs
<karolherbst>
*next
<danvet>
karolherbst, i'd go with arch specific
<danvet>
like defconfig + symbols we should add
<karolherbst>
ahh
<danvet>
eventually with some scripts that auto-add everything
<karolherbst>
yeah, that's better for more global CI of course
<karolherbst>
danvet: that's impossible sadly
<danvet>
at least iirc in mesa we also don't have a build target for each drivers, but a bunch of combos
<karolherbst>
Kconfig is a piece of shit
<karolherbst>
seriously
<danvet>
karolherbst, oh sure
<danvet>
fully automagic it's impossible
<karolherbst>
even just enabling drivers doesn't help because.... weird deps or something
<karolherbst>
and kconfig just doesn't enable shit on its own
<danvet>
but I think manual list of symbols outside of drivers/gpu + automagically trying to enable everything inside should be pretty close
<danvet>
yeah
<karolherbst>
mhhh
<danvet>
if it's not fulfilled, it'll disable again
<karolherbst>
doubtful
<danvet>
and then the icing on the cake
<karolherbst>
yeah.. I mean you can try
<karolherbst>
I just don't see it working out
<danvet>
check across all configs&arch whether each driver was enabled at least once
<danvet>
and fail that check target if not
<danvet>
that way we can reject a pull if it forgets to add it's deps to the build target
<danvet>
and make sure all drivers are always build-tested at least somewhere
<danvet>
but that's like step 20 :-)
<karolherbst>
well
<karolherbst>
I do check if the configs are enabled in that list
<karolherbst>
so if you miss to add deps after pulling a new kernel version it will fail
<karolherbst>
well.. if that disables configs within that list
<danvet>
yeah it needs to be manual like this
<karolherbst>
so it's already in there, you just have to list the configs we require and kconfig is too stupid do enable it on its own
<karolherbst>
k
<danvet>
I just figured what we could do eventually to make sure all the random new drivers are tested mostly automatically
<karolherbst>
mhh yeah...
<danvet>
but because some drivers work only in some configs/arch
<karolherbst>
danvet: we could habe a "DRM_ALL_DRIVERS" config?
<karolherbst>
other subsystems have similiar things
<danvet>
you can only then do that check in another build test
<karolherbst>
so you either enable all or the ones you want
<danvet>
karolherbst, I feel like the symbol list like you have it, eventually in a per-target file or so, is cleaner
<karolherbst>
okay
<danvet>
like Kconfig select is already extremely hairy
<karolherbst>
we can also merge those in the CI I guess
<karolherbst>
shouldn't actually prevent anything as long as there are no conflicts
<karolherbst>
which we don't want to have anyway
<danvet>
yeah that's why a drivers/gpu/.gitlab-c/ directory
<karolherbst>
okay
<robclark>
we probably do want to have some semi-driver-specific config.. doesn't have to be completely driver specific, I think in mesa-ci we are using same kernel build on most of the runners
<danvet>
robclark, yeah per-arch
<karolherbst>
in the end I vote for whatever works :p
<danvet>
or maybe some combos
<danvet>
like FBDEV=n
<danvet>
or BACKLIGHT=n
<robclark>
(and eventually, it would be good for at least one of the build outputs to be fed into jobs that run tests on real hw)
<danvet>
those tend to be fun :-)
<robclark>
DEBUG_FS=n
<danvet>
so maybe a handful
<danvet>
oh yes
<danvet>
maybe 2 per arch
<karolherbst>
danvet: sometimes I think we should just force those things tbh.. like just require BACKLIGHT
<karolherbst>
because.. what the hell do you want to even disable it
<danvet>
one with all these optional things enabled, the other with all of them disabled
<karolherbst>
*wjy
<karolherbst>
*why
<danvet>
that should catch most crap
<danvet>
karolherbst, yes, unfortunately that's a hill I routinely die on
<karolherbst>
:(
<danvet>
like I can at least stop total nonsense like Kconfig for 2 new functions within drivers/gpu
<karolherbst>
guess somebody comes around and say "but I need ACPI=n" or something?
<danvet>
but outside of drivers/gpu those micro-config knobs are way too popular :-(
<danvet>
yeah
<karolherbst>
... *sigh*
<danvet>
or it's an appeasement trick to get something landed
<danvet>
"you can disable it"
<karolherbst>
...
<karolherbst>
maybe we should just require it per driver and once all require it, we can just say "distributions have to enable it anyway"
<karolherbst>
:D
<danvet>
karolherbst, we can't
<karolherbst>
:(
<danvet>
Kconfig can't express that well
<karolherbst>
well I can require BACKLIGHT inside nouveau, can't I?
<danvet>
or well, the tooling is shit
<danvet>
yeah, but if someone disables backlight
<karolherbst>
then no nouveau
<danvet>
nouveau wont even show up
<danvet>
it's very user-unfriendly
<karolherbst>
there is a way to auto select deps
<karolherbst>
there is both...
<danvet>
never found that?
<robclark>
"MR comment bot" is nice.. is that a gitlab feature?
<karolherbst>
danvet: for some stuff it works
<karolherbst>
trust me, I used gentoo :p
<danvet>
karolherbst, maybe gentoo has something?
<karolherbst>
no
<karolherbst>
I saw it also when working on the CI for nouveau
<danvet>
or if there is, please tell me?
<karolherbst>
some things get auto enabled, some don't
<danvet>
oh we sprinkle select around
<karolherbst>
yeah
<danvet>
but select is extremely dumb
<karolherbst>
it is
<danvet>
if force-enables the option
<danvet>
so you either need to select recursively
<danvet>
or it's just busted
<karolherbst>
the problems are if the deps have long || chains I think in their deps
<danvet>
also kconfig gets pissed if you make loops like that
<karolherbst>
so it doesn't work for a lot of things :/
<danvet>
I thought even if not, it just fails
<karolherbst>
yeah.. probably
<danvet>
like if you select DRM_FBDEV_EMULATION or whatever it was
<karolherbst>
point is.. for _some_ things, it works
<danvet>
and that selects FBCON
<danvet>
then you just fail and fbcon isn't enabled
<karolherbst>
project -> Settings -> Access Tokens and it needs "api" scope
<robclark>
k
<karolherbst>
_but_
<karolherbst>
that's a reason to not have the CI files inside the repo
<karolherbst>
because....
<karolherbst>
users have access to that damn "api" scoped token
<karolherbst>
and I am not sure how much of a sec risk that would be
<karolherbst>
so we would need a different solution for a bot like that commenting the results
<karolherbst>
*posts
<karolherbst>
at least that's one of my concerns
<robclark>
hmm, ok.. well the rough idea was to have toplevel .gitlab-ci.yml in a separate tree, and have that be pretty minimal, but include drivers/gpu/.gitlab-ci.yml
<danvet>
hm not sure we need such a bot when it's integrated?
<karolherbst>
I like the idea of a bot posting infos like this, but worst case we just have hooks and some python script running somewhere
<karolherbst>
danvet: the idea was that users don't have to check the logs or something dumb like that, but.. maybe we can require users to check that on their own :P
<danvet>
gitlab does tell you in the MR whether it all passed
<karolherbst>
I just liked the idea of making it a bit nicier for first time contributors
<robclark>
I guess in the end, all the info is there in a MR with some clicking, but avoiding a bunch of clicking is nice
<danvet>
karolherbst, well there's the nice red/yellow/green stuff
<karolherbst>
yeah sure...
<robclark>
anyways, that is more of bell&whistle
<karolherbst>
but you have to say that the comment bot is indeed nice :p
<danvet>
karolherbst, imo that's already massively better than 0day sending you rant mails into some random inbox
<danvet>
karolherbst, it is pretty
* robclark
would like comment bot for mesa
<karolherbst>
:p
<danvet>
karolherbst, we can't have the bot just limited to allowing comments?
<karolherbst>
nope
<karolherbst>
danvet: _maybe_ if we use a user
<danvet>
hm yeah Maintainer role is a bit much
<karolherbst>
so a real account with no access rights
<karolherbst>
that might work
<karolherbst>
but still.. you have this token and could maybe even remove this account if you are angry with drm folks or so
<karolherbst>
or do other random stuff
<danvet>
yeah but there's already plenty of abuse potential with CI
<danvet>
like just burning down endless amounts of machine time
<karolherbst>
ohh sure
<danvet>
but yeah if the comment bot could be just a user, that would be better
<danvet>
karolherbst, tbh I don't even know what exactly that special membership is
* danvet
not much clue
<danvet>
on gitlab ci
<karolherbst>
"special memberhip"?
<danvet>
yeah like the MR comment bot
<danvet>
or the CI token
<karolherbst>
it's a project Access token
<danvet>
oh
<danvet>
it's also in the members list
<karolherbst>
yeah
<karolherbst>
it gets auto added/deleted
<danvet>
real account like Marge, but for the kernel, maybe better
<danvet>
and then more limited access
<karolherbst>
yeah
<danvet>
"Friendly Linus" or so :-)
<karolherbst>
:D
<karolherbst>
in case people to indeed abuse this bot (by renaming it or whatever) we can always do a real bot and just have URL hooks to trigger comments or so..
gouchi has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
ZeZu has joined #dri-devel
Duke`` has quit [Ping timeout: 481 seconds]
tobiasjakobi has quit [Remote host closed the connection]