<bb2045>
ishitatsuyuki: The shaders pass spirv-val as long as --scalar-block-layout is specified (I'm using scalar block layouts).
kts has joined #dri-devel
aravind has joined #dri-devel
<bb2045>
There are three Vulkan validation errors- however, I think the only validation errors being reported may actually be bugs in Vulkan's validation layers.
<bb2045>
VK_EXT_mesh_shader is a relatively new extension, after all.
<bb2045>
In Vulkan SDK v1.3.231.1, the potential bugs can be found at: core_validation.cpp:2374, core_validation.cpp:2401, and core_validation.cpp:2406.
<bb2045>
In short, Vulkan's validation checks for VK_NV_mesh_shader, VK_SHADER_STAGE_TASK_BIT_NV, and VK_SHADER_STAGE_MESH_BIT_NV...
<bb2045>
...and does not check for the VK_EXT_mesh_shader equivalents, resulting in the three validation errors.
<bb2045>
I can confirm using gdb that Vulkan's validation treats the "mesh shading extension" as not enabled...
kts has quit []
<bb2045>
...because although vk_ext_mesh_shader = kEnabledByCreateinfo, vk_nv_mesh_shader = kNotEnabled, and on core_validation.cpp:2374, only vk_nv_mesh_shader is checked for.
<bb2045>
If someone might could kindly confirm that I'm not crazy, I would be happy to report an issue with the shader(s) attached (and hopefully a Fossilize pipeline as well as long as I can figure that out :) )
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
jdavies_ has joined #dri-devel
Guest2824 has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
fxkamd has quit [Remote host closed the connection]
kts has joined #dri-devel
dviola has quit [Quit: WeeChat 3.7.1]
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
itoral has joined #dri-devel
tzimmermann has joined #dri-devel
kzd has quit [Quit: kzd]
kts has quit [Quit: Leaving]
fab has joined #dri-devel
kts has joined #dri-devel
agd5f has joined #dri-devel
kts has quit [Quit: Leaving]
agd5f_ has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
bluetail89482 has quit []
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
fab has quit [Quit: fab]
bluetail89482 has joined #dri-devel
nchery has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
ice9 has joined #dri-devel
danvet has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
sghuge has joined #dri-devel
jfalempe has joined #dri-devel
tursulin has joined #dri-devel
fab has joined #dri-devel
rasterman has joined #dri-devel
ice99 has joined #dri-devel
frieder has joined #dri-devel
ice9 has quit [Quit: Leaving]
pochu has joined #dri-devel
<MrCooper>
nanonyme: Mesa's issues with LTO are fairly random, I wouldn't try too hard to make sense of it
<airlied>
or be prepared to try really hard and file gcc bugs :-P
<HdkR>
Or clang bugs :)
<MrCooper>
actually I do think it's more likely to be Mesa issues, the ODR violations are a good lead
<airlied>
MrCooper: in theory we have a directive to build with LTO for one of our supported OSes :-P
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
<MrCooper>
I've been trying to help move things in the right direction to make that possible
<airlied>
one of the coprs used to use LTO builds, but he did a lot of bumps along the way
lynxeye has joined #dri-devel
bgs has joined #dri-devel
Leopold has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
jkrzyszt has joined #dri-devel
Leopold__ has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<MrCooper>
karolherbst: is there a good way to get meson 1.0.0 on F37?
<hays>
^maybe that needs to be python3 depending on system
<hays>
and you might need some packages depending on system, like python3-venv or such
phasta has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
bluetail894822 has joined #dri-devel
ice99 has joined #dri-devel
bluetail89482 has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
<orbea>
rust-1.67.0 trying to bootstrap itself... https://termbin.com/9rnb (friendly reminder how others suffer because of the rust hype)
<orbea>
(note its already resolved, but amazing failure for a release, how does this happen even?)
jewins has joined #dri-devel
pallavim has joined #dri-devel
<karolherbst>
orbea: what's the point of that comment tho?
<karolherbst>
updated compiler breaking things? Hell, that never happened with C and gcc !!11!!1!!
<orbea>
they broke backwards compatiblity to the point of a rust version not being able to bootstrap itself (same version) in a minor version update
ajax_ is now known as ajax
<karolherbst>
same stuff happens with gcc constantly
<orbea>
never seen it happen, but say it does, I wouldn't like that either
<karolherbst>
right
<karolherbst>
bugs happen
<karolherbst>
I mean.. I think most people are up for alternatives, but.. atm there doesn't exist none, so....
<karolherbst>
*any
<ajax>
i like how wanting to use a language that eliminates entire categories that one has been fighting for multiple decades counts as "hype"
<orbea>
by hype I mean everyone adopting beta software that is clearly not ready
<karolherbst>
well..
<karolherbst>
android reduced their rate of CVEs by adopting Rust
<karolherbst>
"just saying"
<karolherbst>
C must be really terrible if it gets outperformed by beta software
<daniels>
can we please not have this argument here again
<daniels>
Hacker News and Phoronix forums already cover these kinds of things well enough
<karolherbst>
right
<emersion>
thanks
<ajax>
fair enough, i'll adjust my /ignores
<orbea>
rude...
<orbea>
i'll drop it, but its entirely on-topic to talk about how adopting a software stack is consisently a source of pain for many people
<psykose>
i don't think it's very on topic actually
<karolherbst>
last comment: it's not, it's _your_ choice of bootstraping rust yourself. Most (~99%) just use whatever package they get or rustup
<karolherbst>
don't assume your problems are that of anybody else
fab has quit [Quit: fab]
<DemiMarie>
Would it be possible to have some sort of sound NIR validation and backend fuzzing?
rsalvaterra has quit []
<karolherbst>
we do have nir validation, but no fuzzing
rsalvaterra has joined #dri-devel
<karolherbst>
in case you hit cases where a nir pass is generating invalid nir, but nir_validate doesn't spot it, please report this or fix nir_validate to catch those
<karolherbst>
but not really sure how to implement backend fuzzing :/
<karolherbst>
DemiMarie: ohh I have an idea.. could run shader-db through AFL
<karolherbst>
I did this in the past to fix some glsl parser bugs
<karolherbst>
(and to primarily find them)
Company has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
pallavim_ has joined #dri-devel
elongbug_ has joined #dri-devel
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
elongbug__ has quit [Remote host closed the connection]
pallavim has quit [Ping timeout: 480 seconds]
Leopold___ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
bluetail8948221 has joined #dri-devel
bluetail894822 has quit [Ping timeout: 480 seconds]
Leopold___ has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
djbw has joined #dri-devel
Leopold_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
dsrt^ has quit [Remote host closed the connection]
Leopold_ has quit [Ping timeout: 480 seconds]
<Company>
MrCooper: I still have 2 questions from our recent GTK fencing adventures:
<Company>
1. is there a way to wwrite code that triggers issues with wrong use of GLsync - like wait()ing in the wrong palce etc?
<Company>
2. what's a usecase for WaitClientSync()?
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
phasta has quit [Quit: Leaving]
Leopold__ has joined #dri-devel
maxzor__ has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
kzd has joined #dri-devel
junaid has joined #dri-devel
frieder has quit [Remote host closed the connection]
<Ristovski>
... interesting: https://bpa.st/raw/QJZIM (Ryzen 5700G, data from `smu_cmn_get_metrics_table` dumped via bpftrace since not all fields get exposed)
<Ristovski>
I really wonder what "ApuPower" _actually_ is because its value doesn't make sense to me
<MrCooper>
Company: 1. not sure how it could be tested, since the GL implementation may hide the issue; 2. maybe for testing if the fence has signalled (with timeout 0)? Can't think of any other use case offhand
nchery has quit [Ping timeout: 480 seconds]
<emersion>
Company: one way to test would be to implement the ext which disables implicit sync in Mesa
<Company>
MrCooper: (2) is mostly relevant so I can be sure that whatever I do, a WaitSync() is enough and I don't need a client sync
<MrCooper>
emersion: it's not related to implicit sync
<emersion>
and then submit a job which takes a long time to draw, e.g. like the one in weston-simple-dmabuf-egl --mandelbrot
<MrCooper>
Company: WaitSync is enough for synchronizing GPU execution, ClientWaitSync is for synchronously waiting with the CPU
<Company>
yeah - recent questions were about shared data stuff - like glGetTexImage() or ReadPixels()
<Company>
which is a corner case where each one could be necessary in theory, especially for semi-knowledgable people like me
<MrCooper>
WaitSync should be enough for those as well, though doing ClientWaitSync first shouldn't hurt that much, since they are synchronous anyway (except when using PBO for the pack buffer with ReadPixels)
fxkamd has quit []
<MrCooper>
emersion: if it was about implicit sync, the issue wouldn't have manifested itself with radeonsi, so we might still be blissfully ignorant of it :)
<emersion>
sorry, i was missing context here
<DemiMarie>
karolherbst: the reason I brought this up is that WebGL and WebGPU expose parts of Mesa to untrusted input from the Internet, so those parts had better be secure.
<agd5f>
Ristovski, APU power and dGPU power are used for smartshift.
agd5f_ has joined #dri-devel
iive has joined #dri-devel
nchery has joined #dri-devel
nchery is now known as Guest2910
nchery has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
Guest2910 has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<Ristovski>
agd5f: But what are the actual values? On APUs, `dGpuPower` is zero and `ApuPower` doesn't really correlate to anything
<Ristovski>
tl;dr: even though I found a way to get some new metrics you usually cant get access to via sensors, there indeed seems to be no way to get an isolated iGPU power usage on APUs
<Ristovski>
you could _kinda_ base it on VDDCR_SOC but that includes other stuff as well
pochu has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
pallavim_ has quit [Read error: Connection reset by peer]
kzd has quit [Quit: kzd]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
vyivel has quit [Remote host closed the connection]
kzd has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
vyivel has joined #dri-devel
kzd has quit [Quit: kzd]
mbrost has joined #dri-devel
kzd has joined #dri-devel
nchery is now known as Guest2919
nchery has joined #dri-devel
alarumbe has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
nchery has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
agd5f_ has joined #dri-devel
X512 has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
<X512>
What is Tegra? Is it significantly diffenent from nVidia?
agd5f has joined #dri-devel
bgs has quit [Remote host closed the connection]
agd5f_ has quit [Ping timeout: 480 seconds]
<HdkR>
X512: Tegra is NVIDIA's ARM SoC brand. Tegra 4 and older used an older GPU that used to be part of nforce chipsets. Tegra K1 and above use a GPU based on their desktop counterparts
<X512>
I see Tegra GPU code in libdrm. Is there an open source client driver code counterpart?
<jenatali>
Looks like Lima runners are out to lunch?
haasn` has joined #dri-devel
<agd5f>
Ristovski, see the driver. IIRC, it's just used to provide an idea how much of the power headroom is being used by the APU vs the dGPU
<daniels>
jenatali: yeah you can have my Ab for a disable
<daniels>
I noticed it earlier but decided that making lunch was far more important
<jenatali>
daniels: Thanks, on it
junaid has joined #dri-devel
<jenatali>
!20995 going straight to Marge
<anholt>
thanks!
<Ristovski>
agd5f: It should be returning APU power in watts, except in that case the value should match CurrentSocketPower (on APUs) but it does not (though it does get close, to ~3W under/over). Unless there is some sort of timing difference in the SMU which causes the discrepancy.
jluthra has quit [Remote host closed the connection]
<Ristovski>
What I find very unfortunate is how none of the metrics are documented enough to the point where someone could draw concrete conclusions on what the values actually represent and how they are calculated in the first place
jluthra has joined #dri-devel
<jenatali>
Wish there was a way to just use the passing result from the rest of the jobs to avoid having to re-run everything to merge a change after that disable goes through
junaid has quit [Remote host closed the connection]
ajax_ has joined #dri-devel
ajax has quit [Ping timeout: 480 seconds]
X512 has quit [Quit: Vision[]: i've been blurred!]
fab has quit [Quit: fab]
<hays>
I compiled mesa3d-demos and I just got one binary. is there a broader set of demos available somewhere else, or do I need to troubleshoot my build?
<airlied>
hays: the latter
<hays>
running on embedded system with EGL/GLES
<hays>
hrm.. ok
<airlied>
need freeglut or something like that usually
Duke`` has quit [Ping timeout: 480 seconds]
<hays>
hmm requires GL.. maybe there's just not that many EGL demos
gouchi has quit [Remote host closed the connection]
Guest1651 is now known as chadv
<hays>
not sure what EGLUT is
Duke`` has joined #dri-devel
<HdkR>
egl glut, it's in the demos repo itself
<airlied>
ah yeah there is't a huge amount of egl/gles demos
<HdkR>
es2gears and es2tri is all anyone needs
agd5f has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<hays>
yeah i think i can use gears pretty effectively to figure out why this dumb vendor driver is segfaulting es2gears and why wlroots can't create a backend
<HdkR>
"dumb vendor driver" is fairly indicative of the problem :)
mbrost has quit [Ping timeout: 480 seconds]
ice99 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
jekstrand has quit [Quit: leaving]
<Lyude>
MrCooper: I am, just going to let AMD handle that and have them ask me for help if they need it
<Lyude>
I'm burnt out enough with 2171, and now that someone's written fixes from AMD my hope is just that they'll be able to figure out the rest of the remaining issues and contact me if there really are more problems
<Lyude>
(i even remember the gitlab issue id off the top of my head, don't like that...)
ajax has joined #dri-devel
ajax_ has quit [Ping timeout: 480 seconds]
<airlied>
Lyude: hey skeggsb sent some fixes out to dri-devel, can you guide them in misc-fixes?
<Lyude>
airlied: sure thing, what's the topic of the email?