ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
stuart has quit []
q66 has quit [Server closed connection]
q66 has joined #dri-devel
mwalle has quit [Server closed connection]
bl4ckb0ne has quit [Server closed connection]
mwalle has joined #dri-devel
bl4ckb0ne has joined #dri-devel
Emantor has quit [Server closed connection]
Emantor has joined #dri-devel
Lynne has quit [Server closed connection]
Lynne has joined #dri-devel
CounterPillow has quit [Server closed connection]
CounterPillow has joined #dri-devel
marcan has quit [Server closed connection]
marcan has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest277
srslypascal has joined #dri-devel
Guest277 has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
zamundaaa has quit [Server closed connection]
kts has joined #dri-devel
kts has quit []
cengiz_io_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
zamundaaa has joined #dri-devel
tango_ has quit [Server closed connection]
tango_ has joined #dri-devel
Daanct12 has joined #dri-devel
libv has quit [Server closed connection]
libv has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ella-0 has joined #dri-devel
ella-0_ has quit [Remote host closed the connection]
Thymo has quit [Server closed connection]
Thymo has joined #dri-devel
Prf_Jakob has quit [Server closed connection]
Prf_Jakob has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
pq has quit [Server closed connection]
pq has joined #dri-devel
hikiko has quit [Server closed connection]
hikiko has joined #dri-devel
Company has quit [Quit: Leaving]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
llyyr has quit [Server closed connection]
llyyr has joined #dri-devel
LaserEyess has quit [Server closed connection]
LaserEyess has joined #dri-devel
alanc has joined #dri-devel
evadot has quit [Server closed connection]
evadot has joined #dri-devel
dj-death has quit [Server closed connection]
dj-death has joined #dri-devel
Ristovski has quit [Server closed connection]
Ristovski has joined #dri-devel
neobrain has quit [Server closed connection]
neobrain has joined #dri-devel
bbrezillon has quit [Server closed connection]
bbrezillon has joined #dri-devel
pH5_ has quit [Server closed connection]
pH5 has joined #dri-devel
Terman has quit [Server closed connection]
Terman has joined #dri-devel
JoshuaAshton has quit [Server closed connection]
JoshuaAshton has joined #dri-devel
srslypascal is now known as Guest302
srslypascal has joined #dri-devel
mstoeckl has quit [Server closed connection]
mstoeckl has joined #dri-devel
emersion has quit [Server closed connection]
emersion has joined #dri-devel
Guest302 has quit [Ping timeout: 480 seconds]
marex has quit [Server closed connection]
marex has joined #dri-devel
aravind has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
bmodem has joined #dri-devel
bmodem has quit []
pixelcluster has joined #dri-devel
fxkamd has joined #dri-devel
fxkamd has quit []
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
tomeu has quit [Server closed connection]
tomeu has joined #dri-devel
ivyl has quit [Server closed connection]
ivyl has joined #dri-devel
aravind has joined #dri-devel
perr has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
robertfoss has quit [Server closed connection]
robertfoss has joined #dri-devel
xroumegue has joined #dri-devel
perr has quit [Remote host closed the connection]
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
lygstate has joined #dri-devel
mal has quit [Server closed connection]
mal has joined #dri-devel
lygstate_ has joined #dri-devel
lygstate has quit [Ping timeout: 480 seconds]
kgz has quit [Server closed connection]
kgz has joined #dri-devel
lemonzest has joined #dri-devel
pepp has quit [Server closed connection]
pepp has joined #dri-devel
rawoul has quit [Server closed connection]
rawoul has joined #dri-devel
kmn has quit [Server closed connection]
kmn has joined #dri-devel
ccr has quit [Server closed connection]
ccr has joined #dri-devel
perr has joined #dri-devel
danvet has joined #dri-devel
jkhsjdhjs has quit [Server closed connection]
jkhsjdhjs has joined #dri-devel
Duke`` has joined #dri-devel
CME_ has quit [Server closed connection]
CME has joined #dri-devel
eloy_ has quit [Server closed connection]
eloy_ has joined #dri-devel
frieder has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
haagch has quit [Server closed connection]
haagch has joined #dri-devel
gruetzkopf has quit [Server closed connection]
gruetzkopf has joined #dri-devel
jkrzyszt has joined #dri-devel
lygstate has joined #dri-devel
ElementW has quit [Server closed connection]
jfalempe has joined #dri-devel
lygstate_ has quit [Ping timeout: 480 seconds]
qyliss has quit [Server closed connection]
qyliss has joined #dri-devel
mvlad has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
hakzsam has quit [Server closed connection]
hakzsam has joined #dri-devel
sven has quit [Server closed connection]
sven has joined #dri-devel
tursulin has joined #dri-devel
pcercuei has joined #dri-devel
jfalempe has quit [Ping timeout: 480 seconds]
lina has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
jfalempe has joined #dri-devel
mlankhorst has quit [Server closed connection]
mlankhorst has joined #dri-devel
aravind has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
frankbinns1 has quit []
frankbinns has joined #dri-devel
jfalempe has quit [Ping timeout: 480 seconds]
lplc has quit [Ping timeout: 480 seconds]
lygstate has quit [Remote host closed the connection]
pal1000 has joined #dri-devel
pal1000 has quit [Remote host closed the connection]
pal1000 has joined #dri-devel
Ziemas has quit [Server closed connection]
Ziemas has joined #dri-devel
lplc has joined #dri-devel
jfalempe has joined #dri-devel
RSpliet has quit [Server closed connection]
RSpliet has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
pochu_ has left #dri-devel [#dri-devel]
pal1000 has left #dri-devel [#dri-devel]
rasterman has joined #dri-devel
perr has quit [Quit: Leaving]
nchery has quit [Read error: Connection reset by peer]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
MajorBiscuit has joined #dri-devel
ppascher has joined #dri-devel
rkanwal has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
xypron has joined #dri-devel
<xypron> On some RISC-V platforms which only have a framebuffer and no GPU the desktop runs much faster after deleting kms_swrast_dri.so. Is there a switch to disable the driver at runtime? Is the slowdown expected behavior?
<emersion> which desktop?
<emersion> i mean, which compositor are you using?
<xypron> emersion: xfce4 with openbox
<xypron> eversion: x11
<xypron> same with the Xfce windows manager
romangg has quit [Server closed connection]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
<tomeu> xypron: guess you need to tell the compositor to not use opengl if there is no GPU
<tomeu> and yes, it is expected
romangg has joined #dri-devel
mclasen has joined #dri-devel
mclasen has left #dri-devel [#dri-devel]
enick_403 has quit [Server closed connection]
enick_403 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mclasen has joined #dri-devel
mclasen has left #dri-devel [#dri-devel]
mclasen has joined #dri-devel
fab has joined #dri-devel
kts has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
srslypascal is now known as Guest342
srslypascal has joined #dri-devel
Haaninjo has quit [Read error: No route to host]
Haaninjo has joined #dri-devel
saurabhg has joined #dri-devel
thellstrom has joined #dri-devel
Guest342 has quit [Ping timeout: 480 seconds]
jernej- has quit [Server closed connection]
jernej has joined #dri-devel
vup has quit [Server closed connection]
vup has joined #dri-devel
ickle_ has quit [Server closed connection]
ickle has joined #dri-devel
sergi4 has quit [Server closed connection]
sergi4 has joined #dri-devel
MrCooper has quit [Server closed connection]
MrCooper has joined #dri-devel
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
xypron has quit [Server closed connection]
xypron has joined #dri-devel
jcristau has quit [Server closed connection]
jcristau has joined #dri-devel
Thaodan has quit [Server closed connection]
Thaodan has joined #dri-devel
mupuf has quit [Server closed connection]
mupuf has joined #dri-devel
calebccff has quit [Server closed connection]
calebccff has joined #dri-devel
lcn has quit [Server closed connection]
lcn has joined #dri-devel
ds` has quit [Server closed connection]
ds` has joined #dri-devel
calebccff has quit []
calebccff has joined #dri-devel
bnieuwenhuizen_ has quit [Server closed connection]
bnieuwenhuizen has joined #dri-devel
calebccff has quit []
calebccff has joined #dri-devel
<Ristovski> Hmm, radeonsi/amdgpu seems to only expose GPIN_XXX perf counters via GL_AMD_performance_monitor (at least according to apitrace). Are the ones present in GALLIUM_HUD not exposed?
<Ristovski> I would expect all the ones in si_driver_query_list to be exposed
Duke`` has quit [Ping timeout: 480 seconds]
<Ristovski> Interesting, the GPIN ones are SI_QUERY_GROUP_GPIN, but shouldn't the others get exposed either way?
srslypascal is now known as Guest349
srslypascal has joined #dri-devel
Stary has quit [Server closed connection]
tursulin has quit [Ping timeout: 480 seconds]
Stary has joined #dri-devel
Guest349 has quit [Ping timeout: 480 seconds]
Arsen has quit [Server closed connection]
Arsen has joined #dri-devel
noord has quit [Server closed connection]
noord has joined #dri-devel
milek7 has quit [Server closed connection]
milek7 has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
V has quit [Server closed connection]
V has joined #dri-devel
HdkR has quit [Server closed connection]
HdkR has joined #dri-devel
frieder has quit [Remote host closed the connection]
vyivel has quit [Server closed connection]
vyivel has joined #dri-devel
Company has joined #dri-devel
sul has joined #dri-devel
ced117 has quit [Server closed connection]
ced117 has joined #dri-devel
<Ristovski> airlied: That patch from your crocus-fix-perf-count worked! Although some counters seem to get stuck: https://bpa.st/raw/4V5A (with quite high CPU usage as well, which is odd)
<Ristovski> Ok in reality its nearly all of the counters..
<Ristovski> None of the "Compute Metrics" ones work (both basic and extended set, group 0 and 1)
<Ristovski> Others too, it appears that only the "Group #6: Pipeline Statistics Registers." ones are fine
srslypascal is now known as Guest354
srslypascal has joined #dri-devel
Guest354 has quit [Ping timeout: 480 seconds]
morphis has quit [Server closed connection]
morphis has joined #dri-devel
APic has quit [Server closed connection]
APic has joined #dri-devel
mwk has quit [Server closed connection]
mwk has joined #dri-devel
BobBeck has quit [Server closed connection]
BobBeck has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
mbrost has joined #dri-devel
aravind has joined #dri-devel
kj has quit [Server closed connection]
kj has joined #dri-devel
kts has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
aissen has quit [Server closed connection]
aissen has joined #dri-devel
sul has joined #dri-devel
ppascher has joined #dri-devel
agx has quit [Server closed connection]
agx has joined #dri-devel
Lucretia has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> tarceri: "Honestly I don't know the rules around NaNs"
<alyssa> I believe the GLSL rule for numerical correctness is "yeet"
<MrCooper> not YOLO?
enunes has quit [Server closed connection]
<alyssa> MrCooper: Also allowed, the spec is ambiguous on this point
<MrCooper> one thing's for sure, it starts with Y
<alyssa> "Yes" is also allowed
<alyssa> As in, may we support NaNs? Yes.
<alyssa> Can we flush all NaNs? Yes.
<alyssa> Can we flush NaNs but only on Tuesdays? Yes.
<alyssa> Are all hopes of correctness lost when using this API for numerical computing? Yes.
enunes has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
rellla has quit [Server closed connection]
fxkamd has joined #dri-devel
rellla has joined #dri-devel
sdutt has joined #dri-devel
kts has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
luc4 has joined #dri-devel
MrCooper has quit [Quit: Leaving]
danylo is now known as Guest362
MrCooper has joined #dri-devel
urja has quit [Server closed connection]
urja has joined #dri-devel
stuart has joined #dri-devel
vup has quit []
<Ristovski> airlied: in intel_perf_query.c: read_oa_samples_until() keeps returning `OA_READ_STATUS_UNFINISHED` which is what causes apitrace to freeze. It also burns CPU since infinite loop on retrying to read the `oa_stream_fd`. Quite peculiar.
<karolherbst> alyssa: there is always CL if you think glsl is to lax on that stuff :P
jkrzyszt has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
ybogdano has joined #dri-devel
<alyssa> karolherbst: alas
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
MattGPU has quit []
Jeremy_Rand_Talos_ has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
<Ristovski> I wish amdgpu had as good of a reset capability as i915 instead of just crashing the kernel
<karolherbst> wuhu, another rust release
<karolherbst> Ristovski: it's worse on nvidia btw :P
<karolherbst> nvidia isn't even trying
<karolherbst> anyway.. full GPU reset is super complex and maybe something not even possible to do
<karolherbst> reliably that is
<karolherbst> alyssa: "Now, with 1.63.0, the standard library is adding scoped threads, which allow spawning a thread borrowing from the local stack frame." :O
ambasta[m] has quit [Server closed connection]
<alyssa> sorry what
ambasta[m] has joined #dri-devel
<karolherbst> alyssa: imagine you want to parallize a loop and reference stack data, it would be a shame if the thread lives after the stack got nuked
<karolherbst> so scoped threads make sure they exist before the scope is left
<karolherbst> s/exist/exit/
<karolherbst> Mutex::new is const \o/
<alyssa> Ah :)
<alyssa> sorry I'm currently busy trying to get robclark's freedreno demos to work with libmali
<alyssa> aha there we go
Strit[m] has quit [Server closed connection]
Strit[m] has joined #dri-devel
<alyssa> robclark: ^^ this is bad and I feel bad :)
<karolherbst> alyssa: sad... I just wanted to tell you that rusticl is very close to landing :D
<robclark> I'm a bit afraid to ask (and also a bit afraid that someone is looking at gl code I wrote :-P)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<alyssa> karolherbst: :-D :-D :-D
<karolherbst> I am wondering if I should use the debian image for building rusticl?
<alyssa> robclark: libmali linux WSI is all kinds of broken
<robclark> sounds fun
<alyssa> truly
<alyssa> well, test-triangle-smoothed works now, that's what counts....
Duke`` has joined #dri-devel
<danvet> sravn, did you see my ping for locking down the new bpp helper a bit more?
bmodem has joined #dri-devel
bmodem has quit []
iive has joined #dri-devel
<karolherbst> nooo... meson is too old :(
saurabhg has joined #dri-devel
<karolherbst> uhhh...
<karolherbst> okay.. CI folks.. I have to options: use debian 12 or use the fedora image for building rusticl, but both look like bigger projects to get working
<karolherbst> mhh.. maybe I could install a newer meson through pip?
<daniels> if all you need is newer meson then yeah, just pull it from pip or from a backports repo
<karolherbst> yeah.. maybe I add a MESON_NIN_VERSION variable and .gitlab-ci/meson/build.sh just makes a "pip install meson>$MESON_MIN_VERSION" thing
<karolherbst> should only install a newer one if the system one isn't new enough.. let's see how that works
<karolherbst> "line 62: pip: command not found" :( guess I have to use pip3
rasterman has quit [Quit: Gettin' stinky!]
tursulin has joined #dri-devel
macromorgan is now known as Guest374
Guest374 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<daniels> not build.sh
<daniels> the container build
<karolherbst> mhhh
<daniels> and == not >
<karolherbst> > works fine :P
<daniels> no
<karolherbst> why not?
<daniels> because otherwise we have a random build environment which isn't reproducible between MRs
<karolherbst> mhhh
<daniels> and you get things like all your MRs suddenly failing because meson 0.63.0 broke its test-output parsing and suddenly all of your tests fail
<daniels> if you have it in the container build, you discover this immediately and the bump never gets merged
<karolherbst> guess I update meson to 0.57 for everybody then
<daniels> if you have it in your build build, everyone's pipeline goes red until someone diagnoses and fixes it
<daniels> yep
<daniels> consistent >>>>>> inconsistent
aravind has quit [Ping timeout: 480 seconds]
<danvet> airlied, MrCooper there's a pile of patches from danilo krummric pending and that's @redhat ... someone taking care and pushing these to drm-misc-next?
<danvet> and then maybe volunteering through the committer process if danilo will be staying in the drm area
<danvet> or some other rh Lyude karolherbst ^^
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst> danvet: I have other but related plans with danilo :D
<danvet> karolherbst, sounds like you well volunteered :-P
<karolherbst> what patches though?
<danvet> karolherbst, and you have drm-misc commit rights
<danvet> karolherbst, some idr_init conversion stuff I've seen
* karolherbst should think before speaking
<danvet> I think the virtio ones someone pushed already
<danvet> maybe more
<danvet> karolherbst, too late
<danvet> karolherbst, so pls get that series landed, and then if there's even more walk danilo through the commit rights thing and all that
<karolherbst> yeah.. let's see what we discuss
jfalempe has quit [Quit: Leaving]
<sravn> danvet: have read the mail on _bpp helper and blocky formats. Do not see what we gain from avoding the blocky formats
<danvet> sravn, people using cpp/bpp and making a complete mess out of things
<danvet> pretty much why we should use fourcc everywhere
<danvet> so intentionally limiting these helpers to just the legacy use cases is the way to go
<sravn> Using format_info everywhere would be great
<danvet> unfortunately fbdev helper isn't moved to format_info yet, but I can dream
<sravn> But we have many case, I think, that have legitimate needs for bits per pixel
<sravn> I have been lucky never to read any code supporting blocky formats, so I am also rather ignorant here.
<sravn> At lest, not that I have though off.
<sravn> least
<danvet> well that's the thing, if we have this helper people use it and then shit goes boom
<danvet> because it's too easy to ignore the blocky formats
alyssa has left #dri-devel [#dri-devel]
<sravn> So lets limit the use, and if we have a legitimate need, then we can see what to do then...
<danvet> e.g. if you look at depth then we only set that for some formats
<danvet> maybe a good approach would be to limit bpp to depth != 0
<sravn> Let me try to reply on the mail and see if Greert accepts it
<danvet> because that pretty much means "some funky legacy format"
<danvet> as long as the low-bit formats work geert doesn't get much of a vote here imo
<karolherbst> danvet: those were already pushed
<danvet> I don't want random bpp gunk computations to spread around in drivers, getting rid of the old cpp/depth stuff is a mess already
<danvet> karolherbst, oh I guess then just hand-hold through the committer process for the next round?
<sravn> I have looked at the formats table, and I have always been puzzeled by some of them.
<karolherbst> danvet: guess so
<danvet> hm pinchartl dutifully filling out depth for R10 and R12
<danvet> not good
<danvet> should ditch these too
<sravn> So we need drm_format_info in fbdev helpers and we need to clean up the current format definitions
<danvet> sravn, stuff like the stride computation in simpledrm.c is exactly why I don't like helpers like this
<danvet> someone hand-rolling stuff :-)
<sravn> Why do we have .cpp {2, 0, 0} when we have only one plane, puzzles me
<karolherbst> daniels: uhh.. what's the way of triggering a rebuild of the containers again?
<karolherbst> like e.g. after changing .gitlab-ci/container/debian/x86_build-base.sh
<danvet> sravn, which one?
<sravn> R12 as an example
<danvet> sravn, makes perfect sense to me
<danvet> 2 bytes per pixel, one plane, 10 bits actually used
<emersion> karolherbst: FDO_DISTRIBUTION_TAG
<danvet> or 12
<danvet> sravn, I think we should call it drm_format_info_legacy_bpp or something
<danvet> so people don't get funny ideas
<sravn> What confuses me is why there is something in cpp[1] and cpp[2] - but they are 0 so it does not matter
<danvet> hm yeah it's maybe a bit silly to specify them as 0 explicitly
<sravn> I will need the bits per pixel info for a driver I work n from time to time, I do not see a better way to get it. So legacy seems bad here
<danvet> generally you want programming tables/cases to program your registers
<danvet> switch(format_info) {} and then make sure you have them all
<danvet> I've seen a bunch of drivers that tried to use these legacy fields
<danvet> then added more formats and forgot to set some bits and oops
<sravn> Ahh, the array indexes are specified to make the tabel look neat. Now I get it. Slow today I think (nothign new)
<danvet> so drivers using these is really not a great idea imo, ever
<sravn> Hmm, I would rather ask for bpp than to have a list of formats where I hardcode the bpp.
<danvet> sravn, not hardcode the bpp
<danvet> but whatever it is you're programming into registers
<danvet> or why exactly do you need bpp in your driver?
<danvet> (the registers might have a bpp field somewhere, but that's just an artifact of the register interface, could be anything really)
<danvet> and for other computations we should add them to format_info lib, using the block stuff correctly
<sravn> Hmm, one case where I use it is to compute the size of the framebuffer. Where I use width*height*bpp - which I then use to configure the DMA register
<danvet> yeah no :-)
<danvet> you need to do height*stride
<danvet> otherwise you have a driver bug
<danvet> because generally userspace is allowed to give you bigger stride than necessary
<sravn> Yeah, one more thing on the TODO list then.
<danvet> which is also why the helper is called drm_format_info_min_pitch
<danvet> hm tzimmermann not around
chivay has quit [Server closed connection]
chivay has joined #dri-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
lygstate has joined #dri-devel
<lygstate> :jekstrand @alyssa Please at least review the first commit: * 9af356dc - util: Disable usage of \__attribute_\_((\__const_\_)) when the compiler is clang So that I can enable github actions for building llvmpipe for macOS and guard it by MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17879
lygstate has quit [Remote host closed the connection]
unerlige1 has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
unevenrhombus[m] has quit [Server closed connection]
unevenrhombus[m] has joined #dri-devel
<daniels> karolherbst: .gitlab-ci/image-tags.yml - bump to a new value
<karolherbst> thanks
<daniels> if you're upgrading Meson then I'd upgrade it to the same version across the board, bumping all the containers
<karolherbst> yep
lynxeye has quit [Quit: Leaving.]
eukara has joined #dri-devel
<Frogging101> hakzsam: It looks like I won't be able to avoid calling addrlib at the time that the image view is used. I'll have to inject an addrlib handle somewhere, but the question is where.
<Frogging101> Moving the function to ac_surface.c is a start, but it still needs to get an addrlib handle from somewhere. The other functions in that file that use addrlib get the handle because they are called via the radv_amdgpu_winsys_surface_init call chain
<Frogging101> That's at image creation time though. It's too early for this
<Frogging101> since we will need to know the slice being accessed and we don't know it at that time
<Frogging101> I could store a handle in struct radeon_info perhaps. Or have my function take a struct radeon_winsys and derive the handle from that
<karolherbst> uhhh... rustc 1.48 :(
<karolherbst> might have to drop the rust 2021 commit or figure out how to get a newer rust version into debian
ybogdano has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
moony has quit []
moony has joined #dri-devel
Vin[m] has quit [Server closed connection]
Vin[m] has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
gouchi has joined #dri-devel
<karolherbst> daniels: ... I don't think updating meson works :( so we use this debgencross script to generate cross files and using that breaks everything once you start using your pip meson as it seems...
<karolherbst> though no idea why
<karolherbst> or maybe that's a meson 0.57 bug? mhh
<karolherbst> "meson.build:21:0: ERROR: Compiler ccache cc can not compile programs."
<karolherbst> dcbaker: aware of any ccache related bugs around 0.57?
<dcbaker> karolherbst: not that I'm aware of... usually there's more detailed info in $builddir/meson-logs/
<karolherbst> the only relevant changes I did was to add rustc to apt and pip3 install meson
luc4 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
<dcbaker> karolherbst: it sure looks like cc doesn't exist for some reason
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
neobrain[m] has quit [Server closed connection]
neobrain[m] has joined #dri-devel
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
bluetail has quit [Read error: Connection reset by peer]
pcercuei_ has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
bluetail has joined #dri-devel
<karolherbst> dcbaker: are you aware of anybody working on a meson plugin for vscode or something? Got some quetions from Rust folks because of IDE integration for rust tooling.
<karolherbst> alternatively I could also add a cargo.toml file, but then the integration with bindgen sucks
<dcbaker> oh yes, we have one of those, I'm the maintainer :)
<karolherbst> :D
<karolherbst> ever tried that together with ruticl?
<karolherbst> *rusticl
<karolherbst> or well.. rust stuff in general
<dcbaker> I've used it with rust code and it works okayish, but we really need some way to tell rust analyzer about mixed generated code, and I haven't looked into whether that exists
<dcbaker> unfortunately most rust tooling just assumes cargo
<karolherbst> yeah...
<karolherbst> wondering if we want to generate cargo.toml files for those
<dcbaker> I've been talking to a few traditional distro people who want to use rust but absolutely don't want crates (they want dynamic linking I think), so we might start to see some more interest in using Rust without cargo
<karolherbst> mhhh
<karolherbst> probably
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
ngcortes has joined #dri-devel
MattGPU has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
<MattGPU> hi
<MattGPU> Anyone know if PS_INVOCATIONS on Intel GPUs is the number of fragments sent to the fragment shader code, or the number of *successful* (i.e. completed) fragment runs?
<karolherbst> dcbaker: btw.. I think there is a fake extension in the vscode repo based on an older version of yours
<dcbaker> the one in meson was given to us by the creator, and upstream took over maintenance, unfortunately vscode has no way to rename an extension...
<karolherbst> ahh
<dcbaker> so the old version is still there because the original author basically wandered off
<karolherbst> seems that way
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<dj-death> MattGPU: that's the number of pixels/samples running throught the fragment shader
<dj-death> s/throught/through/
Jeremy_Rand_Talos_ has joined #dri-devel
<dj-death> whlk
<karolherbst> dcbaker: what's the best way of opening an existing meson project?
<MattGPU> Basically the problem I have is that I'm seeing CL_PRIMITIVES_COUNT as 2 and PS_INVOCATION_COUNT as 0 with basically everything disabled (no VS, no scissors, no clip - everything off) and I'm trying to work out if somehow the fragment shader is just off somehow or maybe it's objecting to my fragment shader program?? idk
<karolherbst> or well... use it a non painful way
luc4 has joined #dri-devel
<MattGPU> Slowly going mad trying to manually stare-down batch buffers and the GPU code (neither of which I 100% trust are being decoded correctly)
<airlied> Ristovski: I'll take a closer look next week if I get a chance
<MattGPU> Hence the Q whether PS_INVOCATION_COUNT is the number of pixels the PS *wants* to shade or the number of pixels it *actually shaded*
<Ristovski> airlied: sounds good. Hitting the bugs is pretty easy: most counters from GALLIUM_HUD=help on crocus do it
<dj-death> MattGPU: is rasterization disabled?
<MattGPU> It's not disabled in the STATE_WM, but it might be disabled in some other MMIO register?
<dj-death> not aware of a register bit for this
<MattGPU> Me neither :/
<dj-death> would have to see to batch to be sure
<MattGPU> I mean, it should work, the pipeline is consuming geometry if it's setting CL_PRIMITIVES
<MattGPU> It's GEN6 not latest
<dj-death> yeah, quite old
<MattGPU> Yeah :(
gouchi has quit [Remote host closed the connection]
<Frogging101> I think I'm going to move the struct ac_addrlib pointer from the amdgpu_winsys and radv_amdgpu_winsys structures into radeon_info
<dcbaker> karolherbst: with vscode-meson? Just open the root directory with vscode and the extension enabled and it should Just Work™
<karolherbst> well "should just work"... but maybe my expectations are too high here :)
ybogdano has quit [Ping timeout: 480 seconds]
<karolherbst> but maybe I am also too blind to figure out how to configure the meson project from inside vscode
<karolherbst> kind of what "cmake tools" does, just for meson
<karolherbst> ehh wait.. I think I found it
<karolherbst> dcbaker: I suspect there is no proper UI for changing the meson config or is there and I was also too blind for that?
<dcbaker> I don't think we have a UI for that yet, no
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst> dcbaker: mhh yeah.. not finding generating sources is indeed annoying and missing
<karolherbst> but it also doesn't find rust types declared in different files
<karolherbst> but I suspect that's because of the rust extension
<MattGPU> Find someone who loves you as much as GPU designers love bit-field definitions, JFC
<dcbaker> It looks like we need to generate a project.json: https://rust-analyzer.github.io/manual.html#non-cargo-based-projects
<karolherbst> ahhh cool
<karolherbst> let me hack up some files and see if I can make it work
mvlad has quit [Remote host closed the connection]
<karolherbst> ... the example doesn't show anything.. nice
<dcbaker> they've written it inline in their .vscode/settings.json... for some reason
<karolherbst> ohh
<karolherbst> I see
* dcbaker thought the same thing
<dcbaker> but it appears that $source_dir/project.json should work
<dcbaker> err, `rust-project.json`
<dcbaker> we may also need to set some arguments to rustc
<dcbaker> I think you need to add `--error-format=json` in your rust flags as well
<karolherbst> it works!
<karolherbst> now I can at least jump to types within my main crate
<karolherbst> didn't deal with deps yet
<dcbaker> It should be completley possible for meson to just generate the project.json file at configure time, and since rust-analyzer seems to be the de factor LSP for rust now, it probably makes sense for us to do that...
<jenatali> Just a thought, it does seem like this conversation probably belongs in a Meson-focused channel?
<karolherbst> oh no.. people complain about off topic again :'(
<karolherbst> hey, we are doing it for rusticl, and that's mesa!
<jenatali> Dunno if I'd call that "complaining," just a suggestion. There's more people who could benefit from this discussion in that kind of channel than here probably
<dcbaker> there's a tracking issue
<karolherbst> mhh maybe it doesn't like one crate being a total subdir in another one... let me wire up the bindgen thingies first
<karolherbst> ehh wait
<karolherbst> I simply set the wrong path
<karolherbst> \o/ it works
<karolherbst> dcbaker: https://i.imgur.com/idrepe0.png
<dcbaker> \o/
<karolherbst> generate sources: check
<karolherbst> *generated
fab has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<karolherbst> mhhh
<karolherbst> no stdlib code completion
<karolherbst> guess that's the sysroot_src property
<karolherbst> dcbaker: I suspect that part will be _annoying_ to deal with
<dcbaker> jenatali was right, apparently someone asked on #mesonbuild:matrix.org about rust-analyzer with meson last night... lol
<karolherbst> lol
<dcbaker> `rustc --print sysroot`
<dcbaker> ?
<karolherbst> yeah
<dcbaker> I wonder what's going to happen with rust cross compiling?
<karolherbst> seems like it
<karolherbst> need to add "lib/rustlib/src/rust/library/" to the output though
<karolherbst> with that everything seems to work
lemonzest has quit [Quit: WeeChat 3.5]
<dcbaker> karolherbst: do you happen to have any rust-linked-with-c targets in there? and do they work correctly?
<karolherbst> yep
<dcbaker> sweet
<karolherbst> though not quite sure _What_ you mean by that
<karolherbst> bindgen generates the bindings and places them inside a rs file
<karolherbst> which are the first two crates
<karolherbst> you can't just call C code
<karolherbst> but yes.. ra picks up those generated bindings
Haaninjo has quit [Quit: Ex-Chat]
<dcbaker> I was thinking something like CFFI, but if you're not using it I don't care to deal with it ATM
<karolherbst> CFFI is something internal, no?
<karolherbst> well.. the thing rust uses
<karolherbst> it does call the C stuff directly
<karolherbst> but you get the bindings provided as rs files
<dcbaker> okay, I think that someone wanting to just hand roll C code from Rust seems pretty unlikely given bindgen, so I'm not going to worry about it
<karolherbst> even if, they'd write their rust bindings by hand :)
<karolherbst> I don't think there is any legal way of calling C code without rust bindings
<karolherbst> I mean.. I also declare those OpenCL entrypoints directly in rust
<karolherbst> extern "C" makes sure the calling convention matches
eyearesee has quit [Server closed connection]
eyearesee has joined #dri-devel
halfline[m] has quit [Server closed connection]
pcercuei has quit [Quit: dodo]
halfline[m] has joined #dri-devel
Sumera[m] has quit [Server closed connection]
Sumera[m] has joined #dri-devel
<Ristovski> airlied: Final hint: https://github.com/rib/gputop seems to work fine for me, so no clue why the mesa counters are broken *shrug*
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
fxkamd has quit []
iive has quit [Quit: They came for me...]
<karolherbst> dcbaker: mhhh... we can't pass in rustc compiler flags via the project json file, can we?
<dcbaker> looks like only --cfg options?
<karolherbst> yeah..
<karolherbst> I am using some options to silence a few warnings
<karolherbst> though I could potentially move them into the lib.rs files
<karolherbst> or generated bindgen ones
<dcbaker> I'm assuming that writing rust-analyzer patches is in my future
<karolherbst> :D
<karolherbst> anyway... still have to figure out this CI bug :(
Dylanger has quit [Server closed connection]
Dylanger has joined #dri-devel
stuart has quit [Remote host closed the connection]
stuart has joined #dri-devel