[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 1460 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=100024

--- Comment #12 from Julien Isorce <julien.isorce@gmail.com> ---
Hi Michel. Thx you for your comment. In a way it is a good and only my attached
mesa will be needed to fix the test. I will send it to the mailing list.

But I still do not properly understand why there is not enough graphic memory
because lspci reports 2048M. And there are some contradictions depending on the
subSize for the test sequence which is:

for i in 0 1:
  glGenTextures
  glTexImage2D    maxSize
  glTexSubImage2D subSize = maxSize / 2.
  glDeleteTextures

A: The kernel trace ENOMEM appears with:
  subSize = maxSize - 1 -> "radeon: Failed to allocate a buffer"
  subSize = 3 * maxSize / 4 -> "radeon: Failed to allocate a buffer"
  subSize = maxSize / 2 -> "radeon: Not enough memory for command submission"

B: It works with:
  subSize = maxSize
  subSize = maxSize / 4

Isn't A and B a contradiction ? For me A should succeeds because
glDeteteTextures should . Also note that on other 

Also by calling glFush() within an additional loop iteration i = 2, it can
recover so it will fail for iteration i = 1 but succeeds for i = 2. 
So what could the explanation here ? Should the driver just flush the cs
automatically in that case like it does for subSize = maxSize ? Sorry I am just
trying to understand :). Thx!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2394 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel