Main Page | Report this Page
Computers Forum Index  »  Computer - Graphics - API (Opengl)  »  glDeleteTextures...
Page 1 of 1    

glDeleteTextures...

Author Message
AntonioM...
Posted: Wed Sep 23, 2009 10:48 am
Guest
Hi all,

for a personal project I'm introducing some modifications in the code
of XBMC (cfr. www.xbmc.org).
I'm an opengl newbie, so this will likely sound kind of silly to
someone's ears.

The context is a video decoding process for a DVD movie, with GL
overlays being comprised of menus and subtitles.

After some code modifications which definitely changed the standard
code behaviour, one of the application threads gets stuck at line 5 of
the following code snippet.

1 if( fields[f][p].id )
2 {
3 if ((result = glIsTexture(fields[f][p].id)))
4 {
5 glDeleteTextures(1, &fields[f][p].id);
6 CLog::Log(LOGDEBUG, "GL: Deleting texture field %d plane
%d", f+1, p+1);
7 }
8 fields[f][p].id = 0;
9 }

Do you have any clues about this behaviour? Any suggestions? I mean, I
could blame on thread safety here, but I would need a reason why this
code might fail.

If you need further details, I would be more than happy to provide you
with them.

Thanks,
A.
 
AntonioM...
Posted: Wed Sep 23, 2009 11:27 am
Guest
On 23 Set, 12:48, AntonioM <antom... at (no spam) gmail.com> wrote:
Quote:
Hi all,
[CUT]
Thanks,
A.

Should this be useful, I'm on Ubuntu 9.04, x86, with /usr/lib/libGL.so.
1 pointing to /usr/lib/libGL.so.190.32, coming from the nvidia Linux
driver, version 190.32 on a Zotac ION platform (NVidia Geforce 9400).

A.
 
AntonioM...
Posted: Wed Sep 23, 2009 2:03 pm
Guest
On 23 Set, 14:12, Wolfgang Draxinger <Wolfgang.Draxin... at (no spam) physik.uni-
muenchen.de> wrote:
Quote:
AntonioM wrote:
Do you have any clues about this behaviour? Any suggestions? I mean, I
could blame on thread safety here, but I would need a reason why this
code might fail.

It may be called in another thread than the actual render context is.

Uhm, ok, this might explain the issue. I have to say I did not altered
the interactions among thread, hence I expected the sequence of
execution to be quite similar to the original. I think I should try
the way you suggested down here. I'll try and report back if there's
any improvements.

Thanks.
 
AntonioM...
Posted: Wed Sep 23, 2009 2:54 pm
Guest
On 23 Set, 16:18, Wolfgang Draxinger <Wolfgang.Draxin... at (no spam) physik.uni-
muenchen.de> wrote:
Quote:

The thing is: All OpenGL operations must take place within the same thread.


Yes, the point is that I would have never distributed openGL
operations across different threads if the original code version
didn't do so, and I did not.

Quote:
Well, actually a render context can be used only within the thread it has
been created in. It is possible though to create in more than one thread and
tether the contexts of different threads together. But this is a very
fragile thing to do.

I had just read exactly the same thing on Richard Write's "OpenGL
Superbible".

Quote:
Just keep all OpenGL stuff bound to a single thread.

Never felt the need to write crazy code.
Thanks again.
 
Wolfgang Draxinger...
Posted: Wed Sep 23, 2009 4:12 pm
Guest
AntonioM wrote:

Quote:
Do you have any clues about this behaviour? Any suggestions? I mean, I
could blame on thread safety here, but I would need a reason why this
code might fail.

It may be called in another thread than the actual render context is.

BTW: glDeleteTexture is more like a hint, than a explicit deallocation of
texture memory. Instead of deleting the texture you might as well put the no
longer needed texture ID into a separate pool of IDs of which IDs are taken
and glGenTextures is only called if no spare IDs are avaliable. Heck, you
don't even need glGenTextures at all, you might as well use any texture ID
you like, just make sure you don't overwrite an existing texture.


Wolfgang
 
Wolfgang Draxinger...
Posted: Wed Sep 23, 2009 6:18 pm
Guest
AntonioM wrote:

Quote:
On 23 Set, 14:12, Wolfgang Draxinger <Wolfgang.Draxin... at (no spam) physik.uni-
muenchen.de> wrote:
AntonioM wrote:
Do you have any clues about this behaviour? Any suggestions? I mean, I
could blame on thread safety here, but I would need a reason why this
code might fail.

It may be called in another thread than the actual render context is.

Uhm, ok, this might explain the issue. I have to say I did not altered
the interactions among thread, hence I expected the sequence of
execution to be quite similar to the original. I think I should try
the way you suggested down here. I'll try and report back if there's
any improvements.

The thing is: All OpenGL operations must take place within the same thread.

Well, actually a render context can be used only within the thread it has
been created in. It is possible though to create in more than one thread and
tether the contexts of different threads together. But this is a very
fragile thing to do. Just keep all OpenGL stuff bound to a single thread.


Wolfgang
 
 
Page 1 of 1    
All times are GMT
The time now is Mon Dec 07, 2009 5:50 am