<alyssa>
anarsoul: the description doesn't seem to match the cap?
<alyssa>
the only functional change I see is to dont_pack_vec3, nothing about vec2
<anarsoul>
alyssa: vec4, vec2, scalar are already guaranteed to be power-of-two aligned
Company has quit [Read error: No route to host]
<anarsoul>
vec3 is packed last, so it's the only varying type that can be unaligned and double-parked (i.e. split between two inputs)
<anarsoul>
alyssa: link_varyings sorts varyings in type order, vec4, vec2, vec1, then vec3
<alyssa>
anarsoul: then the CAP/GLSL prop/etc name is wrong
Company has joined #dri-devel
<anarsoul>
so we only have to deal with vec3
<anarsoul>
alyssa: nope
<alyssa>
(well, "wrong", heavy handed.)
<alyssa>
and ... misleading
<anarsoul>
it's not misleading, it says that driver wants varyings to be power-of-two aligned
<anarsoul>
I don't want to name it "prefer vec3 to be aligned" just because current packing algorigthm guarantees vec4/vec2/vec1 to be aligned because it's not a hard requirement
<alyssa>
what if panfrost wants vec3 aligned but doesn't care if vec2 is aligned -- should it set the cap?
linearcannon has quit [Read error: Connection reset by peer]
linearcannon_ has joined #dri-devel
<anarsoul>
alyssa: is it a hypotetical scenario? :)
<alyssa>
No
<alyssa>
I'd have to check shader-db but it may help on Bifrost
<anarsoul>
does it care if vec2 is double-parked?
<alyssa>
yes and no
<alyssa>
if interpolation modes etc are the same, it shouldn't matter because dead varying elimination will clean up the mess (and this cap can't work on separable shaders)
<alyssa>
if not, we end up loading extra components and throwing them away
<anarsoul>
alyssa: I'd say set the cap and try if it helps you. Keep in mind that it may increase number of varyings in some cases (e.g. if you have a single vec3 and vec1 you'll end up in 2 varyings)
<alyssa>
That doesn't matter for Mali
<alyssa>
But ... doing a load_vec3(); load_scalar(); is more expensive than a single vectorized load_vec4();
<anarsoul>
alyssa: but if it's double-parked you'll end up in 2 loads
<alyssa>
(Same # of bytes read/written, but 2x as many messages)
<alyssa>
for that matter, Utgard has the same trade off.
<alyssa>
Are you sure it helps Lima?
<alyssa>
(As in, FPS increasing on actual workload/benchmark, not just shader-db #s)
<anarsoul>
alyssa: yes, it helps lima (see shader-db diff), also it helps with utilizing high-precision path for samplers
<anarsoul>
we have to feed load_input directly into load_texture in order for coords to have precision higher than fp16
<anarsoul>
and load_input doesn't have a swizzle
<anarsoul>
so if vec3 in .yzw components of the input or split between two inputs we have to load it into register, swizzle it and then pass into load_texture. As a result it downgrades precision to fp16
<anarsoul>
and you can't sample textures larger than 1024x1024 with fp16
<anarsoul>
(fp16 == 10 bits for mantissa)
mripard has quit [Ping timeout: 480 seconds]
<anarsoul>
so yeah, we want it for lima for sure
<alyssa>
ah, right, so more bug fix than optimization imo
bbrezillon has quit [Ping timeout: 480 seconds]
<anarsoul>
alyssa: it also has shader-db improvement since we get rid of movs
<alyssa>
shader-db is not a benchmark
<anarsoul>
alyssa: no impact on glmark2 :)
<alyssa>
glmark2 is not a ^good benchmark
<alyssa>
;_0
<alyssa>
* ;-)
<anarsoul>
give me a good benchmark for gles2 that runs on linux :P
<alyssa>
i'll tell you when I find one with arm64 builds ;-)
<Plagman>
es2gears of course
<anarsoul>
alyssa: fwiw it fixes blurrines in xfce compositor (that uses legacy GL, so no control over shaders!) on lima
* Plagman
sprints away
<kisak>
I've been using Google Earth VR as my most common test for gles
rasterman has quit [Quit: Gettin' stinky!]
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
<HdkR>
I'm sure there are plenty of Android games that support ES2. Just need to use one of those Android container projects right? :)
<javierm>
tzimmermann: I remember we talked about whether /proc/fb was an ABI or not, and decided that wasn't but it seems there's user-space relying on the name...
dllud has quit [Remote host closed the connection]
dllud has joined #dri-devel
vivijim has joined #dri-devel
adjtm has joined #dri-devel
dviola has quit [Quit: WeeChat 3.3]
tango_ is now known as Guest2084
tango_ has joined #dri-devel
Guest2084 has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
melissawen_ has joined #dri-devel
Company has joined #dri-devel
elongbug has quit []
elongbug has joined #dri-devel
<tzimmermann>
javierm, i wish we could have the guy fix his system. but, well....
<jekstrand>
bbrezillon: I reviewed all the driver changes. I think you can count mine.
<zmike>
approved^
<jekstrand>
:P
nchery has joined #dri-devel
<jekstrand>
danylo: RE: 12785, Do we crash with that MR on the current CTS?
<jekstrand>
(I'ts the depth/stencil helper function one)
rasterman has quit [Quit: Gettin' stinky!]
Ahuj has quit [Ping timeout: 480 seconds]
<danylo>
jekstrand: The fix is not merged in CTS, so we should be crashing. But I didn't personally check it.
<danylo>
tests are crashing in RADV in that MR, and nothing changed in CTS since then
<bbrezillon>
jekstrand: ack, assigning it to marge right now
sravn_ has quit [Ping timeout: 480 seconds]
sravn_ has joined #dri-devel
<jekstrand>
danylo: Ok, I'll pull it and run through the Intel CI
Danct12 has joined #dri-devel
ybogdano has joined #dri-devel
pendingchaos has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
zrusin has joined #dri-devel
zackr has quit [Read error: Connection reset by peer]
mal has quit [Remote host closed the connection]
mal has joined #dri-devel
pushqrdx has quit [Remote host closed the connection]
adjtm is now known as Guest2105
adjtm has joined #dri-devel
libv has joined #dri-devel
Adrinael has quit [Ping timeout: 480 seconds]
libv_ has quit [Ping timeout: 480 seconds]
lplc has quit [Ping timeout: 480 seconds]
Namarrgon has quit [Ping timeout: 480 seconds]
Guest2105 has quit [Ping timeout: 480 seconds]
Adrinael has joined #dri-devel
mmind00_ has joined #dri-devel
pushqrdx has joined #dri-devel
dv_ has quit [Ping timeout: 480 seconds]
mmind00 has quit [Ping timeout: 480 seconds]
mmind00_ has quit [Remote host closed the connection]
mmind00 has joined #dri-devel
flto has quit [Remote host closed the connection]
dv_ has joined #dri-devel
<Venemo>
is something up with gitlab?
ybogdano has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Remote host closed the connection]
flto has joined #dri-devel
<kisak>
Venemo: seems fine here
<daniels>
Venemo: are you experiencing a specific problem with it?
<Venemo>
yes, it times out
<anholt>
wfm
<Venemo>
firefox gives me a "The connection has timed out", and git gives me: "ssh: connect to host gitlab.freedesktop.org port 22: Connection timed out"
<kisak>
maybe a regional issue? poke with traceroute?
<Venemo>
ehh, seems to be an issue with my local network
<Venemo>
it works from mobile data
<mceier>
it does timeout here too
flto has quit [Remote host closed the connection]
lplc has joined #dri-devel
<anarsoul>
same here
<mceier>
the traceroute ends at if-ae-22-2.tcore1.nto-newyork.as6453.net (63.243.128.17)
flto has joined #dri-devel
<Venemo>
same here, though there are some entries after that
<anarsoul>
looks like routing issue, works via VPN through US west coast, doesn't work from Canada
Ahuj has joined #dri-devel
<Venemo>
and apparently neither from the EU
<anarsoul>
last working hop for me is 64.125.29.223
<anarsoul>
interesting -- it goes the same way via VPN, but proceeds further
<Venemo>
in my case it seems to be taking an entirely different route from my local network vs. the mobile data
<Venemo>
anarsoul: you are gonna laugh at this, but now that I visited the mesa gitlab from the mobile data connection, it started working even from the local network
flto has joined #dri-devel
<anarsoul>
Venemo: it resolves to the same address for me
<anarsoul>
so it doesn't look like DNS issue
anujp has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
frieder has quit [Remote host closed the connection]
slattann has quit []
tzimmermann has quit [Quit: Leaving]
gawin has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
mal has quit [Remote host closed the connection]
mal has joined #dri-devel
<gawin>
hello, is there a way how I can easily get tgsi code which is passing tests of piglit?
<anholt>
ST_DEBUG=tgsi will show what st is passing to the driver
<anholt>
but you'll probably want to see your driver-specific debug output, which probably also prints tgsi
<gawin>
I'm able to dump output of shaders (tgsi code), but even with failing test tgsi code looks acceptable in most cases. as an issue can be on driver side or hardware side, is comparing with alternative tgsi (from different driver) good way to check on which side the issue is?
<anholt>
gawin: you probably want to just dump your driver's assembly output, bugs are likely in the driver's compiler backend, and just comparing the tgsi inputs between drivers probably won't show you anything useful.
<zmike>
anyone know any good tools for profiling heap usage over time? massif seems too slow and I tried heaptrack but it doesn't seem to actually do anything
<anholt>
massif's the only one I've used and it's... not exactly a delight.
<gawin>
why it cannot be CMP tmp, -r0 , -r0, -r0 ?
<gawin>
or MIN tmp -r0 -r0 ?
<ajax>
grrr
<ajax>
there's no way in the wsi code to ask if a given surface has a swapchain created for it
<ajax>
which means GetPhysicalDeviceSurfaceCapabilities can call xcb_get_geometry, but there's no call into the swapchain code to run the present event queue
<ajax>
i am starting to regret some decisions
jkqxz has quit [Read error: No route to host]
<alyssa>
gawin: Hardware bug. It says it right in the comment.
jkqxz has joined #dri-devel
<gawin>
alyssa: I was thinking: in which part hardware bug happens? KIL getting -0.0 from tmp or comparison in CMP?
<alyssa>
I don't know what KIL is, but the hardware says the comparison is the bug.
jasuarez has joined #dri-devel
<gawin>
using inaccurate MAD for moving stuff around is probably bad. maybe even using some heuristic to catch if it's used for KIL is worth it
<mareko>
gawin: yeah the comment explains it, KIL means discard
egalli has joined #dri-devel
<jekstrand>
ajax: context?
<gawin>
mareko: worth to try to implement some workaround?
<jekstrand>
hikiko: Have you been testing crocus on BSD? I seem to recall you are but wanted to confirm.
Duke`` has quit [Ping timeout: 480 seconds]
Anson[m] has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
<mareko>
gawin: that doesn't use KIL
<gawin>
I mean maybe accuracy is lost by mad
<ajax>
jekstrand: window resizing with zink is hilariously bad and i'm trying to decide whether to blame zink or wsi more
<jekstrand>
:-/
<ajax>
GPDSC would be a natural place to run the special event queue for the swapchain, but there's no hook from the surface to the swapchain
<ajax>
trying to decide whether to fix that or to fix the whole approach
<jekstrand>
ugh
<jekstrand>
Yeah
<jekstrand>
The problem is that, at least at one point in the past, we weren't the ones to create the VkSurfaceKHR
<jekstrand>
That may have changed
ngcortes has quit [Ping timeout: 480 seconds]
<ajax>
i'm about 50% into whole approach anyway given what another MR does, so
<jekstrand>
At one point, I had a great system where the VkSurfaceKHR would have a bunch of stuff on it like the display pointer, a vtable, etc. It was great.
<jekstrand>
Then someone decided the loader should create those objects....
<jekstrand>
I was (and still am) very sad about it
<gawin>
mareko: in R5xx_Acceleration_v1.5.pdf there's part "For most ALU operations this is acceptable, however a MOV instruction needs to preserve the source exactly. For this, you can disable the output modifier for the MIN, MAX, CMP and CND instructions (...) US_OMOD_DISABLED is not valid with any other ALU operation. "
<gawin>
page 110
join_subline has quit [Remote host closed the connection]
join_subline has joined #dri-devel
<daniels>
ajax: ‘starting’ … ?
mbrost has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
jonmason has quit [Ping timeout: 480 seconds]
austriancoder has quit [Ping timeout: 480 seconds]
daniels has quit [Ping timeout: 480 seconds]
ezequielg has quit [Ping timeout: 480 seconds]
buhman has quit [Ping timeout: 480 seconds]
CosmicPenguin has quit [Ping timeout: 480 seconds]
cengiz_io has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
lileo has quit [Ping timeout: 480 seconds]
krh has quit [Ping timeout: 480 seconds]
dschuermann has quit [Ping timeout: 480 seconds]
narmstrong has quit [Ping timeout: 480 seconds]
cwabbott has quit [Ping timeout: 480 seconds]
pushqrdx has quit [Remote host closed the connection]
arnd has quit [Ping timeout: 480 seconds]
ogabbay has quit [Ping timeout: 480 seconds]
rburton has quit [Ping timeout: 480 seconds]
markyacoub_ has quit [Ping timeout: 480 seconds]
tfiga has quit [Ping timeout: 480 seconds]
zmike has quit [Ping timeout: 480 seconds]
jessica_24 has quit [Ping timeout: 480 seconds]
robclark has quit [Ping timeout: 480 seconds]
dianders has quit [Ping timeout: 480 seconds]
hwentlan has quit [Ping timeout: 480 seconds]
steev has quit [Ping timeout: 480 seconds]
rg3igalia has quit [Ping timeout: 480 seconds]
jstultz has quit [Ping timeout: 480 seconds]
rg3igalia has joined #dri-devel
abhinav__ has quit [Ping timeout: 480 seconds]
robher has quit [Ping timeout: 480 seconds]
tchar has quit [Ping timeout: 480 seconds]
jjardon has quit [Ping timeout: 480 seconds]
seanpaul has quit [Ping timeout: 480 seconds]
eric_engestrom has quit [Ping timeout: 480 seconds]
apinheiro[m] has joined #dri-devel
hfink has quit [Ping timeout: 480 seconds]
SanchayanMaity has quit [Ping timeout: 480 seconds]
rib_ has quit [Ping timeout: 480 seconds]
krh has joined #dri-devel
steev has joined #dri-devel
rburton has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
daniels has joined #dri-devel
ezequielg has joined #dri-devel
buhman has joined #dri-devel
CosmicPenguin has joined #dri-devel
seanpaul has joined #dri-devel
robclark has joined #dri-devel
narmstrong has joined #dri-devel
dschuermann has joined #dri-devel
pushqrdx has joined #dri-devel
arnd has joined #dri-devel
austriancoder has joined #dri-devel
jonmason has joined #dri-devel
mbrost has joined #dri-devel
tfiga has joined #dri-devel
tchar has joined #dri-devel
cengiz_io has joined #dri-devel
jstultz has joined #dri-devel
markyacoub_ has joined #dri-devel
dianders has joined #dri-devel
eric_engestrom has joined #dri-devel
lileo has joined #dri-devel
rib_ has joined #dri-devel
hfink has joined #dri-devel
ogabbay has joined #dri-devel
abhinav__ has joined #dri-devel
cwabbott has joined #dri-devel
jjardon has joined #dri-devel
jessica_24 has joined #dri-devel
hwentlan has joined #dri-devel
robher has joined #dri-devel
SanchayanMaity has joined #dri-devel
zmike has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
pushqrdx has quit [Remote host closed the connection]
lplc has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
<ajax>
we create a sync fence for every dri3 pixmap, in wsi/x11
<ajax>
and the only way we use it is we pass it to xcb_present_pixmap saying we definitely promise to wait for this fence before we touch that pixmap again.
<ajax>
oh. also we destroy it, when we destroy the swapchain. so that's two ways we use it.
<airlied>
shm_fence is the same fence
<airlied>
it's the local side of it, sync_fence is the remote side
<ajax>
that makes slightly more sense
<marex>
hey uh, who is responsible for merging piglit patches ? idr ?
<ajax>
but... in a way that still makes me want to rewrite everything
<anholt>
marex: nobody in particular. it's a very neglected project, too.
<anholt>
(if you can write a test for deqp, that's a better place)
<idr>
Basically what I was going to say.
<marex>
anholt: I just need someone to press "merge" on piglit mr 442
<idr>
I can do that.
<marex>
I got three RBs on it, but I dont know who to ask to merge it
<marex>
idr: ah, thank you
<idr>
I think that's one I reviewed...
<marex>
idr: yep, I wasn;t sure what to do next
<ajax>
beat you to it i think
<marex>
anholt: so is deqp the recommended test suite now ?
<ajax>
there is a nominal ci pipeline so it's /assign @marge-bot just like mesa
<marex>
seems to me like piglit is one step above that , i.e. it calls deqp tests internally too
<anholt>
marex: it's faster than piglit to run tests, actually maintained, and applies to all drivers.
<idr>
Unless it's a GLES 1.x test.
<idr>
Which is... well... on the fringes of things anyway.
<anholt>
or GL2
<marex>
anholt: but does it test all the stuff piglit does too ? I think it only does gles2/3/egl , but piglit seems to do more
<marex>
hmmm ... it is a gles1 test :)
<anholt>
marex: right, it doesn't have GL2 or GLES1 tests.
<marex>
it seems thats where all the odd bugs are left
<marex>
at least in etnaviv
<anholt>
I don't think I've ever even found a gles1 app to find a gles1 driver bug in :)
<idr>
But for basically everything else (except maybe tests that poke at very specific driver issues), having the test in deqp means that everyone will have to pass it.
<marex>
anholt: neverball
<marex>
that is perfect example, it breaks etnaviv and breaks and breaks ...
<anarsoul>
marex: just by using features that are not there in modern hw and have to be implemented in shaders? :)
<marex>
anarsoul: yep
pushqrdx has joined #dri-devel
chivay has joined #dri-devel
<alyssa>
Neverball is the "are point sprites broken?" app :-p
<alyssa>
don't remember if it's broken on panfrost+bifrost nowadays
Sumera has joined #dri-devel
<airlied>
alyssa: it's in a schrodinger state?
<alyssa>
yep.
<alyssa>
airlied: I think on bifrost we don't handle point sprites (PIPE_CAP_POINT_SPRITE = 0)
<alyssa>
but whether the mesa/st point sprite lowering actually works today is unclear