ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa> GenXML question, if you have a helper function that's only needed on certain arches, is it better to #if ARCH it, or mark it UNUSED?
<alyssa> (To quiet -Wunused-functions)
<alyssa> Kayden: ^
<Kayden> both are good
<Kayden> I like UNUSED if it's something fairly simple, it just isn't needed
<Kayden> if it's something totally specific to one gen, ifdef can be good too
<Kayden> (thinking...if the helper queries some info, and the other gens just don't -need that-, then UNUSED...if it's some totally HW specific thing, ifdef)
<Kayden> ah
<Kayden> sometimes I also ifdef out the insides of functions
<Kayden> and mark it UNUSED
<Kayden> that way the callers don't need to ifdef, too
<Kayden> I'd say do whatever seems the most natural to you :)
<alyssa> Okey
<alyssa> I'm not used to so much #ifdef :-p
<alyssa> Thanks :)
<Kayden> Yeah, it takes a bit of getting used to :(
<alyssa> OTOH I do like that a huge amount of copypaste and extra indentation levels go away
<alyssa> GenXML is compiler-assisted copypaste but still
<Kayden> Yep. In the end, it does end up being a lot less duplicated crap
<Kayden> but there's definitely some artistic taste in "I should really just ifdef this whole function" vs ifdef'ing pieces of it
<Kayden> one of my favorite pieces is src/mesa/drivers/dri/i965/genX_state_upload.c:1166
<Kayden> where I have the same code able to pack into 3 different hardware structs via the use of typedef XD
<Kayden> because they all have the same fields, they just keep moving them all over the place
<alyssa> Heh
<Kayden> we also have a few cases of things moving between registers, so we just #ifdef #define WOTS_IT_CALLED REG1 #else #define WOTS_IT_CALLED REG2 #endif
<Kayden> that way things can match the actual docs but the code doesn't have to get pointlessly duplicated
<alyssa> Nod
tursulin has quit [Read error: Connection reset by peer]
<Kayden> of course, if you're RE'ing and naming things whatever you want, then ... :D
<alyssa> Benefits of not having actual docs ;D
<zmike> #define MY_FIRST_REGISTER 1
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
gpoo has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
sdutt_ has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gpoo has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
boistordu has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
anujp has joined #dri-devel
xcube has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has quit [Read error: Connection reset by peer]
anujp has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
tzimmermann has joined #dri-devel
itoral has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
mlankhorst has joined #dri-devel
Hi-Angel has joined #dri-devel
tobiasjakobi has joined #dri-devel
Anorelsan has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
aravind has joined #dri-devel
ced117_ has joined #dri-devel
danvet has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<tzimmermann> danvet, airlied, there are still patches in -misc-fixes from last cycle. i'd send them now. and for the -rc1 update, can you forward drm-fixes, so i can backmerge?
frieder has joined #dri-devel
<danvet> mripard, ^^ if you miss the merge window cut-off make sure your last -fixes lands in the merge window pull request and doesn't get lost
<danvet> tzimmermann, pushed drm-fixes to -rc1
<danvet> thx for taking care of this
<airlied> danvet: I pushed fixes/next to rc1 already I thought
<danvet> airlied, indeed
<danvet> or at least git says it's up-to-date now
* danvet didn't look that closely
Ahuj has joined #dri-devel
rasterman has joined #dri-devel
<MrCooper> karolherbst: yay qemu
<tzimmermann> danvet, can i delete tags from drm-misc?
pochu has joined #dri-devel
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
mlankhorst has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
* icecream95 thinks there might be a bug around handling of LTO
<icecream95> $ ls -sh src/gallium/targets/dri/
<icecream95> 8.0K src/gallium/targets/dri/
<HdkR> That's an efficient driver
<tzimmermann> danvet, nevermind
<icecream95> I guess it would help if I used the right linker (I set /bin/ld -> ld.lld)
frieder has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
thelounge78 is now known as alatiera
<karolherbst> MrCooper: I doubt it's a qemu issue though :D on x86 it takes like 3 seconds
<karolherbst> I think it's just broken on s390x and it loops infinitly
<MrCooper> doubtful
<MrCooper> llvmpipe may hit some SIMD code which is expensive to emulate
<MrCooper> I think these tests are pretty slow for other archs via qemu as well
<karolherbst> I don't think so, because those tests didn't timeout earlier. My assumption is, that we changed something in the format code and the code can't deal with it... but I can take a loop and verify :)
<MrCooper> earlier when? qemu was upgraded from 3.1 to 5.2 on the CI runners a while ago
<karolherbst> locally
<karolherbst> at some point
camus has joined #dri-devel
<pq> tzimmermann, deleting (or changing) git tags is not a thing. The deletion does not propagate to anyone who already saw the tag.
<danvet> tzimmermann, s/severla/several/ in your vgem patch
<danvet> if you haven't pushed it out yet
<tzimmermann> pq, i always git-fetch with --prune. should delete the tag. but it doesn't matter anyway. i used the existing tag for the pull mail
<tzimmermann> danvet, thanks
camus1 has quit [Ping timeout: 480 seconds]
sravn has quit [Ping timeout: 480 seconds]
<pq> tzimmermann, most people don't do that I would think, and you would need to use --prune-tags for tags. And will lose your local tags.
sravn has joined #dri-devel
sravn_ has joined #dri-devel
sravn has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<pq> What should a KMS device be displaying when there is no fbcon on it, and the last KMS client quits?
<pcercuei> it should turn the hardware OFF, no?
<emersion> it should keep displaying the last frame?
flacks has quit [Quit: Quitter]
<emersion> (required for the so-called "flicker-free boot experience")
<pq> AMD on 5.10.0 kernel from Debian Bullseye shows a stripey pattern. Maybe unused memory. :-)
<pq> I wonder if I'm blinded once I get Weston to turn on HDR on that...
flacks has joined #dri-devel
iive has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
Company has joined #dri-devel
phomes has quit [Quit: Page closed]
<tzimmermann> danvet, airlied, there are still patches left in drm-misc-next-fixes. do you want the PR against drm-next or drm-fixes ?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Simon_ has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Simon_ has quit [Remote host closed the connection]
nirmoy has joined #dri-devel
vivijim has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
sdutt has joined #dri-devel
camus1 has quit [Remote host closed the connection]
sdutt has quit []
sdutt has joined #dri-devel
camus1 has joined #dri-devel
<danvet> tzimmermann, drm-fixes, since that's where they should head towards
<danvet> tzimmermann, or just merge them all into drm-fixes and do one overall pull
<danvet> *drm-misc-fixes
<danvet> that also avoids having to stall that tree
<tzimmermann> danvet, merging into -misc-fixes will mess up the history until -misc-fixes has been forwarded to -rc1
<tzimmermann> and there's already a PR for the rest in -misc-fixes
* tzimmermann thinks these transitions among trees are way too complicated
<danvet> tzimmermann, another approach would be a release branch, and somehow figuring out which one to push automatically for linux-next
<danvet> tzimmermann, can't you just backmerge -rc1 into drm-misc-fixes
<danvet> and then merge drm-misc-next-fixes into that too?
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
<danvet> tzimmermann, worst case the same stuff gets merged into drm-misc-fixes and into drm.git, which hurts no one
<danvet> also someone might push another bugfix meanwhile
Anorelsan has quit [Quit: Leaving]
<tzimmermann> danvet, that creates a merge commit in -misc-fixes with the full merge window. that's really ugly
<danvet> tzimmermann, seems ok imo
<tzimmermann> i'd rather backmerge drm-fixes after the current PR got merged
<tzimmermann> it should be a nice fast-forward merge
<danvet> ok I'll do this to unblock further pathces
<danvet> feels a bit over the top ocd, but whatever :-)
<danvet> tzimmermann, btw dim status is kinda meant to catch these kind of fumbles before they block progress
<danvet> mripard, mlankhorst ^^
<tzimmermann> danvet, airlied, mripard, mlankhorst, could we write-protect certain trees at specific times?
<danvet> tzimmermann, that doesn't feel any better, just increases the odds that patches get lost
<danvet> just do more merges imo
<danvet> tzimmermann, pull is build testing now, should go out in a while or so
<tzimmermann> danvet, thank you
<danvet> tzimmermann, pls also apply that bugfix I cc'ed you on and already forgot about myself :-)
<danvet> tzimmermann, but next time around just merge it all together, or better get the pull requests out earlier
<danvet> if there's anything stuck somewhere
<tzimmermann> danvet, airlied, mripard, mlankhorst, or have a train model, where we branch from drm-misc-next after every -rc6
<danvet> tzimmermann, yeah, but like I said that needs some typing in the scripts
<danvet> and maybe retraining committers
<tzimmermann> danvet, the problem is: last thursday, -misc-next-fixes was empty
<danvet> otoh they get it wrong anyway :-)
<danvet> tzimmermann, oh that happens all the time
<tzimmermann> and then 3 patches were commited in the last minute, or so
<danvet> you can't fix that with a write block, because then people will either a) forget about the patch or b) push it to drm-misc-next
<danvet> tzimmermann, yeah, it's the live of drm-misc
<danvet> just do the occasional merge
<tzimmermann> there's no way i can send out PRs later than thursday
<danvet> yeah, totally fine
<danvet> like I said, just merge it together and that should take care of things
<danvet> I mean we also need to sometimes cherry-pick patches around because they're misplaced
<tzimmermann> danvet, well ok. after -misc-fixes has been forwarded, i'll merge -misc-next-fixes and send out another PR. probably tomorrow
<danvet> really not bad, as land as stuff lands and doesn't get lost
<danvet> tzimmermann, ack
* danvet watching the script meanwhile
<tzimmermann> cherry-picking is terrible for distros :) i have to backport patches into suse kernels and i often run into duplicates
<tzimmermann> but detecting duplicates is not as easy as it sounds
<danvet> well cherry-pick -x should always be used
<danvet> even if it pisses of Linus "this isn't a sha1 I have" Torvalds
<danvet> exactly because otherwise it becomes even more pain for downstream consumers
karolherbst has quit [Remote host closed the connection]
<alyssa> > Linus "this isn't a sha1 I have" Torvalds
<tzimmermann> yeah, that option helps
<alyssa> I don't think I've read this one, link? 🍿
<danvet> tzimmermann, it's still annoying, but at least a bit better
<danvet> alyssa, I think it was actually mostly gregkh
karolherbst has joined #dri-devel
<danvet> tzimmermann, pull landed
jewins has joined #dri-devel
jewins has quit []
jewins has joined #dri-devel
<jekstrand> Why is git suddenly suggesting I make GitHub PRs?
<jekstrand> daniels: ^^
<daniels> jekstrand: I don't know, need more context
<HdkR> Is the remote a github remote? It has some post-push server side messaging to quickly create a PR
<jekstrand> Seems I pushed my branch to the main repo instead of my private one.
<jekstrand> And that caused an auto-push to the GitHub mirror which suggested I create a PR
<daniels> oh, on push, right
<daniels> presumably it's prefixed remote: remote: remote:
<jekstrand> I'm less freaked out now. :)
<daniels> (gitlab -> anongit -> github)
<jekstrand> Yeah, it is
* jekstrand is clearly not awake yet (-:
<bnieuwenhuizen> jekstrand: I downgraded my remote for the main repo to use https, so I can't make that mistake
<jekstrand> bnieuwenhuizen: I probably should delete my "public" remote, honestly.
<jekstrand> I occasionally have to use it to do maintainery things but it's been quite a while since I actually needed it.
<jekstrand> karolherbst: Does the nouveau GLSL IR back-end still exist or is nouveau all NIR these days?
heat has joined #dri-devel
<karolherbst> jekstrand: it still exists
<alyssa> jekstrand: there's a TGSI backend
<alyssa> i thought
<karolherbst> ehh glsl ir?
<karolherbst> mhhh
<karolherbst> jekstrand: soo... the gallium driver is either tgsi or nir
<karolherbst> _but_
<karolherbst> we have this classic driver to pre nv30 GPUs
<karolherbst> but those are all fixed pipeline
<karolherbst> nv30 has its own backend consuming TGSI
<karolherbst> and it can't do nir
<karolherbst> nv50+ can potentially be nir
<karolherbst> volta+ is nir only
<karolherbst> the problem really is nv30 as it has its own compiler
urja has quit [Read error: Connection reset by peer]
<karolherbst> well.. it's more an assembler than a real compiler
urja has joined #dri-devel
<jekstrand> karolherbst: I was hoping to delete some compute-specific GLSL IR passes
<karolherbst> mhhh
<karolherbst> which ones?
<karolherbst> at least compute is nv50+ only
<karolherbst> so we could move bits into codegen
<jekstrand> lower_cs_derived and lower_shared_reference
cphealy_ has joined #dri-devel
<jekstrand> Not worth moving into nv50
<karolherbst> mhh
<karolherbst> hh wait
<jekstrand> Oh, and lower_64bit_integer_instructions
<karolherbst> jekstrand: uhhh
<karolherbst> mhh
<karolherbst> that 64 bit is annoying
<karolherbst> mhh
<karolherbst> I wish I'd have more time for all of this :(
<karolherbst> (or have other people working on that stuff)
<jekstrand> karolherbst: Yeah, nouveau seriously needs more devs
<karolherbst> at least I managed to fix multithreading....
<karolherbst> but that meant doing nothing else for a long time :(
<karolherbst> but yeah...
cphealy has quit [Ping timeout: 482 seconds]
<karolherbst> no good idea on how to tackle that really :/
<karolherbst> documentation is crappy, sure.. hard to get into the topic, true, and companies hiring our devs :P
<karolherbst> not a good starting point
<jekstrand> Yeah
<jekstrand> Most people who work on nouveau tend to get hired.
<karolherbst> yeah...
<karolherbst> I just got lucky getting hired by RH :p
<jekstrand> Good thing RH is willing to fund it some
<karolherbst> well.. yeah...
<karolherbst> kind of
<jekstrand> I said "some" :)
<karolherbst> jekstrand: the problem is.. officially I don't work on nouveau stuff :)
<jekstrand> RH funds it more than Nvidia does. :P
<karolherbst> true
<karolherbst> so.. my official responsibility is multi arch, but I do nouveau stuff, because I don't have to spend 100% of my time on multi arch :D
<karolherbst> oh well...
<karolherbst> I think Ben is the only one doing it for real, and then mainly hw enabelement
<karolherbst> just the CL stuff was "special"
<karolherbst> this just fitted into that nvidia HMM stuff, as an open source userspace impl had to be provided and so on
<karolherbst> and I was like: okay.. I know exactly what I want to do for that: nir for nouveau and that clover spirv/nir stuff :P
<jekstrand> Someone's got to work on realizing airlied's grand compute plans. :)
<karolherbst> :D
<karolherbst> yeah...
<karolherbst> I wished I had a bit more time for that honestly
<karolherbst> but I do care more about nouveaus graphics bits than the compute parts honeslty
<jekstrand> I'm just glad that your work, the MSFT stuff, and my RT work all came together at the same time.
<alyssa> "nvidia HMM stuff, as an open source userspace impl had to be provided"
<alyssa> that's what that was about?!
<karolherbst> alyssa: yep.. :D
<karolherbst> funny isn't it?
<alyssa> :V
<karolherbst> I thought I make the best out of it :D
anujp has joined #dri-devel
<karolherbst> which I think I managed to do :D
<karolherbst> pierre kind of started that CL stack for nouveau by doing spirv to codegen and I was like: nah.. let's trash that approach :D
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
<alyssa> vtntn
<karolherbst> hey there was another idea: llvm to TGSI
<karolherbst> :D
<alyssa> where do you come up with these ideas
pendingchaos has joined #dri-devel
<karolherbst> this was before nir even existed
<karolherbst> like 2016?
<karolherbst> or so
<karolherbst> ehh
<karolherbst> I think nir was already there
<karolherbst> but...
<karolherbst> it was all messy at that time
<karolherbst> and every path meant a lot of work
<karolherbst> oh well... doesn't matter :D
<karolherbst> I think I made not the worst choice here :p
<marex> hey, I was wondering about the kernel display pipeline design and backlight handling
<marex> so when the pipeline comes up, the backlight is turned ON first thing, and then the scanout engine starts pushing data out (e.g. on DPI)
<marex> but that might lead to flicker on some panels which expect data available before backlight is enabled
<marex> is there any sane way to swap the order of enablement ?
<marex> i.e. data first, backlight second ; instead of ; backlight first, data second ?
cphealy_ has quit [Ping timeout: 480 seconds]
<marex> danvet: ^
<marex> anholt: ^
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
<danvet> marex, that sounds like a bug somewhere
<danvet> or maybe you're using fbdev
<danvet> bug in the display driver I mean
<marex> danvet: mxsfb in fact, that is drm simple-pipe derivative
<marex> danvet: btw unrelated, but could you pick the ACKed mxsfb patches posted to dri-devel ? They are fixes and would be nice if they were not left to rot
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
<marex> danvet: the mxsfb starts the display, which starts the backlight, first , and only then it can start scanning out data, once mxsfb is done probing
<lynxeye> marex: Aren't you one of the maintainers of mxsfb-drm?
<marex> lynxeye: I think it is somehow delegated to drm-misc ; are you suggesting I apply my own patches ?
<lynxeye> Your ordering issue must be a bug in mxsfb. Normally you do panel_prepare -> do modeset to driver pixel data -> panel_enable
<lynxeye> Only the panel_enable enables the backlight connected to the panel.
<lynxeye> marex: You are listed as maintainer of this driver and since it's in drm-misc, you should be able to push your own patches, once they are acked/reviewed.
sneil__ has quit []
rgallaispou1 has left #dri-devel [#dri-devel]
anujp has quit [Ping timeout: 480 seconds]
<tzimmermann> danvet, -misc-fixes should now be ready for your patch
<marex> lynxeye: except the backlight is enabled already during mxsfb probe
sneil has joined #dri-devel
<danvet> marex, yeah that sounds buggy
<danvet> marex, if you don't have drm-misc commit rights, pls apply for them
<danvet> then get your patches acked/reviewed (cross review with someone else to get that going)
<danvet> and then push
<marex> danvet: where / how ?
<marex> danvet: OK, I think I need to spend some time to read through all that
<marex> danvet: I have a fdo gitlab account, but I suspect that's not enough
cphealy has joined #dri-devel
<danvet> marex, drm-misc is still on the old gitlab ssh account
<marex> danvet: the old gitlab ?
<danvet> old freedesktop infra :-)
* danvet confused
<marex> danvet: and what exactly does that imply for me ?
* marex confused more
bcarvalho has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
YaLTeR[m] has joined #dri-devel
xcube has joined #dri-devel
nchery has quit [Quit: WeeChat 2.4]
<danvet> marex, if you have a bunch of mxfsb patches merged, apply for commit rights per that link
<danvet> and then get going
<marex> danvet: thank you, I did read that link
mbrost has joined #dri-devel
mattrope has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
nchery has joined #dri-devel
anujp has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<marex> danvet: oh, you mean I need to apply for "Legacy SSH accounts" ?
<danvet> marex, yup
tzimmermann has quit [Quit: Leaving]
<vivijim> danvet: I'm not able to push drm-intel-fixes
<vivijim> $ dim push drm-intel-fixes -f
<vivijim> Pushing 193 commits. Are you sure? (y/N)
<vivijim> error: dst ref refs/heads/drm-intel-fixes receives from more than one src
<vivijim> error: failed to push some refs to 'ssh://'
<vivijim> any idea?
<vivijim> I even setup a clean environment from scratch here
pochu has quit [Ping timeout: 481 seconds]
tobiasjakobi has joined #dri-devel
* vivijim pushing with git directly
<vivijim> oh the hooks :(
<danvet> :-)
<danvet> naughty vivijim naughty!
<vivijim> :)
<vivijim> danvet: there's something with dim and new git version that might not be right
<danvet> 2.32.0 here
<vivijim> oh... 2.31.1 here
gouchi has joined #dri-devel
NiksDev2 has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
<vivijim> danvet: oh, pushing with dim push-fixes works... pushing with dim push-branch drm-intel-fixes doesn't... (mind blowing)
ngcortes has joined #dri-devel
<danvet> vivijim, wow
<danvet> yeah that sounds funny
<vivijim> is this why we haven't killed the aliases yet?!
<vivijim> yeap
<danvet> I just used dim push-branch, works here
<vivijim> probably something with worktree?!
<danvet> vivijim, I have no idea tbh
<vivijim> nevermind... I will put a mental note to continue using the alias :)
<danvet> vivijim, checking why dim is confused here would be good
<danvet> maybe the check to deprecate the aliases got it wrong?
NiksDev2 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<airlied> jekstrand: I got back on the opencl wagon this week :-P
tlwoerner has quit [Read error: No route to host]
<jekstrand> airlied: Image support soon, maybe?
<jekstrand> \o/
<airlied> jekstrand: starting with baseline CL 3.0, images are still messy :-P
camus has quit [Read error: Connection reset by peer]
<jekstrand> Sure. Bigger numbers are better, right?
<airlied> bigger numbers have more CTS? :-P
camus has joined #dri-devel
<jekstrand> It also lets us enable features more peacemeal which is good
<airlied> though CL CTS is the only CTS where if someone suggested a test that test every uint64_t value for each api someone would approve it
<airlied> and someone else would say its acceptable for CTS runtime to be 20 years
<alyssa> airlied: Crikey
<alyssa> Testing eery 2^32 input can be reasonable. Testing eery 2^64 input never is..
<jekstrand> Nah. You just need a big enough GPU. :)
<airlied> alyssa: tbh testing very 2^32 isn't really smart thinking either by default
<alyssa> jekstrand: I guess if I made a cluster of 65 of my laptops I could do it in a year..
<alyssa> cwabbott: For what it's worth, Bifrost and newer are supposed to support bindless textures/samplers
<alyssa> Although at a perf penalty..
<alyssa> Also allegedly supports bindless UBOs and bindless attributes/images/varyings
<alyssa> In our case the bindless handles would just be GPU pointers (so.. uint64_t)
<alyssa> --wait, no, that's wrong
<alyssa> hold on
<alyssa> Uh. Right. Ok.
<alyssa> Bindless on Bifrost would require allocations to all be in the bottom 38-bits of gpu a
<alyssa> gpu va
<alyssa> And then bindless handles would be u32's which are the pointers divided by 32-bytes
pochu has joined #dri-devel
lynxeye has joined #dri-devel
NiksDev has joined #dri-devel
<alyssa> Notice that Bifrost sampler/texture descriptors are exactly 32-bytes, and their first 4-bits are a type field allowing hardware validation.
<alyssa> UBOs/attrbutes/images/varyings don't have either of those properties ... you could still make it work if you aligned everything and didn't need robustness...
Peste_Bubonica has quit [Quit: Leaving]
aravind has quit []
bcarvalho has joined #dri-devel
* airlied requests llvm commit rights
pscoe2 has joined #dri-devel
<alyssa> airlied: 🍿
<pscoe2> Hi mesa experts, I am getting erros while trying to compile mesa main following the ci instructions. Is this the right forum to find help?
<alyssa> Sure, what errors?
pochu has quit [Ping timeout: 480 seconds]
<pscoe2> The clang build runs fine but when i try to make libclc, it errors out while trying to verify llvm-as
sdutt has quit [Ping timeout: 480 seconds]
<pscoe2> Command which errors out: cmake ../libclc -GNinja -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-m64" -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DCMAKE_INSTALL_PREFIX="D:\mesa\llvm-10" -DLIBCLC_TARGETS_TO_BUILD="spirv-mesa3d-;spirv64-mesa3d-"
<pscoe2> Where it errors out: -- Check for working LLAsm compiler: D:/mesa/llvm-10/bin/llvm-as.exe -- broken
<pscoe2> CMake Error at cmake/CMakeTestLLAsmCompiler.cmake:40 (message):
<pscoe2> The LLAsm compiler "D:/mesa/llvm-10/bin/llvm-as.exe" is not able to compile
<pscoe2> a simple test program.
Ahuj has quit [Ping timeout: 480 seconds]
<alyssa> What happened here?
<alyssa> (fedora-release failure)
<alyssa> jenatali: I see .exe, I field to you ^
<alyssa> (for pscoe2 's question)
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
Erandir has joined #dri-devel
pscoe2 has quit [Remote host closed the connection]
pscoe2 has joined #dri-devel
pscoe2 has quit [Remote host closed the connection]
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
lynxeye has quit []
<airlied> alyssa: if they comeback its a libclc bug
<jekstrand> alyssa: No one knows... :(
sdutt has joined #dri-devel
<alyssa> jekstrand: 🎵
<jekstrand> alyssa: It's never been unstable before and it's solid here on my fedora box
<alyssa> 🤷
<bl4ckb0ne> jekstrand: do you want more testers for ?
<jekstrand> bl4ckb0ne: No. Just wanted to make sure someone had. :)
<jekstrand> bl4ckb0ne: Need someone to merge for you?
<bl4ckb0ne> aye pls
<jekstrand> bl4ckb0ne: done
<bl4ckb0ne> thanks!
sdutt has quit [Ping timeout: 480 seconds]
<jekstrand> yw
Ahuj has joined #dri-devel
<alyssa> We'll see about that
* alyssa stares at CI pipeline for !11735
<bl4ckb0ne> dont scare it D:
<alyssa> jekstrand: fedora-release has now failed twice on the same pipeline
<alyssa> can I disable the job for take 3?
<jekstrand> alyssa: Yeah.... It's only the fedora one.
<alyssa> and failing an anv test for panfrost changes nonetheless
<jekstrand> Ooh. I wonder if I can repro building in release. Maybe that's the ticket.
<alyssa> also can I turn that yeah into an a-b to disable? thanks
<jekstrand> alyssa: Let me take a few minutes and at least try to repro locally
<alyssa> Sure. If you can't figure it out, !11830 has the disable commit. If you can, even better :)
rasterman has quit [Quit: Gettin' stinky!]
lemonzest has quit [Quit: Quitting]
tlwoerner has joined #dri-devel
Thymo has quit [Quit: ZNC -]
tobiasjakobi has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
Thymo has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
pscoe2 has joined #dri-devel
sdutt has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<airlied> pscoe2: that is a libclc and clang bug
<JoshuaAshton> With a very minor change, lavapipe works in Renderdoc :D
tobiasjakobi has joined #dri-devel
<pscoe2> Thanks @airlied. Let me check it out
tobiasjakobi has quit [Remote host closed the connection]
<jekstrand> alyssa: Yeah, I've got no idea what's going on with the fedora runs.
<jekstrand> I'm scouring anv_state_pool for uninitialized fields etc.
tobiasjakobi has joined #dri-devel
<pscoe2> The make succeeds now, but the compilation of libclc fails with the following error
<pscoe2> D:\mesa_main\llvm-project\libclc\utils\prepare-builtins.cpp(98): error C2039: 'F_None': is not a member of 'llvm::sys::fs'
<pscoe2> Do I have to recompile clang after the libclc cmakelist change
mbrost has joined #dri-devel
<alyssa> jekstrand: so... a-b on the ci change?
<jekstrand> alyssa: I don't know
<airlied> pscoe2: don't think so, might be anoither breakage since that one
<anholt> jekstrand: link?
<jekstrand> anholt: To what?
<anholt> this release build issue
<jekstrand> There's one instance
tobiasjakobi has quit [Read error: Connection reset by peer]
gouchi has quit [Remote host closed the connection]
* jekstrand looks with helgrind
<anholt> would be nice to capture the core file from the ci run.
<jekstrand> If we've got a bug in our lock-free allocators, I'd very much like it fixed
<alyssa> bool does_multithreaded_code_has_bug(Code *code) {
<alyssa> return true;
<alyssa> }
<ccr> (void) code;
pscoe2 has quit [Ping timeout: 480 seconds]
pscoe2 has joined #dri-devel
<alyssa> ccr: ah yep, thanks for the warnings fix
* ccr feels helpful
tobiasjakobi has joined #dri-devel
<karolherbst> ehh.. is there an "easy" way to get debug symbols + sources for debugging on debian?
<karolherbst> or do I have to read through 5 wiki pages, understand the repo structure and add "deb ..." lines manually?
<steev> should be able to install the dbgsym package for the debug symbols
<anholt> DEBUGINFOD_URLS="" gdb ... may also just automatically get them for you
<steev> sources probably still needs a deb-src line though (just match to deb line)
<steev> oh that's cool
<anholt> I don't keep it in my environment because it's slow
<anholt> but way better than guessing package names
<ccr> you should be able to just copy the "deb" line(s) in /etc/apt/sources.list and change it to "deb-src" for the source packages.
<karolherbst> anholt: doesn't work :)
jewins has quit [Quit: jewins]
<karolherbst> well.. probably for x86, but it didn't for s390x
<karolherbst> "function not implemented" or something
<ccr> for dbgsyms I think you need "deb testing-debug main contrib" or so, I'm on debian "testing" so you'll have to change to whatever you're on
<karolherbst> ccr: I asked for a simple way :D
<karolherbst> I don't want to know what I need to put in there
* ccr shrugs :)
<karolherbst> well.. aother distros have a "whatever_package_manager debuginfo-install $package" and you are done
<steev> that... seems simple?
<karolherbst> steev: it's not :)
<steev> TIL editing a file isn't simple
<karolherbst> steev: ... and how do I know what to put in there?
<steev> we literally just told you
<karolherbst> what if I have a package from "updates" and not "main"?
<ccr> tbh, I don't know why the apt src/dbgsym repos are not set automatically at install
<karolherbst> and it doesn't match anymore?
<steev> then you get to pick up the pieces
<karolherbst> ccr: yeah...
<karolherbst> steev: I don't want do :D
<karolherbst> hence me asking for a "simple" way
<steev> then don't break your system
<karolherbst> but if there is no simple way, then just tell me there isn;t :)
<karolherbst> *isn't
<karolherbst> I know I can pick the pieces, point was, I want something simple I can't get wrong :D
<ccr> the #definition of "simple" may vary :P
<karolherbst> ccr: no?
<steev> apparently so
<karolherbst> apt debuginf-install $whatever would be simple
<karolherbst> everything else is stupid
<karolherbst> :D
<karolherbst> honestly
<steev> that's definitely one opinion
<karolherbst> you don't have to defend debian here....
macromorgan_ has quit [Read error: Connection reset by peer]
<steev> apt is open source, send a pull request
<ccr> imo there are worse things. a friend of mine uses Arch and sometimes I wonder why some things on it are so ass-backwards. but shrug.
<steev> i'm not defending debian, i just don't see how adding a line to your sources.list is difficult
<karolherbst> steev: right.. because I have enough time for that
macromorgan has joined #dri-devel
<karolherbst> ccr: :D
<karolherbst> true
<karolherbst> steev: I explained
<steev> realistically, it's probably already in there, and just commented out
<karolherbst> I have not a good idea on how debian works
<steev> you explained that you're lazy
<karolherbst> so I don't know if I have to add 1 or 2 or 3 lines or whatever
<karolherbst> I don't want to have to think about it at all
<karolherbst> heck
<karolherbst> even a "apt install debuginfo-repos" would be better
<karolherbst> and I wouldn't be able to get this wrong
<karolherbst> but fine.. I can't have the nice thanks...
<steev> somehow i think you would
<karolherbst> *thinks
<karolherbst> ,... thngs
<karolherbst> ... nvm
<ccr> this is one of those "with power of some configurability comes slight inconvenience" things.
<karolherbst> steev: yeah.... if you say so
<steev> and even then, you're on s390x, and almost everything is gonna be set up for x86_64
<karolherbst> ccr: I think this is a very stupid approach because that makes your OS silly to use, but whatever
<steev> so at some point, you're gonna have to roll up your sleeves and learn some things
<karolherbst> right, because there is a benefit of learning how debian does it's debug packages stuff a crappy way :)
<karolherbst> very interesting topic
<karolherbst> again.. you don't have to defend debian here
<steev> well, if you're planning on debugging stuff on debian, yes, it would be helpful if you learned how to do it
<karolherbst> well.. guess I just use a differen OS for building my development containers then...
<steev> do what you think is best for you
<ccr> let us know how that goes :)
<karolherbst> probably better
boistordu has quit [Remote host closed the connection]
<steev> karolherbst: how about this - sudo apt install debian-goodies; find-dbgsym-packages [core_path|running_pid|binary_path]
<karolherbst> steev: I still need to add the repos by hand, wouldn't I?
<steev> no
<steev> dbgsym packages are in the main repo, but not all packages are built with them iirc
<karolherbst> okay, then let me try that
<steev> you typically need a deb-src line for the *source packages* - typically these lines are already in sources.list but commented out as most people do not need the source packages, and it just takes longer to apt update
<karolherbst> "IPC::System::Simple required for Fatalised/autodying system() at /usr/bin/find-dbgsym-packages line 27." :)
<steev> sounds like some perl package isn't properly dep'd on :(
<karolherbst> yeah.. seems like it
<steev> i have it here, but then again, i have packaging stuffs installed
<steev> it's libipc-system-simple-perl
<karolherbst> and I disabled recommended and suggested auto install
<karolherbst> ahh...
<steev> well that's why then
<karolherbst> debian-goodies has no hard deps :)
<steev> because it's recommended
<karolherbst> libipc-system-simple-perl sounds like the right one
<karolherbst> yeah... seems like that tooling can't handle that the container is x86 but has s390x packages installed :/
<karolherbst> errors out with "not a dynamic executable" :)
<karolherbst> I mean I used debian, because at least this bit was easy to setup and crosscompiling and everything works
<karolherbst> just getting debug packages is for some reason painful
<karolherbst> guess I will add those lines and see where this gets me.. I just hoped for something simple
<steev> you may want to add :s390x to the end of whatever dbgsym package you want, so it knows to pull the correct architecture
<karolherbst> ohh sure, but I was refering to find-dbgsym-packages not really working
<karolherbst> well.. at least installing it does seem to work.. now let's see if gdb is happy
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst> yay.. it works :)
<karolherbst> but now I need the sources :)
<karolherbst> at least I get a backtrace now
<karolherbst> anyway.. thanks for your suggestions, I just hoped for something more intuitive
tobiasjakobi has quit [Remote host closed the connection]
boistordu_ex has joined #dri-devel
<dcbaker> venemo: we usually don't have one, but we're like 19 hours away from me making the branch. Just let me know when you convince marge, I'll wait for you
Hi-Angel has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
pcercuei has quit [Quit: dodo]
danvet has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
jernej has joined #dri-devel
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
iive has quit []
ppascher has joined #dri-devel
nirmoy has quit []
mbrost has quit [Ping timeout: 480 seconds]
<dcbaker> np