yshui has quit [Remote host closed the connection]
yshui has joined #dri-devel
<austriancoder>
Company: GLES3 is coming along slowly, but it's moving forward steadily.
<Company>
good to know
<Company>
when we dropped GLES2, pinephone and librem5 were the 2 devices that were left behind
<Company>
so nice to know the librem is catching up again
<Company>
do you know of people who keep testing things? Not that changes in GTK break it again...
<austriancoder>
I only look at cts results and nightly ci runs of them
<Company>
yeah, it would need to be someone who regularly compiles together a build with recent Mesa/GTK and runs it
<Mis012[m]>
Also everything with adreno a3xx and I heard claims that a4xx is not great either. a3xx has GLES3 support but it's kinda broken, currently firefox and Gtk are known to be unusable because of triggering bugs in the driver.
epoch101_ has quit []
<Company>
yeah, the pmOS people were testing that
epoch101 has joined #dri-devel
<Company>
but there was nobody who was really working on it anymore
<Mis012[m]>
yep
<Company>
that's why I didn't really worry about it
<Mis012[m]>
well, nobody is working on a3xx
<Mis012[m]>
people are still using SoCs that have a3xx
<Mis012[m]>
although Gtk not having working hw accell will probably be the end of that
<Company>
well, people can keep GTK on 4.16 on those devices
<Company>
but yeah, sooner rather than later that's not gonna be much fun anymore
<Mis012[m]>
pmOS decided to force cairo renderer, I guess it works for simple apps at least
<Company>
I think the a3xx is pretty crappy, so it's not that much of a change
<Mis012[m]>
well, my device has a 540p display so in my case maybe :P
<Company>
to really benefit from hw accel with GTK, you need big screens (read: lots of pixels to render to) or Vulkan-capable GPus
<Company>
same thing on the desktop, but there's very few people who still run GPUs worse than Sandybridge
<Company>
the thing with GTK is that we do damage tracking, so 95% of the time it's fast enough anyway
<Company>
and on mobile you don't resize - which is one of the performance-relevant things
<Company>
and that leaves scrolling as the only thing that's slow
<Mis012[m]>
well, GSKPath is certainly closer to skia than to cairo, but I don't recall if that was also the case with Gtk itself using cairo backend so maybe the issue with cairo isn't even the lack of acceleration
<Mis012[m]>
slow scrolling is definitely sad, don't recall how bad it was
glennk has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
<Company>
GskPath isn't even done yet and always uses Cairo
<Company>
the shaders had issues and weren't merged in time and then we got busy with other stuff...
<Mis012[m]>
guess it uses Cairo much more intelligently than I did then
<Mis012[m]>
or maybe the speedup is in matrix manipulation
illwieckz has quit [Quit: I'll be back!]
illwieckz has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
rellla has quit []
oneforall2 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rellla has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
valpackett has joined #dri-devel
apinheiro has quit [Quit: Leaving]
vliaskov has quit [Ping timeout: 480 seconds]
rellla has quit []
rellla has joined #dri-devel
epoch101 has quit []
feaneron has joined #dri-devel
valpackett has quit [Ping timeout: 480 seconds]
asrivats has quit [Remote host closed the connection]
asrivats has joined #dri-devel
asrivats has quit [Ping timeout: 480 seconds]
<lumag>
karolherbst: hei. Stupid question about RustiCL. I noticed that it has bumped some of the limits for the version checks (max_const_buffer0_size, local_mem_size). Is there any reason for that bump?
epoch101 has joined #dri-devel
<lumag>
I'm asking since some of the MSM GPUs have cs_shared_mem_size fixed of 16 K (which brings them to CL 1.0). Otherwise they look like CL 1.2 at least.
JesusGod-Pope666-Info has left #dri-devel [#dri-devel]
<karolherbst>
lumag: well, the spec requires 32k for CL local memory for anything above 1.0
<karolherbst>
however, embedded devices only need 1k
<lumag>
karolherbst: so it needs to be extended with the full/embedded switch
<lumag>
ack :-)
<karolherbst>
yeah
<lumag>
and for the 32k I got confused by the comment in the code.
<karolherbst>
the selection is a bit automatic, but maybe it's better to let drivers decide if they want to go for full or embedded, but...
<karolherbst>
not that it matters much
<karolherbst>
right
<lumag>
Ah, it was a part of 1.2
<lumag>
and 1.1. But anyway, I see, where to look. Thanks!