Texture Viewer zooming and panning is dead slow

[kvark]

Using qrenderdoc from f46aa29 on Linux/Intel. Viewing a texture and trying to zoom in has multi-second lag, almost completely unusable. Can we have some GPU acceleration for this? :)

[baldurk]

All of the texture viewing already happens on the GPU. It wouldn't make sense to readback the textures from the GPU to try and CPU blit them around.

I'll need more information to try and diagnose this. What linux distribution and what GPU do you have? what version of mesa you are running? Upload the log output from running qrenderdoc in case any errors or warnings are printed. Can you test on another GPU vendor to see if it still happens there? Is it also slow on v0.x?

[kvark]

uname -a:

Linux carbon 4.14.13-300.fc27.x86_64 #1 SMP Thu Jan 11 04:00:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
glxinfo:

    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)  (0x1916)
    Version: 17.2.4
    Accelerated: yes

Console log items repeated on zooming:

Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_VALUE in glCopyBufferSubData(writeOffset 0 + size 262144 > dst_buffer_size 229376)'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 16, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Warning - Attempting to read off the end of the buffer (4 300). Will be clamped (300)
Warning - Attempting to read off the end of the buffer (12 300). Will be clamped (300)
Warning - Attempting to read off the end of the buffer (0 48). Will be clamped (32)

And also lots of these:

Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_PORTABILITY, ID 355, severity GL_DEBUG_SEVERITY_MEDIUM:
'glValidateProgramPipeline: pipeline 1 does not meet strict OpenGL ES 3.1 requirements and may not be portable across desktop hardware'

Stable 0.91 captures but then fails to replay, printing:

Error   - Couldn't choose default framebuffer config
Error   - Couldn't make separable program for shader via patching - functionality will be broken.
Error   - Shader error:  
Error   - Shader error:  
...
... (repeated quite a few times)
...
Warning - FBOs are shared on this implementation
Log     - Created replay driver.
Log     - Timer chunk initialisation - 10902.989 ms
Log     - QRenderDoc - renderer created for "/tmp/RenderDoc/firefox_2018.01.22_16.36.26_frame76.rdc"
Warning - Attempting to read off the end of the buffer (16 32). Will be clamped (32)
Error   - Couldn't choose default framebuffer config
Error   - Couldn't choose default framebuffer config
Error   - Assertion failed: 'm_PixelContext.outputID > 0' 
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No space left on device
Error   - Couldn't choose default framebuffer config
Segmentation fault (core dumped)

Note: independent to this issue but perhaps related to the last log is the fact that latest RenderDoc 1.x hangs on trying to capture FF + WR build now. I'll submit a separate issue for this.

[baldurk]

It might be worth trying the latest v0.x branch in case those bugs are fixed over v0.91, but it might be that the bugfix didn't make it onto v0.x - I'm not sure exactly what this would be.

The debug messages might be false positives. I know the glGetProgramStageiv one is a mesa bug, I don't know about glCopyBufferSubData. The glValidateProgramPipeline is clearly ignoreable since we're not using GLES.

However I only call glGetProgramStageiv when fetching GL render state, which suggests somehow a heavyweight codepath is happening while zooming/panning. Likewise the buffer clamping messages are from GetBufferData which should not be called on the texture render path.

Can you breakpoint in WrappedOpenGL::DebugSnoop where those messages are printed, then zoom/pan and see what the callstack is at that point?

Also can you upload your capture that I can repro with directly?

[kvark]

@baldurk I reproduced it a few more times from inside gdb, and every time I break during the wait I see all the threads waiting on poll:

  Id   Target Id         Frame 
* 1    Thread 0x7ffff7fb38c0 (LWP 30662) "qrenderdoc" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  2    Thread 0x7fffe109c700 (LWP 30684) "QXcbEventReader" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  3    Thread 0x7fffd6ee6700 (LWP 30704) "dconf worker" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  4    Thread 0x7fffd66e5700 (LWP 30705) "gmain" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  5    Thread 0x7fffd5ee4700 (LWP 30706) "gdbus" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  6    Thread 0x7fffc77a3700 (LWP 30708) "QDBusConnection" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  7    Thread 0x7fffbf301700 (LWP 30714) "QThread" 0x00007ffff42b5f50 in nanosleep () from /lib64/libpthread.so.0
  8    Thread 0x7fffbeb00700 (LWP 30715) "Qt bearer threa" 0x00007ffff36d93db in poll () from /lib64/libc.so.6
  17   Thread 0x7fffbd45e700 (LWP 30926) "QThread" 0x00007ffff42b1cbb in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

There is also an XLib error on the output:

Xlib: sequence lost (0x6aeda > 0x5aedb) in reply type 0x23!

I find it suspicious. Maybe it's not busy, but rather the UI doesn't synchronize properly?