<airlied>
is my first pass at fixing the translator
<jenatali>
That seems too simple, it must be broken somehow :P
<airlied>
I now fail 18 instead of 21 compiler tests :-P
camus has joined #dri-devel
macromorgan_ has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
sdutt_ has joined #dri-devel
<airlied>
arrgh interface variable lists
vivekk has joined #dri-devel
* airlied
wonders if the linker is broken here
<jenatali>
IMO the spec was stupid when they claimed that calling an entrypoint was invalid for CL
<jenatali>
Either that, or the original CL spec was stupid when they said it was valid in the first place
vivek has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
<airlied>
jenatali: I think the problem I'm hitting now is the linker taking two 1.0 spir-vs and creating something that isn't legal due to the entrypoints
<jenatali>
airlied: I'm shocked you haven't just disabled SPIR-V validation since Mesa's SPIR-V parser can handle it
<airlied>
jenatali: it actually fell over a subsequent problem :-P
<jenatali>
Oh ok
<airlied>
but yeah I might disable post link spirv validation at least
<airlied>
some Load getting wrong OpType
<airlied>
jenatali: yeah I bump into vtn_variables.c:2274
<airlied>
jenatali: looks like the linker doesn't regenerate the i/o list properly on the entrypoints
<jenatali>
Interesting
<jenatali>
airlied: it's been a while since I've sync'd dependencies, I wonder if something regressed
flacks_ has joined #dri-devel
<airlied>
commenting out the vtn check gets me down 4 fails :-P
flacks has quit [Ping timeout: 480 seconds]
<mattst88>
airlied: just FYI, I tried to get actual tagged SPIRV-Headers releases:
<airlied>
mattst88: going forward I think I'm only going to package what the SDK packages
<mattst88>
airlied: yeah, that's what we decided to do in Gentoo. it was too much of a hassle otherwise
khfeng has joined #dri-devel
<airlied>
the json file the sdk ships is useful for that
<mattst88>
but that still leaves us with shipping untagged SHAs of SPIRV-Headers for no specific reason other than upstream literally cannot be bothered
<mattst88>
would be trivial to just push a tag for the corresponding SHA1 in their DEPS file, but no
<orbea>
mattst88: follow the actual sdk tags, gentoo doesn't do that
<mattst88>
oh, did I misunderstand what he was referring to?
<airlied>
orbea: not the sdk tags, the sdk json file
<orbea>
im just annoyed at maintaining vulkan ebuilds in an overlay because gentoo wasn't giving actual stable versions
<orbea>
maybe that has changed, I guess we will see
<mattst88>
yeah, don't know what to tell you other than you're wrong, and you're talking to the person who would be most able of confirming that you're wrong
<mattst88>
so, shrug
<orbea>
if you looked at the actual git log you would see this was indeed a problem recently...
<mattst88>
I am the git log :P
<mattst88>
I don't know what to tell you. like I said, hop over to #gentoo-desktop if you want to contribute
<mattst88>
but please don't act like this
macromorgan has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
Lyude has quit [Ping timeout: 480 seconds]
SolarAquarion has quit []
Lyude has joined #dri-devel
illwieckz has quit []
tzimmermann has joined #dri-devel
Lyude has quit [Quit: WeeChat 3.2]
illwieckz has joined #dri-devel
SolarAquarion has joined #dri-devel
Lyude has joined #dri-devel
Duke`` has joined #dri-devel
itoral has joined #dri-devel
danvet has joined #dri-devel
rando25892 has joined #dri-devel
rando25902 has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
vivekk has quit [Ping timeout: 480 seconds]
jernej_ has quit [Ping timeout: 480 seconds]
jernej has joined #dri-devel
DPA- has joined #dri-devel
DPA has quit [Read error: Connection reset by peer]
<pepp>
zmike: nice!
pcercuei has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
rcf has quit [Quit: WeeChat 3.3-dev]
<airlied>
jenatali: going to investigate whether fixing the entrypoints should be an llvm pass
bcarvalho has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
<hakzsam>
tomeu: daniels: ^
<tomeu>
hakzsam: what's the problem with that job?
<tomeu>
ah, had it been waiting to be picked up by a runner for a long time? I see that the pipeline was started 2 hours ago
<hakzsam>
tomeu: oh it started since actually
<hakzsam>
yeah, the job was stucked for a long time
mlankhorst has joined #dri-devel
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
shfil has joined #dri-devel
flacks_ has quit [Quit: Quitter]
<shfil>
hi, I'm thinking about putting some work into wiki/docs. basically idea is to divide wiki into three parts: for user, for dev and the rest like history, links etc.
flacks has joined #dri-devel
<shfil>
imho best way would be keeping one clean path of usage for user (eli5 and maybe anything what's not directly needed on separate page "advanced")
<shfil>
iirc arch wiki is following this direction
<shfil>
I'm gonna be happy if someone gonna help me with answering these questions, which imho should be in FAQ:
<shfil>
1) do you need to reboot system after upgrading mesa?
<shfil>
2) where is the border of responsibilities of kerner's driver and mesa's driver?
<shfil>
3) do gallium based drivers provide vulkan?
<shfil>
4) can mesa be used on (older) windows? do devs provide support for it?
<shfil>
5) the same as above but with stock android/lineageOS?
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
<shfil>
I'm thinking about concentrating on uses more than on structure of driver itself. (documentation is becoming outdated super fast and devs are probably digging into code directly)
thellstrom has joined #dri-devel
Company has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<FLHerne>
1) not generally
frieder has joined #dri-devel
<FLHerne>
2) kernel driver manages power, displays, usually GPU memory allocations and scheduling, sometimes does some validation on command streams, exposes an ABI to send commands and compiled shaders to the GPU
<FLHerne>
Userspace driver compiles shaders and translates other API calls to the GPU's instruction set and submits them through the kernel driver
<FLHerne>
3) No, because the performance would suck, except Lavapipe because performance of software renderers sucks anyway
<FLHerne>
4) Yes, but not [yet?] any of the hardware drivers -- GLon12/CLon12 are supported by MS/Collabora, and I think the swrast drivers work
<FLHerne>
5) Yes
flacks_ has joined #dri-devel
<shfil>
oh, also how is gonna be able gallium nine run on zinc?
<shfil>
I remember reading about it on phoronix, and for most people this wasn't clear
<shfil>
btw thanks
aravind has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
itoral has quit []
imgui-quest has joined #dri-devel
<jenatali>
Yeah no hardware drivers run on Windows, just layered or software drivers
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
<imgui-quest>
Hello, I'm not sure if this is the right place to ask, here it goes: I want to run IMGUI on a cluster that only supports OpenGl 2 (it's virtualised) but has vast CPU resources. After search I found this library called MESA and to my surprise I stumbled upon this: https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/imgui , does anyone have experience in this? Is it worth to try setting MESA and how far will
<imgui-quest>
it get me? I don't have root rights nor can change the systems display drivers, will that be an issue? Thank you in advance :)
<FLHerne>
shfil: In principle it seems straightforward -- nine is a DX9 -> Gallium frontend, and zink is a Gallium -> Vulkan backend
<FLHerne>
I suspect it wasn't quite so trivial :p
<FLHerne>
imgui-quest: That particular directory won't help you -- Mesa just vendors in imgui for (afaik) drawing Gallium's performance overlay graphs
<emersion>
danvet: do you have good ideas to be able to tie kernel logging to a particular drmModeAtomicCommit?
<emersion>
e.g. i have a failing drmModeAtomicCommit and i'd like to know what happened, but the kernel logs are 4MB worth of data
<FLHerne>
imgui-quest: but Mesa does have software rendering drivers that will support imgui
<emersion>
and many other drmModeAtomicCommit calls failed
<FLHerne>
which should work without needing root or anything
<imgui-quest>
good :) is there a setup I should prefer over another?
<FLHerne>
imgui-quest: Look up OSMesa probably?
<imgui-quest>
for example i dont care if they computation is broken into multiple CPUs (actually i would prefer that)
<FLHerne>
Someone else might know more about that
<imgui-quest>
OKMesa, will look into it thank you
<imgui-quest>
OSMesa*
<FLHerne>
llvmpipe and swr both use multiple threads; llvmpipe is the default software backend and you should use it unless you have a specific reason not to
<imgui-quest>
i'm very agnostic to all this, you mention software backend, is that to emulate OPENGL2? I was planning to use glfw backend, but that might mean something different in IMGUI's context
<FLHerne>
definitely means something different
<imgui-quest>
thank you, I think you've covered my (silly) questions, it's time for me to dig deeper now based on your input :)
<imgui-quest>
I wanted to learn more about the MESA side since I don't think they use it as they focus on GPU accelerated environment, I'll try to limit to MESA related things (bad username pick I guess :D )
<shfil>
FLHerne: so zink is kinda vulkan -> gallium -> OpenGL (and just skips last step?)
<FLHerne>
shfil: Zink is Gallium -> Vulkan; the original idea was OpenGL -> Gallium -> Vulkan but now DX9 -> Gallium -> Vulkan works too
<shfil>
ah, yes
<FLHerne>
imgui-quest: Mesa is a library that implements various rendering/compute APIs (OpenGL/CL/GLES, Vulkan, DirectX, and some more ) -- either by hardware GPU drivers, software renderers or translation to another API
<FLHerne>
imgui-quest: In "I don't think they use it as they focus...", who is "they" ?
<imgui-quest>
@FLHerne The authors of IMGUI
<dj-death>
imgui-quest: there is almost no link between imgui and mesa
<dj-death>
imgui-quest: we just have a few tools in mesa using this library
<dj-death>
imgui-quest: that library has backends to work on DX/GL/Vulkan, it's really not aware of mesa in any way
<imgui-quest>
Which sounds really good, I'll try to make it work with llvmpipe OpenGL3
dogukan has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
dogukan has quit [Quit: Konversation terminated!]
dogukan has joined #dri-devel
dogukan has quit []
dogukan has joined #dri-devel
dogukan has quit []
<danvet>
emersion, not really ...
imgui-quest has joined #dri-devel
<danvet>
emersion, well maybe the crashrecorder thing from seanpaul, but it's not merged
<emersion>
we could log the user_data value, which could help with *some* user-space
<danvet>
hm yeah
<danvet>
but I think in general the crash recorder is the best solution
<danvet>
since userspace can trigger it whenever something has gone wrong
<danvet>
and userspace knows best which is the actually interesting fail, and which is the fail it expects to cope with
JohnnyonFlame has joined #dri-devel
bcarvalho has joined #dri-devel
<emersion>
indeed
imgui-quest has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
agd5f has joined #dri-devel
Peste_Bubonica has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
gpoo has joined #dri-devel
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
haagch has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
jekstrand[m]: afraid to ask but is pow(NaN, 0.0) = 1.0 or = NaN?
<alyssa>
I guess it's 1.0 from googling. wat
haagch has joined #dri-devel
<alyssa>
oh I can still handle that with a special NaN * 0.0 = 0.0 mode ok
tagr has quit [Remote host closed the connection]
tagr has joined #dri-devel
imgui-quest has joined #dri-devel
<zmike>
pepp: yeah, though there's still something seriously broken with z24x8 -> z32 conversion
vivijim has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
<jekstrand>
alyssa: Uh.... NaN, I'd expect.
<jekstrand>
alyssa: But I've not dug into it
<tjaalton>
mutter autopkgtest fails on ppc64el with mesa 21.2.0; "Unable to initialize the Clutter backend: no available drivers found."
<tjaalton>
anyone seen that?
<zmike>
jekstrand: if I txf z24x8, the x component should be 24 bits of z in MSB and 8 bits of garbage in LSB right?
<bnieuwenhuizen>
zmike: uh txf still does format conversion based on the aspect, no?
<jekstrand>
zmike: If you txf z24x8, it's treated like Z24_UNORM and you get a float.
<zmike>
right, but what data is in that float?
<zmike>
just the z?
CosmicPenguin has quit [Quit: Updating details, brb]
<jekstrand>
Yes
<zmike>
🤔
<zmike>
baffling
<jekstrand>
Why baffling?
<zmike>
because I wrote code that works to handle exactly that and I just get zeroes
<jekstrand>
Yes, that's correct pos(x, 0) = 0 if x != sNaN
<alyssa>
ugh
<jekstrand>
*pow
<alyssa>
jekstrand: I'm wondering if there's a good way to test this stuff in mesa
<karolherbst>
jenatali: you have reopened the "let's use the static pipeloader" discussion again :D
<alyssa>
we're not running piglits in panfrost CI yet :|
<jekstrand>
alyssa: piglits?
<karolherbst>
but hey.. maybe we should just sneak it in, then we can get rid of this "nir_serialized" hack
<alyssa>
karolherbst: whose side am i supposed to be on I forget
<karolherbst>
alyssa: pro static
<jekstrand>
alyssa: FYI: GLSL doesn't typically care about NaN correctness all that much.
<karolherbst>
alyssa: remember that NIR_SERIALIZED stuff you had to add?
<karolherbst>
with the static pipeloader, we don't need it
hikiko_ has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: of course you should make your own opinion on all of that and stuff
<alyssa>
jekstrand: but Vulkan does..
<alyssa>
karolherbst: booooo down with dynamic go static brr!!!!
<jekstrand>
true
<jekstrand>
alyssa: Well, sort-of true. Vulkan pretends to care. But not enough to have CTS tests for it all.
<alyssa>
lol
<alyssa>
jekstrand: Hmm if I added constant folding for the bifrost ops used in the fpow lowering I could do unit tests for them...
<alyssa>
this seems questionable. i should really piglit or ambe
<alyssa>
*amber
<alyssa>
Hmm I probably have the 754 spec through the university don't I..
imgui-quest has quit [Remote host closed the connection]
<zmike>
is there something special I should be doing in a nir txf in order to correctly sample z24x8? feels like I must be missing something simple at this point
* zmike
doesn't understand how this is still failing
<jekstrand>
alyssa: Amber is probably best if you can since it cuts out one layer of compiler
<alyssa>
Ack.
<alyssa>
Not sure if panvk is mature enough for it yet
<jenatali>
karolherbst: Glad to help :P
<jekstrand>
alyssa: IDK, Does it have basic compute shaders with SSBO support?
<jekstrand>
'cause that's really all you need.
sdutt has quit []
sdutt has joined #dri-devel
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
<alyssa>
Uhhh don't think so yet
frieder has quit [Remote host closed the connection]
<zmike>
huh on radeonsi I at least get data out of it
<zmike>
but on iris it's always zero
<ajax>
oh good, the other one
<jekstrand>
ajax: What amber were you afraid of?
<ajax>
i lacked all context, and was parsing "cuts out one layer of compiler" as suggesting to throw some old hardware support to the lts (amber) branch so alyssa wouldn't have to support something inconvenient
<ajax>
i'd also forgotten the other one existed so i was trying rillllhard to match "amber" to something i knew
<ajax>
parsing: literally impossible.
<jekstrand>
Ah
mattrope has joined #dri-devel
flto has quit [Remote host closed the connection]
nchery has joined #dri-devel
flto has joined #dri-devel
imgui-quest has joined #dri-devel
jessica_24 has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
<alyssa>
ajax: can i parse English with regexps???
thellstrom has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
imgui-quest has quit [Ping timeout: 480 seconds]
vivek has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
imgui-quest has joined #dri-devel
<ajax>
about as well as with anything else i guess
<austriancoder>
if somebody has time to review some bitset related changes I would be really happy - !11321
idr has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: Quitting]
<robclark>
austriancoder: sorry for the delay in looking at the encoding part of !11321 .. was out last week (and will be a couple days this week)
<robclark>
so a bit behind on reviews
Peste_Bubonica has quit [Quit: Leaving]
Peste_Bubonica has joined #dri-devel
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
shfil has joined #dri-devel
rcf has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
imgui-quest has quit [Remote host closed the connection]
imgui-quest has joined #dri-devel
imgui-quest has quit []
mbrost has joined #dri-devel
<austriancoder>
robclark: np - I thought a public ping might help this bigger MR :)
<karolherbst>
jenatali: if it comes to clover I can also just do a final decision in case curro isn't around, I just doubt curro made anything "public" about this though :p
<karolherbst>
but yeah, relevant people should still have a chance to review stuff :)
imirkin has joined #dri-devel
<airlied>
todays the day the teddy bears write an llvm pass
<jekstrand>
airlied: ?
<airlied>
jekstrand: trying to fix the SPIR-V convertor entrypoints can't be functions problem
bcarvalho_ has joined #dri-devel
<mattst88>
tjaalton: I haven't seen that particular error, but I do know that you need llvmpipe for mutter's test suite to pass. could that be it?
bcarvalho has quit [Ping timeout: 480 seconds]
<dj-death>
jenatali: I was trying a newer version of LLVM+LLVM_SPIRV_TRANSLATOR and I noticed the clc code that tries to pull argument types/names our of spirv
<dj-death>
jenatali: on the more recent version, it doesn't always work, have you noticed this?
<airlied>
dj-death: is it missing const?
<dj-death>
airlied: it's more that the OpName is not on the function's arguments
* airlied
has a cts test regression (or new test) that is failing to get kernel argument info for const args
<dj-death>
airlied: so you have to pull a bit further to pass some OpTypePointer so that you can get the actual type
<dj-death>
typical case for me was pointer arguments
<dj-death>
but I don't know much of the expectations for the translator
<dj-death>
could as well not put any OpName? :)
<airlied>
dj-death: don't suppose you have a old/new spir-v output?
<dj-death>
I could probably generate one
tzimmermann has quit [Quit: Leaving]
<dj-death>
airlied: but I was quite far back on the llvm-spirv-translator so...
<dj-death>
at the time I was using llvm11
<dj-death>
now 13
lynxeye has quit [Quit: Leaving.]
<alyssa>
it always amazes me that the clover -> clang -> llvm -> spirv -> nir dance works
<karolherbst>
alyssa: :D
<karolherbst>
why shouldn't it?
<dj-death>
there is many millions LoC why it shouldn't ;)
<karolherbst>
:D
<karolherbst>
well..
<karolherbst>
tell that to all consumers of llvm :D
<jenatali>
karolherbst: Yeah, agreed
<jenatali>
dj-death: I believe we've tried things on LLVM 12 and it seems to work, I haven't tried anything newer recently
<jekstrand>
dj-death: Yup. 90% of which are in LLVM. :D
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
shfil has quit [Quit: Konversation terminated!]
Kayden has joined #dri-devel
<jenatali>
dj-death: for what it's worth, I have aspirations of moving that to vtn rather than using hand-rolled parsing, at some point
<jenatali>
airlied: does clover pull that data out of the LLVM IR? or from the SPIR-V? or is it after the NIR conversion?
<dj-death>
jenatali: ok
K`den has joined #dri-devel
Kayden has quit [Remote host closed the connection]
* airlied
isnt code adjacent, prob be a few hrs
Duke`` has quit [Ping timeout: 480 seconds]
<jenatali>
No worries, I'm not either or else I'd just look. Was mainly just curious
K`den is now known as Kayden
rasterman has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: WeeChat 3.2]
Lyude has joined #dri-devel
pcercuei has quit [Quit: dodo]
nirmoy has quit []
rasterman has quit [Quit: Gettin' stinky!]
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: WeeChat 3.2]
flto_ has quit []
flto has joined #dri-devel
Lyude has joined #dri-devel
pnowack has quit [Quit: pnowack]
Lyude has quit []
<airlied>
jenatali, dj-death : if I'm looking at the right place clover/spirv/invocation.cpp pulls those things out of the spir-v
<jenatali>
airlied: I was just taking a look at that
<jenatali>
I guess that means you'd be impacted too by whatever change happened in the translator
<airlied>
it's probably one of contributors to my consts going missing
iive has quit []
<jenatali>
If you find any more details, I'm all ears
<airlied>
yeah it's on my list after the entry point wrappers