CODEWITHSUNDEEP
openglopengl-4
Newline
Newline

Reputation: 973

OpenGL warning after calling glCopyNamedBufferSubData and glNamedBufferSubData

I'm getting the following warning:

Buffer performance warning: Buffer object 19 (bound to NONE, usage hint is GL_DYNAMIC_DRAW) is being copied/moved from VIDEO memory to HOST memory.

I allocate this buffer with glNamedBufferStorage. I copy data into it from another buffer (allocated the same way) with glCopyNamedBufferSubData then update some of its data with glNamedBufferSubData. this gives me an warning. I don't use mapping. Just these functions. (Using OpenGL4.5. Card is NVidia.)

So far I couldn't reproduce this warning with some minimal code but it comes consistently. After searching I found people who got this message used some kind of buffer mapping. What can cause this warning in my case? How can I found more about what is causing it?

EDIT:

Minimal reproducible example:

GLuint test_buffer_1_ID;
GLuint test_buffer_2_ID;

glCreateBuffers(1, &test_buffer_1_ID);
glCreateBuffers(1, &test_buffer_2_ID);

UByte data_source[100];

const GLbitfield flags = GL_DYNAMIC_STORAGE_BIT;

glNamedBufferStorage(test_buffer_1_ID, 100, data_source, flags);
glNamedBufferStorage(test_buffer_2_ID, 100, data_source, flags);

glCopyNamedBufferSubData(
    test_buffer_1_ID,
    test_buffer_2_ID,
    0,
    0,
    10
);

glNamedBufferSubData(
    test_buffer_2_ID,
    0,
    10,
    data_source
);

Warning comes when glNamedBufferSubData is called. If I specify source data glNamedBufferStorage or give it nullptr makes no difference. If I call SubData first and Copy after, or just SubData, then there is no warning.

Upvotes: 1

Views: 685

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 474436

Because people have misused and mischaracterized buffer objects so frequently in the past, implementers have basically been forced to move buffer storage around based on how it is used, not how you say it will be used.

You said that your buffer would be filled by the CPU (otherwise you couldn't use BufferSubData on it). But if you drop stuff in it from the CPU enough times, the driver will think that you're serious about doing that. So it will move the storage to directly CPU-accessible memory, where such copies will be cheaper. Potentially at the cost of read performance.

If you're updating the storage of the buffer so frequently that you're triggering this condition, it might be better to just map it persistently and write to that when you need to. Of course, you'll now have to manage synchronization, but you should have been doing that anyway if performance mattered to you.

Upvotes: 4

Related Questions