 |
|
| Computers Forum Index » Computer - Graphics - API (Opengl) » glDeleteTextures... |
|
Page 1 of 1 |
|
| 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. |
|
|
| Back to top |
|
|
|
| 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. |
|
|
| Back to top |
|
|
|
| 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. |
|
|
| Back to top |
|
|
|
| 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. |
|
|
| Back to top |
|
|
|
| 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 |
|
|
| Back to top |
|
|
|
| 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 |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Mon Dec 07, 2009 5:50 am
|
|