ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Daanct12 has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
Daanct12 has quit []
idr has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
YuGiOhJCJ has joined #dri-devel
jernej has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
GloriousEggroll has quit [Quit: Death is life's way of telling you you've been fired.]
heat has joined #dri-devel
Emantor has quit [Quit: ZNC -]
Emantor has joined #dri-devel
tarceri_ has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
Lightkey has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 481 seconds]
cef has quit [Quit: Zoom!]
Lightkey has joined #dri-devel
cef has joined #dri-devel
soreau has quit [Quit: Leaving]
soreau has joined #dri-devel
soreau has quit [Quit: Leaving]
soreau has joined #dri-devel
boistordu_old has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
curro has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
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 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
<danvet> karolherbst, oh where?
<robclark> ok, I'll take a look at that
<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> yeah..
<danvet> yeah leaf symbols
<karolherbst> robclark: it's a token on the repo
<karolherbst> robclark: but yeah
<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]
Duke`` has joined #dri-devel
greaser|q is now known as GreaseMonkey
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has quit [Ping timeout: 480 seconds]
flto has quit [Ping timeout: 480 seconds]
flto has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
iive has quit []
K`den is now known as Kayden
pcercuei has quit [Quit: dodo]
Stary_ has quit []