<tomeu>
my current problem is that anything above 0x4 will hang the GPU
<tomeu>
but that doesn't happen to galcore with the same cmdstream
<tomeu>
so I'm seeing if I need to initialize the HW differently in order to "activate" those shaders
<austriancoder>
tomeu: -ENOTIME .. but I have seen something like this on GC2000: groupsizeX * groupsizeY * groupsizeZ / (NumShaderCores * 4)
* austriancoder
is quite sorry for the delay
<tomeu>
yeah, unfortauntely that was already known :(
<tomeu>
but we even have some bits about images in _ProgramPPUCommand
<tomeu>
but just confirm things we already knew
<austriancoder>
I think I can spend more time to help out in 2-3 weeks
<austriancoder>
maybe you get it working by then :)
<tomeu>
don't worry, no rush
<tomeu>
I surely hope!
<tomeu>
or at least work around it
<tomeu>
I'm really close to run the whole pipeline in tensorflow lite, I think this is the last operation
<austriancoder>
nice
<tomeu>
yay! finally got to run inference correctly with etnaviv :)
<tomeu>
worked around that cores limitation by reducing the number of workgroups on the tflite side
pcercuei has joined #etnaviv
lynxeye has joined #etnaviv
tomeu has quit [Quit: Reconnecting]
tomeu has joined #etnaviv
<tomeu>
does anybody know what is this flop reset think in galcore?
<lynxeye>
tomeu: My _guess_ is that it's kind of a internal state reset, so you can't leak information from one context to another.
<tomeu>
hmm, that sounds pausible
<tomeu>
lynxeye: do you have any idea of what the galcore ko may be doing so that when userspace submits THREAD_ALLOCATION values higher than 0x4, the HW doesn't hang?
<tomeu>
for identical cmdstream, ioctl dumps and shaders, I get a hang with etnaviv but not with galcore
<lynxeye>
Nope, sorry. Haven't really looked at this part of the HW/blob.