<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>
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
<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>
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>
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>
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*