<tomeu>
yeah, my fault, this seems to be solved now
BobBeck has quit [Quit: Ping timeout (120 seconds)]
italove has quit [Quit: Ping timeout (120 seconds)]
BobBeck has joined #etnaviv
<tomeu>
austriancoder: btw, VIVS_CL_WORKGROUP_SIZE_X/Y/Z seem to be restricted to the low 10 bits of that int
<tomeu>
don't know how that would be expressed n the rnndb file
italove has joined #etnaviv
frieder has joined #etnaviv
wv has joined #etnaviv
Leopold has joined #etnaviv
mvlad has joined #etnaviv
cphealy has quit [Read error: Connection reset by peer]
cphealy has joined #etnaviv
<wv>
Hello, I have this imx6 which drives a fullhd screen. Though only one third of the tft is physically visible (rest is covered). Is there a way to have this as performant as possible? So configuring it in a way that only the visible part is rendered/accelerated?
lynxeye has joined #etnaviv
pcercuei has joined #etnaviv
wv has quit [Ping timeout: 480 seconds]
<marex>
is that like 1920x360 ?
<marex>
i.e. the noodle ?
<marex>
hm ... gone
frieder has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
<austriancoder>
tomeu: I am not convinced that WORKGROUP_SIZE_X/Y/Z are only 10 bit big - if all 10 bit are set we get 1023 which is the value reported by clinfo for max work item sizes (1024x1024x1024). So there might be some vivante gpus supporting bigger work item sizes .. which would end in 11 or more bits used. It would be possible to represent this limit in the rnndb file but.. yeah.. I do not think it is needed as the upper layers
<austriancoder>
in opencl stack keep care of the max size limits and we never ever should end in the situation to write too big values to these registers that might not be supported by the gpu.
<austriancoder>
tomeu: this how it would be done in rnndb (theoretically)
<austriancoder>
which would give you e.g. VIVS_CL_WORKGROUP_SIZE_X_VALUE(..)
mvlad has quit [Remote host closed the connection]
<cphealy>
marex: I seem to recall that being the case. I think the idea was can 1920x360 be exposed as the display resolution so the GPU only works with that resolution render buffers / framebuffer, but the IPU in the i.MX6 has to handle an LCD which requires display timing based on 1920x1080 as that's what the display originally is.
<cphealy>
If the IPU only has to scan out 1920x360 pixels at VSYNC rate, there would be less load on the DRAM interface.
<cphealy>
What wasn't clear was how to achieve this. Could playing with the front/back porch and resolution configuration be sufficient to achieve this goal between the IPU and LCD?