ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<computermouth>
kisak: I don't think that's inherently a problem. So long as I can static link everything, and drop the drm and x11 requirements
<computermouth>
the drm dependency is more of a question to me. I was thinking this would be an entirely userspace library, and maybe it still can be, but I just don't know enough about how drm functions there
<itoral>
fwiw, it only happens when I run against my compiled version of mesa, running against the system's mesa works fine
<gfxstrand>
Does your compiled mesa have a GL build?
<itoral>
yes
<gfxstrand>
IDK why deqp-vk grew a GL dep but it did
<gfxstrand>
hrm...
<itoral>
yeah, that puzzled me as well
<gfxstrand>
IDK what the driver load path with glvnd looks like but I wouldn't expect glvnd to be involved with a custom mesa build
<itoral>
mmm... I see that my build of mesa doesn't have the glGetInternalformativ symbol, but the system's version does
<gfxstrand>
I wonder why I'm not hitting this
<itoral>
yeah, I only started to hit this when setting up a new laptop
<itoral>
doesn't happen to me on the old one
<gfxstrand>
woof
<itoral>
well, on my old laptop my custom built mesa doesn't have the symbol either :-/
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
<gfxstrand>
Is your CTS building against libGL or libOpenGL?
<gfxstrand>
Hrm... I'm seeing GetInternalformativ in both of them on my system
<itoral>
how can I check that? the cmake output doesn't specify
<itoral>
mmm... interesting
<gfxstrand>
Ok, so on my system, I have GetInternalformatiV on the system libGL and libOpenGL but not on my mesa build
<itoral>
ah, ok
<itoral>
so same as me then
<gfxstrand>
but deqp-vk seems to be fine
fab has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ngcortes has joined #dri-devel
<MrCooper>
itoral: sounds like a deqp-vk bug, pretty sure glGetInternalformativ isn't part of the ABI of any shared library (i.e. GetProcAddress needs to be used for it)
<itoral>
maybe, but why is it not affecting everyone else?
rasterman has joined #dri-devel
mvlad has joined #dri-devel
<gfxstrand>
And why are the system-installed versions providing it?
jkrzyszt has joined #dri-devel
ppascher has joined #dri-devel
<MrCooper>
glvnd versions may expose more symbols, doesn't mean they can be relied on
<itoral>
fwiw, it seems I "fixed" the problem by setting --libdir <install>/lib instead of <install>/lib64
<itoral>
and then recompiling CTS again
<gfxstrand>
ugh
lynxeye has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
phasta has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
yogi has joined #dri-devel
tango_ has joined #dri-devel
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #dri-devel
jdavies has joined #dri-devel
Guest3218 has quit [Read error: Connection reset by peer]
jdavies is now known as Guest3240
jdavies_ has joined #dri-devel
pcercuei has joined #dri-devel
Guest3240 has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
vliaskov has joined #dri-devel
yogi has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
Haaninjo has quit [Remote host closed the connection]
zaratustra has joined #dri-devel
ice9 has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
phasta has quit [Quit: Leaving]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
itoral__ has joined #dri-devel
itoral_ has quit [Ping timeout: 480 seconds]
Zopolis4 has quit []
jdavies_ has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
phasta has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
itoral__ has quit [Remote host closed the connection]
<haasn>
so where does VK_EXT_headless_surface exist at all anymore? not?
<haasn>
I could have sworn it existed in the past on mesa
<haasn>
but I can't find any reference to it in the code now
<daniels>
you don't need one? you can just create VkImages without a swapchain in Vulkan
<haasn>
daniels: I need it for my test framework
<haasn>
to test the swapchain code
X512 has joined #dri-devel
<X512>
I use Vulkan headless surface as gateway for displaying contents on Haiku windows.
<bbrezillon>
airlied: didn't implement async bind/binding yet (VM_BIND), and I thought it'd be safe to allocate mem in the VM_{MAP,UNMAP}, since, AFAICT, there's no fence signaling involved there
kzd has joined #dri-devel
<bbrezillon>
but yeah, we'll have problems when/if we want to support VM_BIND
fab has quit [Quit: fab]
zehortigoza has joined #dri-devel
<X512>
For first time I got Vulkan headless surface by using vulkan-wsi-layer in Mesa repo group.
<X512>
Now I made own Haiku WSI Layer add-on but it still works throuth headless surface.
<Ristovski>
Nice!
<X512>
Adding new Vulkan WSI surface type is not trivial.
X512 has quit [Quit: Vision[]: i've been blurred!]
alyssa has joined #dri-devel
<alyssa>
anyone have test coverage for ASTC with border colours?
<alyssa>
i guess i could extend texwrap ..
* alyssa
extends texwrap begrudgingly
<mareko>
you can also just do nothing
<alyssa>
I can?
ngcortes has joined #dri-devel
Guest3270 has quit [Remote host closed the connection]
<alyssa>
if test coverage doesn't exist the feature can't hurt me? :-p
junaid has quit [Ping timeout: 480 seconds]
<anholt>
do the deqp-gles border color tests not cover astc?
<anholt>
khr-gles maybe I meant
<alyssa>
deqp-gles doesn't
<alyssa>
maybe khr, let's see
<alyssa>
not seeing anything in khr either
<alyssa>
and piglit tests BCn but not ASTC
<anholt>
-t border_clamp was the thing I was thinking of, and looks like it doesn't.
<alyssa>
nod
<alyssa>
Undecided between asserting out or doing a guess in the dark
bluebugs has joined #dri-devel
moa has quit [Ping timeout: 480 seconds]
<airlied>
gfxstrand: would rust be much nicer for vulkan drivers if we just decided to not deal with the common code? like I wonder if there is a nicer win in just redoing it
frieder has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<anholt>
I have a suspicion that rust drivers would end up wanting to rewrite vk common at some point. but some incrementalism would probably be good.
jkrzyszt has quit [Remote host closed the connection]
<daniels>
can't wait to see wsi_common_xcb.rs
<airlied>
wsi is mostly a layer anyways
<airlied>
so we might be able to push that out a bit
<daniels>
there is the separate layer project on GitLab, but it's ... not good
<airlied>
no even in mesa we wrote it to act like a layer
<airlied>
it might have degraded a bit, but I'm sure we could firm up the boundaries
<airlied>
it's more the entry point generators and the sync code I suppose
<alyssa>
daniels: can't wait to see x11.rs ;p
<gfxstrand>
airlied: Yeah, I think we'd want to go in stages:
<gfxstrand>
1. Wrappers similar to what I put in that MR
<gfxstrand>
2. Modify the C code to make all the structs memmove-able. I.e., no more struct list_head.
<airlied>
zmike: llvmpipe reboot in rust...
<gfxstrand>
3. Start replacing bits of common code with Rust, starting with vk_object_base.
<emersion>
oh you don't want to deal with Pin<T>?
<gfxstrand>
Pin<T> is a pain
* emersion
is disappointed
tzimmermann has quit [Quit: Leaving]
<airlied>
gfxstrand: just replace all the list_head with u_dynarray?
<gfxstrand>
Also, even if you use Pin<T>, you still have an initialization problem where things like list_head can't be initialized by creating one and then moving into the final location.
<gfxstrand>
airlied: Initially, yeah, probably.
<emersion>
i thought you were more brave, but it turns out you're a sane person :P
<gfxstrand>
I don't really like dynarray, personally. It always feels less typesafe than list_head to me.
<gfxstrand>
emersion: Well, "sane" might be a bit of a stretch.
<airlied>
gfxstrand: make a typesafe dynarray :-P
<gfxstrand>
emersion: The other option would be for Rust to grow some sort of a concept of placement-new.
<emersion>
yeah you need to pin and then mutate
<gfxstrand>
airlied: You mean like Vec<T>?
<emersion>
it's not great at all
<emersion>
and project the pin when mutating ofc
<airlied>
but more of the I think we should do that pre-rust anyways, being nice to caches
<airlied>
gfxstrand: just write a Vec<T> equiv in C first then :-)
<gfxstrand>
airlied: The few things we use list_head for aren't gonna be hot in anyone's cache.
<gfxstrand>
It's stuff like walking all the physical devices.
<gfxstrand>
Bit meh
<airlied>
yeah but it would be nice to get it consistent before rusting it
<gfxstrand>
But, yeah, once we get all the C types moveable, that'll make rust binding a lot easier.
<gfxstrand>
And we can have pub fn vk_foo_init(*mut foo, ...) { foo.write(Foo::new(...)?); Ok() }
<gfxstrand>
So it's easy to move stuff over one thing at a time.
<gfxstrand>
The big thing is that I think it'd be easiest to start with BaseObject so that everything else can do VkImage { base: BaseObject::new() ... }
<airlied>
hey so has anyone got a good link to anything that helped them "get rust"?
<gfxstrand>
Nope
<gfxstrand>
For me, it's just been spending time with it
<anholt>
airlied: I feel like I've asked this before, but how do I dump the LLVM ir generated?
<gfxstrand>
But the key is don't fight it.
<airlied>
ah okay, guess I gotta go old school and grind
<Sachiel>
leaving a sheet of iron out in the open will get you plenty of rust
<airlied>
anholt: GALLIVM_DEBUG=ir
<anholt>
thanks
<airlied>
Sachiel: I have a car to do that :-P
<gfxstrand>
If you fight it, it'll just be frustrating and clearly worse C.
<anholt>
was looking in lp_debug
<Sachiel>
gfxstrand: what do you mean by not fighting it?
ybogdano is now known as Guest3291
ybogdano has joined #dri-devel
<emersion>
from my PoV, you fight it whether you want it or not
<gfxstrand>
When you run into trouble, don't reach for unsafe or try to fight the borrow-checker. Take a step back and ask if there's a different way you could structure your code that doesn't rely on weirdly linked data structures.
<gfxstrand>
Often, there is.
<gfxstrand>
The more you do that, the more you learn to let rust work for you instead of against you.
<anholt>
gfxstrand: yes, exactly
clever has joined #dri-devel
<gfxstrand>
Of course, it depends on what you're trying to do. If you're writing a Wayland compositor, that's gonna be hard. You're going to have Arc and Rc everywhere because that's the way Wayland wants to work. You're not really fighting Rust in that case, you're fighting to very different ways of thinking about problems.
<gfxstrand>
*fighting the mismatch between two very different ways of thinking about problems.
rsripada has joined #dri-devel
<gfxstrand>
Unfortunately, a legacy C code-base like Mesa is going to have a LOT of Cisms that are difficult to work around.
<gfxstrand>
Not the best environment for learning Rust.
mdnavare has joined #dri-devel
aswar002_ has joined #dri-devel
aknautiy_ has joined #dri-devel
<alyssa>
gfxstrand: Yeah, I know how you feel about Cisms
aknautiy has quit [Ping timeout: 480 seconds]
TheSwordOfMyBone has quit [Ping timeout: 480 seconds]
dolphin has quit [Ping timeout: 480 seconds]
rsripada_ has quit [Ping timeout: 480 seconds]
mdnavare_ has quit [Ping timeout: 480 seconds]
aswar002 has quit [Ping timeout: 480 seconds]
<gfxstrand>
alyssa: 🥚
dolphin has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
nchery is now known as Guest3293
nchery has joined #dri-devel
fdu has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
fdu_ has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
Guest3293 has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: to office]
Zopolis4 has joined #dri-devel
jkrzyszt has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
<alyssa>
how do I have this many commits on top of main in my {agx,panfrost}/next branches
<alyssa>
when did I become Android
columbarius has joined #dri-devel
* ccr
ponders if alyssa has a positronic brain.
co1umbarius has quit [Ping timeout: 480 seconds]
<HdkR>
alyssa: Watch out, Google might want you to work on the Android Graphics stack
<alyssa>
oh no
<alyssa>
or oh yes?
<alyssa>
is that good or bad?
<alyssa>
you say it like a threat
<HdkR>
The Android Graphics Stack stares back menacingly
<alyssa>
emersion: do I want to work around a wlroots bug in mesa yes or no
<emersion>
no!
<emersion>
what is the bug?
<alyssa>
using mediump texture coordinates
<alyssa>
which a conformant GLES driver is allowed to implement as fp16
<alyssa>
which is not enough precision for 4K textures
<alyssa>
which means blocky artefacts on the right side of the screen
<alyssa>
i'm tempted to workaround in mesa anyway, I already do so on Panfrost and I expect there are piles and piles and piles of broken apps with this exact bug
<emersion>
weston has the same bug FWIW
<alyssa>
delight
<emersion>
does the "precision mediump float" has any say in this?
<emersion>
i'll type the wlroots patch, it'll make it in 0.16.2
<alyssa>
the precision mediump float line sets the default shaderwide
<alyssa>
it's fine if the output variable is fp16, it's just the texture coordinates that need the extra precision
<emersion>
ah maybe Weston is fine since... recently
<alyssa>
TBH I expect piles of stuff in the wild will break if I try to optimize this so I'm just going to.. not
<alyssa>
since I'd rather not play driconf whack-a-mole for something that probably doesn't matter for perf
bgs has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
<emersion>
i probably need to use highp for the matrix as well
<alyssa>
possibly
agd5f has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<alyssa>
the GLSL precision qualifier was the biggest mistake in GLSL imho
<alyssa>
there is no way to use it unproblematically
agd5f has joined #dri-devel
<jenatali>
Probably the same reason D3D added it. It makes some hardware go brrr
<airlied>
at least on mobile, it makes some hardware go
agd5f_ has quit [Ping timeout: 480 seconds]
<daniels>
ugh
<mattst88>
yeah, but the precision qualifiers themselves and the optionality of it all is terrible
<daniels>
looking at Weston, we set 'precision highp float' if GL_FRAGMENT_PRECISION_HIGH is set ... but only in the frag shader, and that macro is only ES3.1+
<daniels>
oh, but Mesa defines it for all ES contexts
<daniels>
alyssa: know off the top of your head what happens if we have 'varying vec2 v_texcoord' in both VS&FS, but 'precision highp float' only in FS, and nothing defined in VS?
<emersion>
lol
<emersion>
that sounds fun
<zmike>
airlied: I'm on it
<emersion>
bleh i'm not even sure what the right fix is
apinheiro has quit [Ping timeout: 480 seconds]
<anholt>
30 -> 1.7 seconds on these llvmpipe tests. now to just make them pass again. :/
<emersion>
in strict GLSL 1.20, mediump doesn't actually exist
vliaskov has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
ngcortes has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
<alyssa>
daniels: "know off the top of your head what happens if we have 'varying vec2 v_texcoord' in both VS&FS, but 'precision highp float' only in FS, and nothing defined in VS?"
<alyssa>
If separable shaders are used, that's invalid
<alyssa>
Otherwise the precisions get linked together. Unsure what Mesa will produce for that particular combination, possibly mediump
<alyssa>
oh right but emersion pointed out VS defaults to highp, not defaults to mediump (different from FS) because of course
<alyssa>
so yes that will give you highp
Duke`` has quit [Ping timeout: 480 seconds]
<emersion>
""""sane""""
<alyssa>
literally
<alyssa>
emersion: strictly, the wlroots commit message isn't right
<alyssa>
(even though the patch is)
<alyssa>
2^14 = 16384, which is plenty
<alyssa>
the issue is the precision
<emersion>
eh
<alyssa>
IEEE 754 fp16 floats have a max value of about 65k
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
so overflow isn't a problem
<alyssa>
for tex coords
<mareko>
are you sure?
<alyssa>
the problem is they only have 11 bits of significand
<mareko>
the exponent should give you much higher values than 65K
<alyssa>
which means consecutive integers near 4096 have identical fp16 representations => precision loss => wrong pixels are sampled
<alyssa>
mareko: 5 bits of exponent, but the exponent is signed
<mareko>
ok
<alyssa>
so 0b1111 = 15 is the maximum exponent (2's complement representation)
<mareko>
it's indeed +-65504
<alyssa>
rig
<alyssa>
right, giving a maximum value of
<alyssa>
>>> (2**15) * (1 + (1 - (1/(2**10))))
<alyssa>
65504.0
<alyssa>
(...Knowing IEEE 754 arithmetic by heart is an occupational hazard :|)
<alyssa>
emersion: anyway, floats in [2047, 4094) have an exponent of 10
<emersion>
yeah that makes sense
<alyssa>
so mantissa bits corresp-- hold on I have an off by one somewhere
<HdkR>
Sounds like typical float problems. just off by a ulp
ngcortes has quit [Remote host closed the connection]
<HdkR>
;)
<alyssa>
right yes there it is
<mareko>
there is one value above 65504 though: +inf