Advertisement

does not name an attachment when glInvalidateNamedFramebuffer

Started by June 04, 2019 10:46 PM
4 comments, last by Green_Baron 5 years, 8 months ago

Hi.

So, i am doing my first framebuffer


glCreateFramebuffers( 1, &m_framebuffer );
bind( GL_DRAW_FRAMEBUFFER );
if( GL_TRUE != glIsFramebuffer( m_framebuffer ) ) {
	....

with a color


glCreateRenderbuffers( 1, &m_colorAttachment );
if( GL_TRUE != glIsRenderbuffer( m_colorAttachment ) )
	std::cerr << "Error creating color renderbuffer.\n";
glNamedRenderbufferStorage( m_colorAttachment, colorFormat, m_sizeX, m_sizeY );
glNamedFramebufferRenderbuffer( m_framebuffer, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, m_colorAttachment );

and depth


glCreateRenderbuffers( 1, &m_depthAttachment );
if( GL_TRUE != glIsRenderbuffer( m_depthAttachment ) )
	std::cerr << "Error creating depth renderbuffer.\n";
glNamedRenderbufferStorage( m_depthAttachment, depthFormat, m_sizeX, m_sizeY );
glNamedFramebufferRenderbuffer( m_framebuffer, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, m_depthAttachment );

attachment. Execute the "how we are we today"


if( GL_FRAMEBUFFER_COMPLETE != glCheckNamedFramebufferStatus( m_framebuffer, GL_FRAMEBUFFER ) )
...

and in the renderloop i bind the framebuffer, render into, bind it to read, the window buffer to draw, and copy the rendered image over.

This works (example taken from the Red Book):


// Render in the framebuffer first
m_framebuffer->bind( GL_DRAW_FRAMEBUFFER );
glClearColor( 1.0f, 0.0f, 0.0f, 1.0f );
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
//m_framebuffer->invalidateData();

// ... renderrenderrender...

m_framebuffer->bind( GL_READ_FRAMEBUFFER );
glBindFramebuffer( GL_DRAW_FRAMEBUFFER, 0 ); // or m_framebuffer->unbind()
glClearColor( 0.0f, 0.0f, 1.0f, 1.0f );
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glBlitFramebuffer( 0, 0, m_window->getWidth(), m_window->getHeight(),
                 0, 0, m_window->getWidth(), m_window->getHeight(),
                 GL_COLOR_BUFFER_BIT, GL_NEAREST );

// poll() and swap() and start all ove again ...

But if i stray from the tutorial path and use glInvalidate..() instead of glClear() i get an "invalid enum, <attachment> does not specify an attachment".

The method is trivial:


if( GL_TRUE == glIsRenderbuffer( m_colorAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_colorAttachment );
if( GL_TRUE == glIsRenderbuffer( m_depthAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_depthAttachment );

glInvaliate... cause the error.

Debug message (1280): Source: API; Type: Error; Severity: high; GL_INVALID_ENUM error generated. <attachment> does not specify a valid attachment.
 

What have i done wrong ? It is just, i read, invalidate may be faster than actually clearing the buffers to a colour.

 

35 minutes ago, Green_Baron said:

if i stray from the tutorial path and use glInvalidate..() instead of glClear() i

Invalidate and Clear are two different things.

36 minutes ago, Green_Baron said:

The method is trivial:



if( GL_TRUE == glIsRenderbuffer( m_colorAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_colorAttachment );
if( GL_TRUE == glIsRenderbuffer( m_depthAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &m_depthAttachment );

glInvaliate... cause the error.

Which call brings the error ? The first one, the second one, or both ?

Also, from this API doc, it seems you should not give the attachment name (id), but its enum matching (color, depth...), which should be the cause of your error.

Advertisement

Hi,

yep, the invalidation apparently doesn't bother with overwriting, it just sees the contents as not worthy to preserve. Useful when one is about to overwrite the buffer anyway (beginning of the frame, or so).

There are two commands: glInvalidateFramebuffer (the one you linked that works on the currently bound fb) and glInvalidateNamedFramebufferDate (the ones i use that work on a buffer- and attachment name). Syntactically that should be (?) ok.

What confuses me, it renders to the buffer. Just teh two (both) invaliation calls cause the error.

clearbuffer actually does cost considerable time and framerate ...

41 minutes ago, Green_Baron said:

There are two commands: glInvalidateFramebuffer (the one you linked that works on the currently bound fb) and glInvalidateNamedFramebufferDate (the ones i use that work on a buffer- and attachment name). Syntactically that should be (?) ok.

They both expect the same enum for the attachment.

44 minutes ago, Green_Baron said:

What confuses me, it renders to the buffer. Just teh two (both) invaliation calls cause the error.

As said in my previous post, you don't give the expected value to the attachment parameter, and this is the cause of your errors.

Oops, yes, you are right.

Here's how it works for everyone else:


GLenum attachments[2]{ GL_COLOR_ATTACHMENT0, GL_DEPTH_ATTACHMENT };
if( GL_TRUE == glIsRenderbuffer( m_colorAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &attachments[0]);
if( GL_TRUE == glIsRenderbuffer( m_depthAttachment ) )
	glInvalidateNamedFramebufferData( m_framebuffer, 1, &attachments[1] );

 

This topic is closed to new replies.

Advertisement