<HdkR>
I'm still missing The Burger's Priest. I want to go back :P
<mareko>
poutine in NZ? blasphemy
<dcbaker>
jenatali: that's happening to me too
<Sachiel>
there's someone called 'test' here, that I assume is using matrix and is called blue_penquin there?
<Sachiel>
ah yeah, /whois to the rescue
sarnex has quit [Quit: Quit]
<alyssa>
test: Congratulations on successfully trolling jenatali 😃
pnowack has quit [Quit: pnowack]
<jenatali>
I just don't get how it's happening, those words are unrelated
<Sachiel>
matrix is transling their nickname here on irc to their matrix name for you
<jenatali>
Oh wait, Sachiel sent a message that doesn't make sense when I read it, but I assume one of those instances of 'blue_penquin' used the name 'test'
<jenatali>
Weird
<robclark>
mareko: re: tomsguide link.. this statement hurts my brain, " whereas the Mali GPU design found in many a Snapdragon system-on-a-chip (SoC)..."
sarnex has joined #dri-devel
<HdkR>
ow
<icecream95>
alyssa: The massive 4000 clause compute shader for geometry shaders doesn't seem to do much except patch a few addresses in etc.
<alyssa>
shiver
meatloaf|2 has joined #dri-devel
virtjkl has joined #dri-devel
virtjkl has left #dri-devel [#dri-devel]
meatloaf has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
<airlied>
alyssa: did b4214adefc3ab5eb5e6bc456413cb2449d98a444 not fix that?
<mareko>
robclark: it's not a good article, but at least it acknowledges AMD as a new competitor
mbrost has quit [Read error: Connection reset by peer]
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
vivekk has joined #dri-devel
vivek has quit [Ping timeout: 480 seconds]
cef has quit [Ping timeout: 480 seconds]
boistordu_old has joined #dri-devel
<alyssa>
airlied: oh, need to rebase my branch, oops
<alyssa>
sorry!
boistordu has quit [Ping timeout: 480 seconds]
meatloaf|2 has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<robclark>
mareko: the thing I'm curious about, is whether AMD bolted on tiling again (which tbf, ati did before with what ended up adreno).. most of what I see in play store is stuff that tiling benefits somewhat.. since I can do both tiler and IMR with adreno it is fun to compare ;-)
<mareko>
robclark: you would have to ask Samsung about that
<robclark>
I'll guess we'll find out eventually.. if they were mainly aiming for laptop TDB and memory bandwidth, maybe they could get by without..
<mareko>
robclark: TDB?
<robclark>
it'll be interesting to see when they ship
<HdkR>
TDP?
<alyssa>
thermal dot product
<alyssa>
very machine learning
<alyssa>
so hot
<HdkR>
ML is the hot thing right now. So hot it'll burn a hole through your pocket
<HdkR>
Samsung is used to doing this.
<alyssa>
used to burning holes in user's pockets
<alyssa>
?
<HdkR>
yes
<mareko>
more like detonate while charging
<robclark>
yeah s/TDB/TDP/
shashanks has joined #dri-devel
<Venemo>
mareko: what I'm curious about is whether the Samsung RDNA device will work with an upstream kernel and mesa, or will it just live in Samsung's downstream. I realize you are probably not allowed to answer that
<Venemo>
but you should realize, if it can work with upstream, that may be the world's first mobile GPU that its vendor supports with open source drivers without someone needing to reverse engineer it
Duke`` has joined #dri-devel
lemonzest has quit [Quit: Quitting]
<airlied>
Venemo: hey intel made some mobile GPUs :-P
<airlied>
but first mobile gpu connected to an arm
<Venemo>
Well, mobile as in, phone
<Venemo>
Okay, I guess Intel did that too if you count Medfield
<Kayden>
but those didn't have real open source drivers, either
<Kayden>
since they were imagination
pnowack has joined #dri-devel
<airlied>
yeah there was some atom that ended up in a phone
<airlied>
but only one :-P
<airlied>
oh the zenfone was pvr as well
lemonzest has joined #dri-devel
vivijim has quit [Remote host closed the connection]
itoral has joined #dri-devel
<Venemo>
Also, as far as I heard Medfield was also no stranger to burning holes in people's pockets
<HdkR>
If it can double as a camping range then it's a good thing right?
<Venemo>
Of course
mbrost_ has quit [Read error: Connection reset by peer]
mlankhorst has joined #dri-devel
frieder has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
vivekk has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
danvet has joined #dri-devel
tomba[m] has quit []
tomba[m] has joined #dri-devel
tomba[m] is now known as tomba
thellstrom1 has joined #dri-devel
thellstrom1 has quit []
thellstrom has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
pcercuei has joined #dri-devel
jkrzyszt has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
Company has joined #dri-devel
milek7 has quit [Ping timeout: 480 seconds]
bcarvalho has joined #dri-devel
Ahuj has joined #dri-devel
<karolherbst>
arnd: I starting to think that all this Kconf stuff is just super stupid and annoying :( Why can't that be easy :D
hch12907 has joined #dri-devel
tursulin has joined #dri-devel
<arnd>
karolherbst: I think the complexity grows naturally over time, simplifying it takes a lot of effort.
hch12907_ has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah....
<arnd>
The huge obstacle of 'select' FB' is gone now though, so additional cleanups should be a bit easier than they were in the past
<karolherbst>
yeah... thing is just, I have the problem that 5.14 fails to compile once backlight support is disabled :(
<karolherbst>
maybe I should just fix this and wait with removing the option once your stuff all lands or something
boistordu_old has quit [Remote host closed the connection]
<airlied>
jenatali: you any idea where the "may not be targeted by both an OpEntryPoint instruction and an OpFunctionCall instruction." issue is stuck?
xexaxo has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
<graphitemaster>
alyssa, The TA I was thinking of was Technical Artist, not Teacher's Assistant XD
<mlankhorst>
sravn: I'm curious when adding all those panels, where are they used?
nirmoy has joined #dri-devel
<danvet>
tzimmermann, I didn't see any reply from you on the shmem/vgem discussion
<danvet>
tldr; this isn't a vgem special case, it's really a shmem bugfix
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
iive has joined #dri-devel
cef has joined #dri-devel
<karolherbst>
soo... what's the procedure to get patches into drm-misc-fixes? I want to push out this patch to drm-misc-next and fixes or can we fast forward it through drm-next/fixes danvet (in which case I'd responed with my r-by)? https://patchwork.freedesktop.org/patch/443967/?series=92538&rev=1
<danvet>
if you're late in the week (meaning Thu/Fri) and it's urgent
<danvet>
poke drm-misc maintainers to make sure it's included in that week's pull
<karolherbst>
yeah.. but also my fault for procrastinating :(
<danvet>
karolherbst, if you procrastinated it's probably not that urgent, so just push to drm-misc-fixes
<karolherbst>
well.. compile fix with backlight disabled ¯\_(ツ)_/¯
<danvet>
imo drm.git is for big gotchas (instead of another pull) or when the tree really is on fire
<danvet>
yeah just stuff it into drm-misc-fixes and back to procrastinating
<karolherbst>
yep
<karolherbst>
I actually tried to make it non optional in nouveau, but that just opened another can of worms
<danvet>
part of why drm-misc is so that you have a tree to just stuff fixes into
<danvet>
and don't have to ponder whether to do a PR or not, which means more mental load and more excuses to procrastinate
<karolherbst>
yeah :D
<danvet>
yeah, just push the fix
<danvet>
move on
<danvet>
maybe arnd converts it to a depends next time around it blows up
<karolherbst>
I already talked with arnd about it :D
<danvet>
karolherbst, you can go even simpler and just push everything into drm-misc-next
<danvet>
worst case it's a cherry-pick
<karolherbst>
result was: arnd has many pending patches which my stuff depends upon
<danvet>
yeah
<arnd>
I had spent a lot of time coming up with a broader solution a year or two ago, and made sure it all worked, but then we could not agree on some of the details, so I never followed up with the big approach.
<arnd>
the main goal at the time was however to separate DRM from FB, and that has now been done differently, so doing it again is probably easier
vivijim has joined #dri-devel
<karolherbst>
just need to get my head around the workflows with dim
<danvet>
arnd, btw a practical thing that would be worth to push through the bikeshed is the optional depends on thing
<danvet>
instead of depends on FOO || FOO=n that we have all over
<arnd>
I think we have finally solved the problem with PTP_1588_CLOCK, which was a similar (but completely unrelated) mess. I sent out a new version of the patch for that today. In theory it might loop into the same dependency chain as backlight, by way of CONFIG_I2C, but I don't think I ever saw the combination of the two
<danvet>
like I don't care what the bikeshed looks like, but it would be good to have and help a lot in these cases I think
<danvet>
arnd, and yeah FB we just switched over to depends on I think
<arnd>
danvet: for PTP_1588_CLOCK, we ended up adding a CONFIG_PTP_1588_OPTIONAL symbol that is defined as "def_tristate PTP_1588_CLOCK || !PTP_1588_CLOCK", so users of that can just "depends on CONFIG_PTP_1588_OPTIONAL"
<danvet>
arnd, hm could we make this automagic?
<karolherbst>
why does git am have to be so aweful :(
<danvet>
I really don't care what it looks like, as long as it just happens
<danvet>
karolherbst, are you using dim or not?
<karolherbst>
I do
itoral has quit [Remote host closed the connection]
<danvet>
karolherbst, it still keels over?
<danvet>
even if you grab the mbox from patchwork or lore?
<karolherbst>
it fails to apply the patch on -fixes :(
<danvet>
:-/
<karolherbst>
yeah.. but git am is just stupid
<danvet>
add -3?
<danvet>
it sometimes helps
<karolherbst>
"error: could not build fake ancestor"
<danvet>
next up the big shotgun
<danvet>
dim magic-patch
<danvet>
uses wiggle
<danvet>
50% it works
<karolherbst>
it works on -next
<danvet>
50% it just shreds your tree :-P
<karolherbst>
:D
<danvet>
apply to -next, cherry pick over?
<karolherbst>
yeah
<karolherbst>
that's my current plan
<danvet>
then your git has the local sha1 and is slightly smarter ...
<karolherbst>
but dim still complains about other crap
<danvet>
cherry-pick -x or so
<karolherbst>
"-:11: WARNING:COMMIT_COMMENT_SYMBOL: Commit log lines starting with '#' are dropped by git as comments" I guess I can ignore that
<danvet>
oh that's patchwork
<karolherbst>
orr.. maybe not
<danvet>
unfortunately patchwork is the biggest bikeshed of them all
<karolherbst>
it's not patchwork
<danvet>
it would be really, really great to have a linter that you can blindly trust
<danvet>
dim apply runs patchwork
<karolherbst>
Fix build errors and warnings when
<karolherbst>
# CONFIG_DRM_NOUVEAU_BACKLIGHT is not set
<karolherbst>
that's the git commit message
<danvet>
and this looks like patchwork?
<danvet>
or is it git?
<karolherbst>
ohh sure, but it's also in the plain mail afaik
<danvet>
patch transport over smtp, it's a standard protocol, didn't you know
<karolherbst>
sure
<danvet>
even scriptable!
<karolherbst>
dim just warns me that this might be dropped
<karolherbst>
but it's there in the git log
<karolherbst>
...
* danvet
should perhaps add more /s
<karolherbst>
yeah.. no :p
<danvet>
yeah that sounds like patchwork being funny
<karolherbst>
I am just thinking out loud
<karolherbst>
:D
<karolherbst>
ohh wait
<karolherbst>
that's checkpatch isn't it?
<karolherbst>
mhh
<danvet>
oh right
<danvet>
I wanted to say checkpatch, not patchwork
<danvet>
it's all ducttape of the horrible kind
<karolherbst>
I just do the pragmatic thing and adjust the commit message by removing the # and newline
<karolherbst>
or will anybody scream at me for daring to do such changes :p
<jenatali>
airlied: It's stuck that someone with LLVM knowledge needs to implement a workaround in SPIRV-LLVM-Translator
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
<karolherbst>
jenatali: what's the problem?
<jenatali>
CL allows one kernel to call another, but SPIR-V doesn't
<jenatali>
So the workaround needs to be that every kernel is split into an entrypoint wrapper + implementation function
<jenatali>
Calling a kernel needs to call the implementation instead of the entrypoint
<karolherbst>
spir-v doesn't know about kernels, that's the only assumption you have to do for everything to make sense :p
<jenatali>
It does though, OpEntryPoint
<karolherbst>
yeah.. that's just metadata
<karolherbst>
why would the translator care
<jenatali>
Yeah but the validator complains that you can't call a function marked OpEntryPoint
<karolherbst>
fix the validator ¯\_(ツ)_/¯
<jenatali>
The spec also says you can't
<karolherbst>
uhhh
<karolherbst>
fix the spec?
<jenatali>
And when I complained, they said the spec is right and the translator is wrong
<karolherbst>
:(
<jenatali>
Yep
<karolherbst>
well the spec is wrong because it defines functions args incorrectly ¯\_(ツ)_/¯
<karolherbst>
ehh
<karolherbst>
kernel args
<jenatali>
How?
<karolherbst>
because it uses pointers to function mem for non scalars passed by value
<tzimmermann>
danvet, i saw that reply, but i didn't think i could further contribute to the discussion. i'd be ok with the current fix, at least
<arnd>
I don't get any warnings in that tree, but a number of those patches are probably obsolete by now, as the original bug has been addressed differently
<karolherbst>
is there a way to have git blame but for removed lines? :D
<graphitemaster>
Woah, SPIR-V has actual functions? I always thought shaders were inlined to hell and back. Does that mean we can do recursion now?
<karolherbst>
danvet: ehh.. it failed to apply becvause somebody removed an "int ret;" :(
<karolherbst>
graphitemaster: no
<karolherbst>
well
<karolherbst>
in kernels maybe
<karolherbst>
but spir-v disallows recursion for graphics afaik
<graphitemaster>
What is the point of having actual functions then? Code size?
<jenatali>
Yeah, recursion is disallowed for graphics and unspecified for CL I believe
<karolherbst>
graphitemaster: what's the point of recursion?
<karolherbst>
wasting mem?
<karolherbst>
honestly.. if you want to use recurision you are doing it wrong
<karolherbst>
I still have an unfixable bug in the glsl parser because it's doing recursion :)
<graphitemaster>
See, recursion is great for parsers and evaluating an AST / visitor pattern for codegen :P
<karolherbst>
it isn't
<graphitemaster>
Well, it's the obvious way, short of simulating a stack.
<karolherbst>
maybe I have that shader somewhere still :D
<karolherbst>
then use a stack
<karolherbst>
and don't simulate one
<karolherbst>
the issue is just, it causes issues you wouldn't have otherwise
<karolherbst>
and to fix it, you have to remove the recursion
<karolherbst>
long term it's adding bugs
<graphitemaster>
What issues are we speaking of, possible stack overflow?
<karolherbst>
every recursion is a bug itself
<karolherbst>
graphitemaster: yep
<karolherbst>
it's a security issue :)
<graphitemaster>
You can track recursion depth as an integer argument and then just be like "too deep" and fail
<danvet>
tzimmermann, well atm it's stuck for lack of acks and reviews
<graphitemaster>
Same issue exists with a simulated stack btw, if it's bounded and static in size.
<karolherbst>
worst case you enable remote DOS attacks
<tzimmermann>
danvet, i'll ack it then
<karolherbst>
simply by having recursion
<danvet>
tzimmermann, I can also add some fixme comments that shmem with wc is broken on !x86
<danvet>
if you want
<karolherbst>
don't do recursion, there are always faster and better ways of doing things
<danvet>
or better explain why things are broken, or why it's not easy to fix on !x86
<danvet>
tzimmermann, maybe can you reply with what you'd like to see explained and I add that?
<karolherbst>
also
<karolherbst>
recursion on a GPU is stupid for different reasons
<karolherbst>
because that just kills perf outright
<tzimmermann>
danvet, sure. i'll do that later today
<graphitemaster>
I'd say actual functions on the GPU is stupid, never mind recursion.
<karolherbst>
imagine that goes happily through webgl
<karolherbst>
and ends up in mesa
<karolherbst>
and a website can just crash your browser or so
<graphitemaster>
karolherbst, Need to eliminate precedence climbing and go shunting yard.
<karolherbst>
or do other random crap with the stack
<graphitemaster>
Well if you're running AFL against the shader compiler, you may as well run AFL against the entire OpenGL API in mesa too.
<graphitemaster>
Since anything crashable from there is just as problematic as shader input.
<karolherbst>
ohh wait.. Lyude added that int ret; mhhh
<karolherbst>
graphitemaster: sure
<karolherbst>
but AFL is input based
<karolherbst>
so you need a file as an input
<karolherbst>
of course you could have something declaring GL API calls
<karolherbst>
or just fuzz through shader_runner
shashank_sharma has joined #dri-devel
<graphitemaster>
Just take some frame recordings of video games in nsight, the ones that can emit source code of all the OpenGL calls.
<graphitemaster>
Then massage them through AFL compiling them and running them.
<karolherbst>
danvet: if I have to resolve merge conflicts, do I have to leave a comment if I have to add more code or what's the prefered thing here?
<karolherbst>
graphitemaster: then I fuzz the parser of that file :p
<karolherbst>
I am sure 99% of the bugs will be in the tooling
<karolherbst>
not in mesa
<karolherbst>
which was the point of using the shader_compiler thing mesa has
<karolherbst>
as there is nothing in between mesa and the shaders
<graphitemaster>
I've found (and haven't reported) several OpenGL API calls that crash NVs driver and ANGLE (WebGL)
<graphitemaster>
Don't have the time to.
<danvet>
karolherbst, for cherry-picking or where?
<karolherbst>
danvet: yeah
<danvet>
karolherbst, small comment in the commit message so it's know whom to blame
<Venemo>
is there a version of cursor_next_instr which isn't internal?
NiksDev has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
<karolherbst>
ohhh.. dim uses sparse as well
xexaxo has quit [Remote host closed the connection]
<karolherbst>
might be a cool wrapper for sparse for gitlab CI
xexaxo has joined #dri-devel
<karolherbst>
well.. except that the config used looks broken?
Peste_Bubonica has joined #dri-devel
thellstrom has joined #dri-devel
<zmike>
pepp: you planning to merge your pbo stuff soon?
<pepp>
zmike: yes, tomorrow
<zmike>
cool
<zmike>
would like to get compute pbos moving after that since I need it to get csgo running
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<pepp>
zmike: did you find a heuristic to select the fastest codepath?
<zmike>
nope :)
<zmike>
I'm considering that maybe to start off we can just enable it conservatively for cases where your new pbo download path isn't supported
<zmike>
since that should be a 100% win and still solve my problem cases
<ajax>
fwiw i'm convinced that the variations i was seeing are not important enough to block pepp's pbo code
<zmike>
cool
<zmike>
I'm investigating your comment re: 32bit/16bit now
<ajax>
pretty sure there's still room for improvement there but i'll take the existing order of magnitude improvement just as like a start
<zmike>
yeah it's definitely a big win
<karolherbst>
danvet: ohh btw.. we might have a plan on how to resolve the nouveau situation in a more "organized" way and I blame you for this :p
<zmike>
ajax: so what you're saying is that any time the dst bitsize is 16, the entire branch should stick with 16bit ALUs?
<danvet>
karolherbst, always happy to take the blame for org/process improvements
<danvet>
?
<karolherbst>
:D glad to hear
<karolherbst>
yeah.. the current idea is just to have somebody "maintaining" a nouveau-next branch on gitlab drm/nouveau and just push it in via drm-misc-next or so :p Still want everybody to ack on that, but will send out some more or less formal proposal about this oon
<karolherbst>
*soon
<danvet>
sgtm
<danvet>
well assuming it follows drm-misc rules, which is "at least an ack on each patch"
<ajax>
zmike: i need to reread that patch i think. i had this whole mental model for how it worked that explained the test 18[879] numbers that i need to rediscover.
<ajax>
something along the lines of "we must be literally expanding that R32F to an RGBA32F somewhere before packing it down to RGBA16F, because if bandwidth were the only concern this should be only 2x slower than R32F -> RGBA32F"
<ajax>
but instead it's 4x slower, which you'd expect from turning one channel into four without narrowing...
<ajax>
and i think it's not so much "stick with 16 bit ALUs" as "pick the smallest type at every step that preserves enough precision to get he right answer"
sdutt has joined #dri-devel
<zmike>
right, makes sense
<ajax>
if you _have_ to pick a float for the intermediate stage (and the spec reads lke you do) but the dest is rgb555 you could probably use r11g11b10 instead of rgba16f?
<zmike>
that was sort of one of the goals I had with doing this, try to keep the speeds relatively consistent even if they weren't "the fastest"
<ajax>
not that anyone is likely to _do_ such a blit, but,
<alyssa>
jenatali: ETA until Microsoft replaces its d3d12 drivers with DXVK running on top of dozen? 🙃
<zmike>
there isn't really intermediate for that case though, I don't think? it's just load -> convert -> write
<zmike>
will post on the ticket
<karolherbst>
danvet: ohh sure.. we wouldn't merge MR without reviews/acks :p but Ben wants to be able to nack patches as well.. so the idea is roughly we pull in MRs, send out 1-2 weeks in advance drm-misc-next gets pulled and people can complain on the ML or something and patches might get dropped ¯\_(ツ)_/¯ details
<karolherbst>
anyway
<karolherbst>
will write something up and send it out
<jenatali>
alyssa: Not anytime soon :P
frieder has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<alyssa>
jenatali: Okay. But GLon12 is definitely deprecated in favour of Zink+Dozen, right? 🙃
<alyssa>
Zink is a Gallium driver which means it's faster.
<alyssa>
and Vulkan go brrrrrr
<jenatali>
Heh, yeah I don't think so
<alyssa>
jenatali: but phoronix forums said so ~!!!`!
Peste_Bubonica has quit [Remote host closed the connection]
<jenatali>
I am wondering how long before Dozen shows up there :P
<alyssa>
jenatali: I would signal boost it but knowing how the internet works the article would probably say "Alyssa Rosenzweig reports her work on Dozen at Collabora.." and 🤦♂️
* alyssa
does not want credit for other people's hard work
<karolherbst>
alyssa: :D
<karolherbst>
what the hell is happening again?
<alyssa>
karolherbst: this happened a week ago
<jenatali>
Eh it doesn't need a signal boost lol
<karolherbst>
alyssa: I think I missed it
<jenatali>
karolherbst: !12209
<karolherbst>
can we add a new metric?
<jenatali>
Metric?
<karolherbst>
max wrappers used to maintain 60 fps
<karolherbst>
so we wrap stuff in circles and see how far we can go without hurting perf
<jenatali>
Heh
thellstrom has quit []
<karolherbst>
wondering if we can run into a circular wrapping situation once vendors starts shipping wierdo wrappers themselves
frieder has joined #dri-devel
mattrope has joined #dri-devel
<jenatali>
Yeah you could pretty easily get circular between VKD3D and Dozen
<Sachiel>
reminds me of a site that translates a phrase from japanese to english and back until the translation is stable
<alyssa>
random question, why does device tree abbreviate to OF?
<karolherbst>
alyssa: because they don't have UEFI or ACPI
<karolherbst>
alyssa: the entire topic is annoying, if you like your life, ignore the entire topic :) :P
<alyssa>
karolherbst: let me know when i should switch industries
Ahuj has quit [Ping timeout: 480 seconds]
<Lyude>
karolherbst: 09:11 <karolherbst> ohh wait.. Lyude added that int ret; mhhh ?
<karolherbst>
Lyude: yeah... nothing.. it was my mistake and I was stupid :p
<karolherbst>
alyssa: well.. there are arm devices with UEFI
<karolherbst>
:P
<karolherbst>
so it's all good
<ajax>
zmike: by "loaded as 32 bit by the sampler" do you mean that sampler_type_for_target is always using GLSL_TYPE_FLOAT?
<karolherbst>
alyssa: we could benchmark if GLon12 + vkd3d or if zink+dozen is faster, no?
<zmike>
ajax: yes
<ajax>
is GLSL_TYPE_FLOAT16 not meaningful there?
<zmike>
not sure?
<zmike>
part of the thing is that the ubershader handles bitsize conversions, but it's meant to optimize for fewer shaders right now, not necessarily "the best" performance
<zmike>
I'm currently updating the MR on top of pepp's work to have this only run as a fallback when blit isn't supported
<zmike>
I think that'd be a good first step, and we can add optimizations and such from there
thellstrom has joined #dri-devel
<ajax>
i'm kind of expecting that, once we find the places where you'd need this fallback, we'll discover that the ubershader covers too many cases and can be optimized further from there
<zmike>
sure, absolutely could be the case
<zmike>
I mainly just want to get it landed in some form since I can't run a lot of stuff in zink atm due to sw fallbacks here
<zmike>
csgo takes literal days to launch
<ajax>
yeeeesh
<ajax>
got my ack
<zmike>
ty
<zmike>
doing another piglit run here before I update the MR...
<ajax>
the answer to my question is no, only uint sint and float there
<zmike>
cool
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<zmike>
uhhh
<zmike>
pepp: I'm trying out your pbo thing and it looks like you're never setting a vertex shader? 🤔
<zmike>
this crashes iris
<zmike>
hm maybe I broke this locally actually
<jekstrand>
kusma: Looking at your WSI series, I'm really thinking we want to land !12031 first.
<jekstrand>
kusma: Not out of any sense of "me first!" but because your series makes it even more clear to me that we need a more formal framework for image creation in order to think throuugh all the issues properly.
<kusma>
jekstrand: Yeah, that's fine with me. I'm not really in a hurry here anyway, this is just kinda what I need to do to get things working. We'll also probably switch to a DXGI native winsys before this is production-ready anyway, so arguably *some* of this is temporary.
<jenatali>
At least for Windows
<kusma>
Well, yeah. We're going to need the transition for WSLg, and probably also the other stuff, but it's a bit easier to untangle if it's all non-Windows, I think...
<pepp>
zmike: the vs is set by st_pbo_draw
<zmike>
pepp: yeah, I forgot I had some local refactoring there
<kusma>
So I guess the Windows-bits is the stuff that kinda temporary.
<jenatali>
Yeah
frieder has quit [Remote host closed the connection]
<kusma>
jasuarez: In !12069, you seem to have re-added xfails that were removed in !10219... Running locally, I can't reproduce these even on the top of your commit... Are you sure that wasn't a mistake? I'm referring to the dEQP-VK.texture.filtering.* failures specifically...
shashanks has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
<kusma>
Those should have been fixed by the no brilinear stuff AFAICT
<kusma>
AFAIK, the CI doesn't run all tests... so it's easy to miss some updates, sadly :/
<kusma>
jasuarez: Lavapipe, sorry that I didn't specify :)
<kusma>
jasuarez: The CI doesn't seem to run these AFAICT.
<anholt_>
kusma: I think I would assume that it was just clashing of the two MRs at the same time and update the xfails.
mbrost has joined #dri-devel
<kusma>
anholt_: Yeah, so a bad conflict resolution. That's kinda what I suspect.
<kusma>
jekstrand: Yeah, I'll take some time for that later this week. Right now I'm not in the right headspace :)
<jekstrand>
kusma: Fair enough. :)
<jekstrand>
kusma: When are you going to implement Vulkan on OpenGL? Seems like the obvious next step. :P
<kusma>
jekstrand: Don't need to, airlied already did that with Lavapipe.
<jekstrand>
lol
<ajax>
can we hurry up and delete classic yet
<ajax>
finding it really annoying to need to fix gallium and i965 and i915 and vieux and r100 and r200 and...
<kusma>
ajax: Yes, please! And lets kick out r200 and i915 as well, and garbage collect a whole lot of crap!
<ajax>
those count as classic.
<dcbaker>
Realistically now that we have crocus merged and in a real release, is there any reason not to go ahead with the amber thing?
<kusma>
Ah, I thought you meant swrast classic
<kusma>
But yeah, I guess we'd need to delete those anyway to be able to do that.
<dcbaker>
I'm happy to work on that again if we're actually read to do the deed
<ajax>
dcbaker: probably a good time now, yeah
<kusma>
dcbaker: I don't know what's holding us back.
<anholt_>
need to do some perf testing of i915g, but I think with all I've done it's getting pretty close to ready.
<ajax>
ironically i don't have a _ton_ of time to work on that right now... but i should soon, i hope
<kusma>
I mean, I think we got as much consensus as we're going to get (disagreements were mostly about details of how far we go, not about deleting those ancient drivers from modern mesa)
<ajax>
anholt_: owe you a beverage for the i915g work, btw, that's some thankless ish
<dcbaker>
indeed. I'll rebase the PR today, I've got a lot of meetings so I'll have plenty of time to do something mindless, lol
<anholt_>
well, ok. I'm also a bit worried about texture layout due to the cube and 3d fails, and also I haven't tested the older texture layouts since I only have 945 in CI.
<kusma>
anholt_: When you say worried, how worried is that compared to the worries of bit-rotting drivers? I mean, we don't actively verify that they still work, do we?
<anholt_>
kusma: we don't. I have an untested fix for "unbreak swrast fallbacks" on i915c that's been sitting around because ughhh trying to test that.
<kusma>
hehe :)
<ajax>
ngh, honestly worried that i might have a real 915gm hiding somewhere
<ajax>
i'm sure i do, actually, but it's an eeepc that's in eeepieces
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
<zmike>
sounds like there's no neeepcd to worry then
sdutt has quit []
* jekstrand
really wants SList in Mesa....
<sravn>
mlankhorst: You asked about panels, I assume you refer to the ones that Pengutronix adds where I have been involved
<jenatali>
SList?
<sravn>
mlankhorst: SKOV A/S that I work for produces climate systems including climate controllers. i.MX 6 based running mainline Linux
<sravn>
mlankhorst: So if you have 1000 pigs og 50.000 chicken in the backyard we can help maintain a very good climate for the animals :-)
<jenatali>
I thought that might've been it but thought there was no way you were referencing that :P
<jekstrand>
jenatali: We use something similar in ANV for all our memory allocators but we're currently bending over backwards to deal with 64-bit pointer problems.
<jekstrand>
Mostly because I've not gotten around to implementing a version that doesn't suffer from those.
<jekstrand>
Which Windows has "for free" but Linux, not so much.
<jekstrand>
It's not often that I crave something from the Windows standard library....
<jenatali>
Heh
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
shashank_sharma has quit [Remote host closed the connection]
xexaxo has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
* zmike
quietly renames pbobench nirbench
idr has joined #dri-devel
<mlankhorst>
sravn: Jättebra!
lemonzest has quit [Quit: Quitting]
frieder has joined #dri-devel
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
fso has joined #dri-devel
camus1 has joined #dri-devel
xexaxo has joined #dri-devel
<ajax>
so 21.1.x is the amber branch, yes?
<ajax>
i guess it's probably not going to be 21.0.x
<dcbaker>
I would say 21.2.x at this point, why make it earlier when it could easily be later?
<dcbaker>
unless people just really want it to be 21.1.x
camus has quit [Ping timeout: 480 seconds]
<ajax>
yeah, fair point, 21.2 has classic drivers in it so
<tzimmermann>
danvet, all the vgem-shmem patches should now have my a-b
<dcbaker>
why does nearly every target in mesa have `inc_mesa` in it 😕
<alyssa>
dcbaker: because none of us know what inc_mesa does but we copy it around since it seems important
<airlied>
jenatali: not sure I have knowledge but I'm may end up giving it a hack
<jenatali>
airlied: I gave it a hack too
<jenatali>
We don't validate our SPIR-V, and I just have a quick hack to make the linker able to link an extern kernel with a call to it
<dcbaker>
I think that is mostly comes from the fact that before I refactored ton of it, there was a lot of useful utility stuff in src/mesa, but I moved most of it to src/utils
<dcbaker>
I guess I'll just go on another refactoring spree
<alyssa>
dcbaker: read: I have no idea what inc_mesa actually pulls in
<dcbaker>
the target's I've seen that have actually needed it so far need mtypes.h
<airlied>
ajax: you can get float16 there if the driver enables FP16 I think
<idr>
dcbaker: At some point... most things get mtypes.h, right?
<dcbaker>
I've found quite a few things that include mesa that don't need mtypes.h. Radv has inc_mesa, for example
<ajax>
airlied: that might be the intent, but glsl_type::get_sampler_instance() only handles those three cases (and void but that's not super relevant here)
<airlied>
ajax: I think it gets lowered later
ngcortes has joined #dri-devel
* airlied
isn't sure I just've seen (float16) in my texture return types when I've played with fp16 recently
<alyssa>
airlied: I definitely have but it might depend on what CAPs you set and NIR passes you run
<alyssa>
16-bit support has way too many knobs and a lot of combinations are subtly broken.
<airlied>
jenatali: I might try and give it a real fix then :-P
<airlied>
jenatali: slowly churning through fixing CL3.0 headers in llvm :-P
<jenatali>
\o/
pnowack has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<alyssa>
airlied: one of these days i'm going to actually work through the cl cts on panfrost, huh :V
<airlied>
alyssa: I'd probably wait until clover has at least passed it once :-P
<alyssa>
airlied: that would be the day i'd feel compelled to run panfrost+clover, yes :p
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<airlied>
jekstrand: what fisnormal nir lowering?
* airlied
wonders if you mixing up some internal patches
<alyssa>
too many trees
<jekstrand>
airlied: I thought we had some somewhere
<jekstrand>
airlied: I guess we don't. We should add some. :)
<jekstrand>
airlied: Sounds like something karolherbst probably has a MR for somewhere.
<karolherbst>
could be
<airlied>
jekstrand: I think some gpus have classify support so I'm fine with leaving it to the backend, but I suppose NIR could do the same lowering as the backend
<jekstrand>
airlied: The lowering you're doing in gallivm is exactly what we'd want for our back-end.
<jekstrand>
I mean, maybe we could do something clever with flags but meh.
<airlied>
okay I'll consider lifting it up then
<alyssa>
airlied: bifrost has an FPCLASS.f32 instruction but it's also... kind of useless afaict?
<karolherbst>
alyssa: why is it useless?
<alyssa>
karolherbst: It returns a bitmask (bits for "is negative zero?" "is positive normal?" etc)
<karolherbst>
that looks... kind of usefull, no?
<alyssa>
ostensibly, but for most of the things it tests, testing the relevant bit and getting a boolean out is more alu than just testing the value itself
<karolherbst>
why?
<karolherbst>
you just do a bitwise end, no?
<karolherbst>
*and
<karolherbst>
you can even do a "is positive normal" and "is negative normal" in the same op
<karolherbst>
uhm
<karolherbst>
or
<karolherbst>
not and
<karolherbst>
just need to prepare the mask accordingly
<alyssa>
Yeah, that's fair
<alyssa>
I guess fisnormal() is a valid use for it
<karolherbst>
yeah
<alyssa>
let me see if the DDK uses it for isnormal
<karolherbst>
and all the other CL functions :D
<karolherbst>
but it also allow potential opts if you have more complex checks or so
<airlied>
pretty sure amd have a classify as well
<airlied>
so I'd need to add optional lowering :-P
<karolherbst>
I think it's too complex for nvidia hw
<karolherbst>
let me check :D
<karolherbst>
mhhh.. something similiar
<karolherbst>
but totally odd
<alyssa>
karolherbst: DDK implements isnormal as ((x + x + 0x1000000) > 0x1ffffff)
<alyssa>
i do not understand.
<karolherbst>
alyssa: it checks for nan
<karolherbst>
ohhh wait
<karolherbst>
ehhh
<karolherbst>
the heck
<alyssa>
for fp16, it does ((x << 1) + 0x800) > 0xfff
<karolherbst>
makes sense
<karolherbst>
but no idea why it works though
<jenatali>
I did get some flak for adding fisnormal/fisfinite and not waiting long enough for people to NAK it, but DXIL does have dedicated intrinsics for them so it made sense in my mind to (be able to) send it to the backend
<karolherbst>
but I guess it just fiddles with the exponent
<alyssa>
It is not clear to me why it does `x + x` for fp32 but `x << 1` for fp16 lol
<karolherbst>
alyssa: 32 bit overflow
<karolherbst>
ehhhh
<karolherbst>
wait....
<karolherbst>
alyssa: do x + x and x << 1 differ in terms of overflow handling?
<alyssa>
I don't.. think so
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa>
isnan() is implemented as `fmax_nan_propagate(x, x) != fmax_nan_propagate(x, x)`
<alyssa>
karolherbst: Anyway, for fp32, using FPCLASS to check something will take at least 3 instructions (FPCLASS, bitwise AND, int comparison)
<karolherbst>
yeah...
<karolherbst>
sometimes people add pointless things to the ISA
<alyssa>
whereas all the above lowerings are at most 3 instructions (and slightly easier to schedule)
<alyssa>
For v2f16, the above lowerings can all be vectorized, so /still/ a most 3
<alyssa>
but FPCLASS.f16 can't be vectorized so doing a classify of a vec2 is at least 4 instructions
Miepee has joined #dri-devel
frieder has quit [Remote host closed the connection]
buhman has quit [Ping timeout: 480 seconds]
hwentlan has quit [Ping timeout: 480 seconds]
steev has quit [Ping timeout: 480 seconds]
eric_engestrom has quit [Ping timeout: 480 seconds]
narmstrong has quit [Ping timeout: 480 seconds]
cwabbott has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: uhhh
<karolherbst>
now it feels like wasted transistors
<alyssa>
bad design decisions?
<alyssa>
in Bifrost?
zzag has quit [Ping timeout: 480 seconds]
<alyssa>
surprised pikachu
jjardon has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
camus1 has joined #dri-devel
<alyssa>
karolherbst: If Bifrost had a bit test instruction, and if the fp16 classify were vectorized, it would be a lot more useful.
<Miepee>
Hello! I'm having some strange behaviour on what I assume is Mesa related as so far I only had it appear on AMD Cards. On Game Maker Studio games, when you execute the executable, it will crash if the executable is not named a certain way. Backtraces are different each time, but generally follow the pattern of libc calls libpthread calls radeonso_ri calls libLLVM and crashes there.
<Miepee>
I was able to remedy the crashes by, as explained above, renaming the executable, but it's also possible by using one of the following environment variables: "600_DEBUG=mono", "R600_DEBUG=vs.ps", or "R600_DEBUG=check_vm". Although these seem to be a little less consistent, as the same cards can still need a different env var
<Miepee>
all right i think i managed ti get into the right channel again. @kisak no i did not know of that list, but can confirm tga
<Miepee>
*that using radeon_si_sync compile works as well.
nirmoy has quit []
<airlied>
agd5f: hey that fixes pull has an Ack that should be an SOB
<airlied>
drm/amd/pm: update yellow carp pmfw interface version
<airlied>
can you fix that up?
<Lyude>
Anyone know if there's a way to do a git cherry-pick that would allow you to map certain file paths to different files?
<pcercuei>
format-patch, edit manually maybe?
<Lyude>
pcercuei: well yeah I could do that, but i'm mostly wondering if git actually has anything built-in for handling this.
<alyssa>
are you really using git if you're not editing hunks by hand
<alyssa>
("...Yes")
Duke`` has quit [Ping timeout: 480 seconds]
steev has joined #dri-devel
<airlied>
so v3d and midgard appear to set lower_bit_count, but looking at nir_lower_alu the pass never runs just for that flag, granted it might run because of other flags
ngcortes has quit [Ping timeout: 480 seconds]
<HdkR>
alyssa: Asahi backend on native linux doesn't currently hook up to anything right?
buhman has joined #dri-devel
<dcbaker>
ajax: rebased !10153, though I ended up rewriting the last couple of patches as it was easier than rebasing them
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<alyssa>
HdkR: Correct. Kernel driver Coming Soon
<alyssa>
the only reason mesa+asahi builds on linux at all right now is for CI buildtests
<HdkR>
I can confirm it builds for x86/x86-64 as well :P
<alyssa>
Funny
<ajax>
but does it build for m68k
<dcbaker>
I greatly appreciate that, as a release maintainer :)
gouchi has quit [Remote host closed the connection]
<airlied>
jekstrand: is nir_lower_alu the wrong place to lower fisnormal?
<alyssa>
airlied: fwiw bit count is probably broken on midgard due to other issues
<alyssa>
so ignore what it does, it's probably not what I intended :p
ngcortes has joined #dri-devel
<jekstrand>
airlied: Lower it in opt_algebraic
Miepee has quit [Quit: AtomicIRC: The nuclear option.]
Miepee has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<airlied>
jekstrand: that would mean I had some idea how to write opt_algebraic, at the moment it's just a lot of () to me :-P
<jekstrand>
airlied: It's easy. There are even instructions at the top of the file.
<Kayden>
it's search and replace
<Kayden>
(pattern to detect, pattern to replace with)
<airlied>
yeah just the replacement for isnormal isn't a simple expression
<airlied>
it needs INFINITY and FLT_MIN
<jekstrand>
airlied: FLT_MIN is tricky
<jekstrand>
airlied: for infinity, you should be able to use whatever python has
<alyssa>
it modetests! :D
<jekstrand>
alyssa: \o/
<alyssa>
no connectors or framebuffers though uhhh
<airlied>
jekstrand: you want to import numpy into opt algebraic? :-)
<jekstrand>
airlied: LOL, no.
<alyssa>
`from valhall import instructions`
<jekstrand>
airlied: If you need all the crazy, maybe lower_algebraic is the place.
<airlied>
oh python3 has math.inf I think
<dcbaker>
airlied: float('inf') IIRC
<dcbaker>
or `'-inf'`
milek7 has joined #dri-devel
milek7 has quit [Remote host closed the connection]
<dcbaker>
or `math.inf` seems to be a thing as well
<alyssa>
I can use GEM... right? maybe? :|
<airlied>
of course python floats are doubles
* airlied
is backing away slowly from nir_opt_algebraic for this
<jekstrand>
airlied: Yeah, the min float stuff is going to be annoying with different bit sizes
soreau has quit [Remote host closed the connection]
* airlied
hasn't handled bit sizes properly anyways yet
<Kayden>
could put in rules for each bitsize and include the hex representation of the float...
<jekstrand>
That works
<airlied>
Kayden: that seems like the opposite direction to maintainable
soreau has joined #dri-devel
Miepee has quit [Quit: AtomicIRC: The nuclear option.]
<airlied>
I could just write it in C with the defines
xexaxo has quit [Read error: Connection reset by peer]
<ajax>
how bad could it be? let me just take a big sip of my coffee while i check how many float types opengl has...
* airlied
wonders why nir_opt_algebraic isn't written in lisp :-P
<Kayden>
only 3 bitsizes...
<airlied>
so 3 infinties and 3 mins
<alyssa>
ajax: if you're not packing 11-bit floats with 10-bit floats in the same word, what are you doing tbh
* alyssa
doesn't understand who calls drm_framebuffer_init
<alyssa>
like, in meson/
xexaxo has joined #dri-devel
<ajax>
do we count s9e5 here
<alyssa>
I have .fb_create = drm_gem_fb_create
<alyssa>
that should be enough right..?
mbrost has joined #dri-devel
<alyssa>
oh
milek7 has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
<jekstrand>
dcbaker: How do I make a file only build on x86_64?
<dcbaker>
if host_machine.system() == 'x86_64'
<dcbaker>
target_files += files('x86_64-only.c')
<dcbaker>
endif
<jekstrand>
cool
<dcbaker>
ironically I've ripped inc_mesa out of almost everything, except the intel stack. At least some of our compilers are just too deeply entwined with it
<jekstrand>
dcbaker: How do I detect a particular instruction when configured with the CC build flags?
<dcbaker>
you want to know if a particular option is set?
<jekstrand>
I want to know if the build flags guarantee I have CMPXCHG16B or not
<dcbaker>
you can get whatever is in $CFLAGS or -Dc_args with `get_option('c_args')`, then you could pass those to a `CCompiler.compiles()`
<dcbaker>
I think $CFLAGS aren't normally passed to `Compiler.compiles()` for reproducability reasons
hwentlan has joined #dri-devel
pcercuei has quit [Quit: dodo]
jhli has joined #dri-devel
Company has quit [Quit: Leaving]
danvet has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
<jenatali>
dcbaker: While we're talking meson... is there a way to set `default_options` differently per platform / compiler? I want to use a default warning level for MSVC builds (at least) of 2 for Mesa
ngcortes has quit [Ping timeout: 480 seconds]
<jekstrand>
dcbaker: How do I add a compiler flag for just one file?
<jenatali>
jekstrand: Build it as a separate target?
<jekstrand>
Yeah, I think that's what I have to do
<jekstrand>
'tis annoying but oh, well.
<HdkR>
Just set minspec to CMPXCHG16B O:)
<jekstrand>
HdkR: It's tempting.....
<jekstrand>
Or I can just rely on new GCC/clang which call out to libatomic and let handle this mess
<HdkR>
If only function multiversioning didn't suck
jessica_24 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
iive has quit []
jhli has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
macromorgan has quit [Remote host closed the connection]