[krita] [Bug 445561] Krita 5 16bit integer colorspace canvas rendering is broken on M1

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=445561

--- Comment #15 from Dmitry Kazakov <dimula73 at gmail.com> ---
Hi, Ivan!

> 3) This is interesting, testing to 1 buffer does not make it behave as it was before, in fact, the texture tiling is broken and still shows the image broken

That sounds interesting... It sounds as if M1's openGl cannot track the
dependencies between the buffers usage. That is, it allows writing into a
buffer that has not finished painting yet.

Could you do the following test:

1) Set the number of buffers to a fixed value of 1024. To achieve this, comment
out the call to `m_bufferStorage.allocateMoreBuffers(nextSize)` in
'KisOpenGLImageTextures::recalculateCache()' **and** change the initial number
in `KisOpenGLImageTextures::initBufferStorage()` to 1024.

2) Create **a small** image of 200x200 at 16i in size (one tile). And try to paint
on it for a couple of seconds. It should work for some time and then start
failing. Or not start failing at all.

3) Restart Krita. Create an image of 400x400 at 16i in size (four tiles). And try
to paint for a couple of seconds.

The results of these tests can be interpreted as follows:

1) If the you can paint on a single-tile image forever, or if you see artifacts
from time to time, but they heal themselves with the next update, then the
problem is in race conditions in the openGL pipeline. We write into a buffer
that is currently accessed by the GPU. Though looking into your previous
screenshots I don't think it is the case.

2) If you can paint for some time, then the artifacts start to appear and
become worse and worse with time, then the problem is in the fact that the
buffer cannot be reused for the second time. That is, openGL implementation
discards this buffer right after the first usage. It could be caused by either
a bug in openGL implementation or by the way how Qt uses it.

3) If you cannot paint on these images at all, it means that the problem is in
the buffer format itself. Though it shouldn't happen, because the old
implementation of the buffers worked fine.

I will make one more test a bit later, but I'll add it as a separate comment.

-- 
You are receiving this mail because:
You are watching all bug changes.