<Lynne>
"if os.path.isdir('/usr/lib64') and not os.path.islink('/usr/lib64'):"
<Lynne>
well, on my debian system, /usr/lib64 exists, and contains ld-linux-x86-64.so.2, and I had a flashback to wondering why it's there and what happened when I decided to remove it
<psykose>
:p
<psykose>
so meson will default to the debianlike block i guess unless that fails and then use lib64
tarceri has quit [Ping timeout: 480 seconds]
djbw has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
<kode54>
the mesa-git package I used uses arch-meson and doesn't pass --libdir for the 64 bit target
<kode54>
the issue was that the mesa scripts installed stuff to lib64, then the pkgbuild tried to create a symlink in lib
<kode54>
which it assumed existed
bgs has quit [Remote host closed the connection]
yuq825 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
KaitoDaumoto has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
nchery has quit [Quit: Leaving]
<kode54>
psykose, the arch-meson script does:
<kode54>
--prefix /usr
<kode54>
then --libexecdir lib
<psykose>
and so no libdir set in it
<kode54>
guess that pkgbuild I use needs to be set
camus has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<tleydxdy>
it does sound like a issue that'll affect all arch-meson package, might best be fixed in arch-meson?
<psykose>
offtopic but in alpine we have the same kind of wrapper and pass --libdir /usr/lib for that, not sure why arch didn't, maybe they thought it was merely redundant?
<psykose>
open an arch bug and find out :p
off^ has joined #dri-devel
jljusten has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
<HdkR>
asdasd/win 10
<HdkR>
Yep, that's how brains work
kimbro has joined #dri-devel
sarnex has quit [Quit: Quit]
heat has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
flto_ has quit []
flto has joined #dri-devel
aravind has joined #dri-devel
kimbro has quit [Ping timeout: 480 seconds]
antoniospg____ has joined #dri-devel
Jeremy_Rand_Talos has joined #dri-devel
bmodem has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
RhineDevil^ has quit [Remote host closed the connection]
RhineDevil^ has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
lemonzest has joined #dri-devel
<kode54>
figured it out
<kode54>
it wasn't anything they did
<kode54>
or that arch did
<kode54>
it was because I stupidly untarred an archive to root (a modified opencl icd binary) that replaced my /usr/lib64 symlink with the folder from the archive
<kode54>
which in turn rendered /bin/bash inoperable as well
<kode54>
which in turn caused dracut to generate corrupted images
<kode54>
good thing I know my way around a rescue system
Danct12 has quit [Remote host closed the connection]
aravind has joined #dri-devel
Company has quit [Quit: Leaving]
kts has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
bgs has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
fab has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
Danct12 has joined #dri-devel
kts has quit [Quit: Leaving]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
off^ has quit [Remote host closed the connection]
ahajda has joined #dri-devel
jluthra has joined #dri-devel
fab has quit [Quit: fab]
sgruszka has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
rszwicht has joined #dri-devel
tursulin has joined #dri-devel
lynxeye has joined #dri-devel
elongbug__ has quit [Read error: Connection reset by peer]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rszwicht has quit []
rszwicht has joined #dri-devel
rszwicht has quit []
jljusten has joined #dri-devel
rasterman has joined #dri-devel
fab has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
dcz_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
xyb has joined #dri-devel
xyb has quit []
rszwicht has joined #dri-devel
rszwicht has quit []
rszwicht has joined #dri-devel
rszwicht has quit [Read error: Connection reset by peer]
bmodem has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
bmodem has joined #dri-devel
kts has joined #dri-devel
sarahwalker has joined #dri-devel
mvlad has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
sarahwalker has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
elongbug__ has joined #dri-devel
elongbug__ has quit [Remote host closed the connection]
junaid has joined #dri-devel
elongbug__ has joined #dri-devel
elongbug__ has quit [Remote host closed the connection]
elongbug__ has joined #dri-devel
elongbug__ has quit []
elongbug has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<danvet>
mripard, I pulled your pull, maybe forward drm-misc-fixes to drm-fixes so that -next shows up in linux-next like it should?
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
RhineDevil has joined #dri-devel
bgs has quit [Remote host closed the connection]
RhineDevil^ has quit [Ping timeout: 480 seconds]
<mripard>
done
bmodem has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
Akari has quit [Quit: segmentation fault (core dumped)]
Jeremy_Rand_Talos has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
dri-logger has quit [Remote host closed the connection]
dri-logger has joined #dri-devel
mareko has quit [Remote host closed the connection]
mareko has joined #dri-devel
<melissawen>
danvet, not yeat, but I will (or maybe siqueira)... vkms is somewhat broken after dont-know-yet DRM changes and mairacanal is debugging/working on stabilizing it
jkrzyszt has joined #dri-devel
camus has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
camus1 has quit [Read error: Connection reset by peer]
rahul_janga has joined #dri-devel
rahul_janga has quit []
<danvet>
tzimmermann, can you help me remember to ping airlied when he's back next week about the legacy driver removal?
<tzimmermann>
danvet, sure
dri-logger has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
jewins has joined #dri-devel
<danvet>
mripard, [PATCH] drm/vc4: Fix refcount leak in vc4_hvs_bind
<danvet>
in case you missed
frytaped has joined #dri-devel
<danvet>
emersion, thx for reviewing some of the drm printing patches, you're also going to push them?
<danvet>
or waiting for respin?
frytaped has quit [Remote host closed the connection]
frytaped has joined #dri-devel
kts has joined #dri-devel
<danvet>
tzimmermann, an absolute horrible idea just crossed my mind for the fbdev default format saga
<danvet>
could we change the parameter to u32 and do a horrible check if the value is > 32, the assume it's a drm fourcc code?
<danvet>
and then gradually move all the drivers over to either going with the default of 0 and letting the helpers auto-select
<danvet>
or a real fourcc code?
<danvet>
I fear otherwise we'll never get out of this mess
<tzimmermann>
danvet, didn't we want to add something like a preferred_format field to drm_mode_config and set the format there?
<tzimmermann>
if set, fbdev emulation would use it
<danvet>
yeah, but that misses the vc4 case
<tzimmermann>
otherwise fall back to the current crazyness
<danvet>
and some other ones, where we want fbdev to just use something much less
<danvet>
and yeah mode_config could use the same trick maybe?
bgs has joined #dri-devel
<tzimmermann>
tbh, i'm not sold on the idea of treating fbdev different from the other clients. it now uses 16-bits for the console to adapt to low memory. but how is that different from the other clients?
<danvet>
mostly it's telling that no one cares that much about fbdev
<danvet>
but yeah
<danvet>
mripard, ^^
<danvet>
maybe these distros should have a kernel cmdline that supplies a bunch of low-res fbdev formats or something
MajorBiscuit has joined #dri-devel
<tzimmermann>
and on the rpi4, the 16-bit setting feels out of place. in my opinion, we fbdev should go with the default. setting a low-mem policy seems system-specific
<danvet>
yeah ...
<tzimmermann>
well, there's always video=-32
<tzimmermann>
on the kernel command line
Haaninjo has joined #dri-devel
<mripard>
the Pi4 also uses CMA
<tzimmermann>
i mean, 8 GiB of it
<mairacanal>
tzimmermann: about the default value, after 37c90d589dc0, I'm having a problem with the depth default value on the vkms. I'm getting a similar error as the vc4 in the vkms, but with the following output "[drm] bpp/depth value of 32/0 not supported". When I use the preferred_depth as 0, it is not changing to the default depth of 24 apparently.
<danvet>
mairacanal, since I spot you, I dropped some comments on the addfb format check patches, pls look before you push
<mairacanal>
I checked! Thanks for the feedback!
<tzimmermann>
mairacanal, we should set a default depth in vkms. or maybe let fbdev pick some useful value
jkrzyszt has quit [Remote host closed the connection]
<danvet>
oh the epic bpp vs depth confusion
<danvet>
or not
<danvet>
I guess we lost the default cases for when preferred_depth is 0?
<mairacanal>
danvet, it seems like it
<tzimmermann>
i just fixed a lot of confusing bpp/depth handling. some fallout is expected
<danvet>
tzimmermann, the other option is that you need to figure out preferred depth before you pass it down
<tzimmermann>
i'd rather go through drivers and fix them one by one, if necessary
<tzimmermann>
or what you just suggested
<danvet>
but as-is it doesn't work, because we seem to end up with preferred_depth=0 in there, and no such format exists
<danvet>
it's 100 or so
<danvet>
so interim we need to handle preferred_dept=0 somehow
<tzimmermann>
i'll add code to handle it
<tzimmermann>
if we have no bpp given, 32 is the default
<tzimmermann>
and from the bpp we can select a meaningful depth
<danvet>
yeah
<mairacanal>
before the change, it used to be 24
<danvet>
yeah for 32bpp it's 24
jkrzyszt has joined #dri-devel
<danvet>
and for 16, 8 it just matches
<danvet>
nothing else should be needed
<tzimmermann>
or even simpler: where it says "No compatible format found", we can always select 32/24
<tzimmermann>
that's xrgb8888. drivers are expected to provide it
fab has quit [Quit: fab]
Guest342 has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, that might change defaults in a few cases
<danvet>
hm
<tzimmermann>
really?
<danvet>
ok I think I see what's going on now
<danvet>
we can't mix up the preferred_bpp we get as parameter with mode_config.preferred_depth
<danvet>
because a ton of drivers only set one or the other
<danvet>
so if we have preferred_bpp, we should _only_ use that to filter formats
<danvet>
if we don't have that, then we can use preferred_depth
<danvet>
but mixing them up gives us all kinds of fun
Duke`` has joined #dri-devel
<danvet>
like the preferred_bpp for fbdev of 16 and preferred_depth of 24 or so
<danvet>
so new idea
<tzimmermann>
it's not so easy. we can have xrgb1555 in simpledrm et al. that's 16/15. we need to communicate both values to fbdev
<danvet>
if we have a preferred_bpp, we convert that directly into a fourcc
<danvet>
yeah, but only after we looked up what the driver supports
<danvet>
hm this is a nice mess
<danvet>
because we also need to pick the right fourcc from the driver, we can't hardcode
<danvet>
because of big endian lol
<tzimmermann>
that's what drm_fb_helper_find_format() is for
<tzimmermann>
it picks a supported fourcc code from bpp/depth
<danvet>
yeah but it's not good enough
<danvet>
because in most cases we only have either bpp or depth
<danvet>
not both
<tzimmermann>
indeed
<danvet>
that's the root cause of this entire mixup
<tzimmermann>
i think we should add the logic directly to drm_fb_helper_find_format()
<danvet>
and because of drivers like vc4, you cannot even assume that the fbdev preferred_bpp and the mode_config.preferred_depth refer to the same thing
<danvet>
yeah that's what I suggested
<danvet>
more or less
<tzimmermann>
ok
<danvet>
we need to additionally make sure we don't mix up fbdev and mode_config
<tzimmermann>
what do you mean by mix-up?
<danvet>
so the mode_config.preferred_depth can only be passed around if we have a 0 fbdev preferred_bpp
<danvet>
otherwise you end up with bpp=16 preferred_depth=24 or some fun
<tzimmermann>
no that does not work
<danvet>
(not sure we have such a driver, but that's essentially what vc4 wants)
<danvet>
it did before
<tzimmermann>
because of the xrgb1555 case
<tzimmermann>
the current assumption is that there's a valid pair bpp/depth. this apparently breaks several drivers. IMHO the best fix is to try to auto-detect the values that are 0
<danvet>
yeah
<tzimmermann>
so if bpp==0, try to get a compatible bpp from depth
<danvet>
but additionally, you cannot assume that the values you get are a pair
<danvet>
which means, one of them is always 0 in find_format
<tzimmermann>
and if depth==0, get it from bpp
<tzimmermann>
why is one always 0?
<danvet>
it has to
<tzimmermann>
why?
<danvet>
they're entirely unrelated, drivers actually set different format preferences for mode_config (userspace) than fbdev
<danvet>
so if you just smash them, then it'll fail in the cases where the preference differs
<danvet>
so it's either a) use preferred_bpp to look up, guess depth or b) use mode_config.preferred_depth to look up, pick first format with right depth
<danvet>
not both at the same time
<tzimmermann>
no
<tzimmermann>
it's expected to get both values from the driver. if that does not work, we can still try to fix it up
<danvet>
that would be the reasonable thing
<danvet>
but this isn't very reasonable
<danvet>
they are different, you can't use them together and assume it'll make sense
<tzimmermann>
having just one of them has lead to numerous problems in the past
<danvet>
for added infuriation, they're also different in the bpp vs depth sense
<danvet>
yeah that's why the find_format needs to look which format fits best for a driver
<danvet>
and why we should just pass fourcc codes around
<danvet>
but alas, lots of drivers
dcz_ has quit [Ping timeout: 480 seconds]
<tzimmermann>
i don't disagree. it's just that your assumption of taking one value and easily guessing the other is wrong. that has not worked in the past and lead to numerous problems. guessing here comes down to brute-force trying out combinations
<tzimmermann>
i have to leave now. let me send a patch and disuss that instead. it seems the discussion is currently going nowhere
<tleydxdy>
when a process is killed, how does the kernel find it's gpu contexts and free them? I'm specifically looking at amdgpu_ctx
mbrost has joined #dri-devel
<HdkR>
Probably the same way it finds FDs and frees them
<HdkR>
:)
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
<tleydxdy>
which is?
<HdkR>
Sadly that bit is beyond me since I'm not a kernel dev
<tleydxdy>
I tried to search everywhere that leads to kfree(ctx) and I can't find anything that does it
<tleydxdy>
only thing is the free ioctl
ybogdano has joined #dri-devel
<tleydxdy>
ig somehow it's a side effect of closing the amdgpu_device?
sarahwalker has quit [Remote host closed the connection]
<mlankhorst>
drm_file bookkeeping
jfalempe has quit [Ping timeout: 480 seconds]
dcz_ has joined #dri-devel
ybogdano has quit [Quit: Ping timeout (120 seconds)]
ybogdano has joined #dri-devel
heat has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
pallavim has joined #dri-devel
nchery has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
MajorBiscuit has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<sravn>
macromorgan: Change the prototype to struct mipi_dsi_host * drm_of_get_dsi_bus(struct device *dev, struct mipi_dsi_device_info *info) and return an ERR_PTR in case of failure.
<sravn>
macromorgan: This is what I think mripard suggests, and it is more in line with what we do in other places so I like it.
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
kts has quit [Quit: Leaving]
<jenatali>
Looking at the Vulkan CTS cases for "no_position", what are you supposed to do when e.g. a VS doesn't write position but the next (non-fragment) stage reads it?
dcz_ has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
kimbro has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<jenatali>
Looks like the test isn't expecting valid positions to end up in the fragment input so I guess it can be anything...
<DavidHeidelberg[m]>
robclark: there is issue for it I think created by Emma
<robclark>
ahh, indeed there is
rahul_janga has joined #dri-devel
tdjb has joined #dri-devel
ngcortes has joined #dri-devel
rahul_janga has quit [Read error: Connection reset by peer]
<tdjb>
Hi, I have this strange amdgpu crash which happens ins Warhammer 40000 Darktide if you disable the in-game FPS cap of 60 FPS (any other cap still leads to crashing), Windows users seem to have the same issue. How would I go about collecting useful information about the crash to create a meaningful report? Thanks.
MajorBiscuit has joined #dri-devel
frytaped has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
lemonzest has quit [Quit: WeeChat 3.6]
dcz_ has joined #dri-devel
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
mzamreal has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rasterman has quit [Remote host closed the connection]
fxkamd has quit []
iive has joined #dri-devel
alatiera6 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
dreda has joined #dri-devel
RhineDevil has quit [Quit: Leaving]
RhineDevil has joined #dri-devel
bgs has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
Akari has joined #dri-devel
paulk has joined #dri-devel
paulk-bis has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
frytaped has quit [Quit: WeeChat 3.6]
alyssa has joined #dri-devel
<alyssa>
naive question ... if a shader samples the alpha component of an RGB texture, out of bounds with CLAMP_TO_BORDER wrap mode and a border colour with alpha not equal to 1,
<alyssa>
does that return 1.0 or the border alpha?
<alyssa>
seemingly panfrost differs from Apple's GL driver
<alyssa>
and IDK who's right
<RSpliet>
Naive request for additional precision :-P is this an XRGB/SRGB/RGBX/... texture, or an ARGB texture?
<alyssa>
RGBX
<anholt>
alyssa: piglit's texwrap test should tell you
<alyssa>
anholt: fair enough, will look there, thanks :)
<alyssa>
(IDK which of the two I want it to be. They are both bad.)
<anholt>
pretty sure it's going to be border color alpha, though
zehortigoza has quit [Remote host closed the connection]
<alyssa>
same
<alyssa>
that
<alyssa>
's what panfrost goes to great lengths to ensure
<alyssa>
and which I suspect is broken in Apple's GL driver
<alyssa>
not like they submitted conformance for the thing
<jenatali>
alyssa: D3D's spec says: "For example, suppose the resource format is DXGI_FORMAT_R8_SNORM, and BorderColor is needed during a sample operation. In this case only the RED component of BorderColor is used, along with the appropriate format-specific defaults for the other components."
<alyssa>
jenatali: so D3D votes for 1.0 and GL votes for ???
<jenatali>
Yep
jfalempe has joined #dri-devel
<alyssa>
GL *seems* to vote for border colour alpha
<alyssa>
if I'm understanding texwrap code right
<jenatali>
Does anyone know by any chance if typical desktop GPUs have switches for changing sample coordinate rounding behavior between D3D and VK/GL? I'm seeing D3D specs coordinates have to go to fixed 16.8 and then truncated, where VK specs coordinates are floored, and I'm actually seeing a VK test that seems to hit a difference in that exact behavior
<alyssa>
Who votes for "this is impossible to implement on AGX and the Apple driver is broken"?
<RSpliet>
GLES 3.2 says, on the topic of texture minification: "if the texture contains color components, the values of TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match the texture’s internal format in a manner consistent with table 8.8."
<RSpliet>
And that's as vague as it's going to get
<alyssa>
truly
danvet has quit [Ping timeout: 480 seconds]
<alyssa>
wait does texwrap even check this
Duke`` has quit [Ping timeout: 480 seconds]
tdjb has quit [Quit: Leaving]
<alyssa>
i do not see how texwrap possibly works
<alyssa>
right. init_float_texture applies the default swizzle implicitly
<alyssa>
so... texwrap votes for "border color alpha"
<alyssa>
which is weirdly inconsistent with D3D
<jenatali>
Agreed
<alyssa>
jenatali: well of course you agree :p
<jenatali>
I've been finding a bunch of those tiny little details that are weirdly inconsistent recently though
<alyssa>
similar questions arise around luminance and alpha of course
<zmike>
boo hiss
<alyssa>
e.g. if there are different values for each RGBA in the border colour
<alyssa>
but it's a greyscale (GL_LUMINANCE) format
<alyssa>
do we get colourful borders or not?
<alyssa>
d3d votes no, texwrap piglit seems to maybe vote yes
mzamreal has quit [Ping timeout: 480 seconds]
<DemiMarie>
alyssa: do you mean that Apple hardware is broken and cannot have OpenGL, Vulkan, or DirectX 12 implemented on it?
<alyssa>
DemiMarie: I mean, we already knew that much :-p
<jenatali>
alyssa: Well D3D doesn't have luminance or alpha formats anymore
<jenatali>
Ah that's not entirely true, A8 still exists
<alyssa>
"the border values defined by TEXTURE_BORDER_COLOR are used in place of the non-existent texel. If the texture contains color components, the values of TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match the tex- ture’s internal format in a manner consistent with table 8.18. The internal data type of the border values must be consistent with the type returned by the texture as described in
<alyssa>
chapter 8, or the result is undefined. If border values are out-of-range with respect to the texture’s internal format, the result is undefined. If the texture contains depth components, the first component of TEXTURE_BORDER_COLOR is interpreted as a depth value."
<alyssa>
that.. that really is not enlightening
pallavim has quit [Ping timeout: 480 seconds]
<alyssa>
wtf does it mean to interpret consistent with table 8.18
<alyssa>
JoshuaAshton: ^^^ how does this work in VK
<alyssa>
"Table 24. Border Texel Components After Replacement
<alyssa>
" makes it pretty clear that Vulkan has D3D behaviour
<alyssa>
I think
<alyssa>
"This is substituted for the texel value by replacing the number of components in the image format"
<alyssa>
does this mean Zink fails texwrap?
<alyssa>
and/or that the VK CTS isn't testing this?
pallavim has joined #dri-devel
<alyssa>
zmike: you passing texwrap?
<alyssa>
seemingly nobody passes texwrap, but
<DemiMarie>
alyssa: what do you mean by “we already knew that much :-p”? The only limitation I knew of is the lack of double-precision floating point. Is it possible to implement robust buffer and texture access at least?
RhineDevil has quit [Remote host closed the connection]
RhineDevil has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jenatali>
alyssa: We pass most texwrap tests, we do fail for integer textures in some cases though
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Major_Biscuit has joined #dri-devel
RhineDevil has quit [Remote host closed the connection]
<alyssa>
if texwrap is asking for something completely different than vulkan
<alyssa>
and you can't layer it
<alyssa>
idk how you managed that
digetx has quit []
digetx has joined #dri-devel
<alyssa>
then again if the VK CTS is missing tests for this edge case it's possible that vk drivers are implementing the gl thing and zink works by accident
<alyssa>
i mean
<alyssa>
if texwrap is authoritative for GL and my reading of the VK spec is right, then unless lavapipe is fixing up custom border colours, there is no way this works in both lvp and llvmpipe
<alyssa>
since gallium doesn't have a sampler state bit for this
<zmike>
gallium has a ton of stuff for border colors now
<alyssa>
lavapipe is indeed not fixing anything up
<alyssa>
idk if I have the will to read LLVM code to see what gallivm is doing
<zmike>
what are you even looking at
<alyssa>
lp_build_sample_texel_soa
<alyssa>
seemingly that implements the VK behaviour
<zmike>
I meant what behavior are you supposing can't be replicated
<alyssa>
zmike: R8_UNORM image, (0.5, 0.5, 0.5, 0.5) border colour, sample "green" in the shader, do you get 0 or 0.5
kimbro has quit [Ping timeout: 480 seconds]
<alyssa>
or more problematically, sample "alpha", do you get 1 or 0.5
<zmike>
if it's just normal border color stuff I'm not sure why you're expecting that wouldn't work on zink
<alyssa>
this is seemingly different in VK and GL
<alyssa>
VK gives 0/1 for those
<alyssa>
GL we think maybes gives 0.5/0.5 for them
<zmike>
there's border color extensions and gallium swizzling