Jump to content

  • Log In with Google      Sign In   
  • Create Account

wglShareList with Query Objects


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 BornToCode   Members   -  Reputation: 926

Like
0Likes
Like

Posted 29 August 2013 - 02:32 AM

Using wglShareList with any gl object context works fine. But i am kind of confuse as to why Query Objects do not work. Does anyone know why. When i create an Query object on one context and then switch to a different context which is shared glIsQuery is returning 0. But for every other resource it works fine.

Sponsor:

#2 samoth   Crossbones+   -  Reputation: 4783

Like
0Likes
Like

Posted 29 August 2013 - 11:18 AM

The documentation to wglShareList is not very specific (and wrong/incomplete, because it only talks about sharing lists, not textures or other things), but the specification of WGL_ARB_create_context which is the more modern context sharing implementation is more precise. It states that GL objects for which it makes sense to be shared are shared, if the respective context versions allow for it. That means for example, shaders from a GL3/GL4 context are not shared with a GL2 context (but textures would be).

 

Now it is debatable whether sharing query objects makes sense or not, but it seems like the implementors seem to think it doesn't make a lot of sense (and I somewhat agree -- what exactly would you want e.g. the number of fragments rendered in another context, it's of no use).

 

It does make sense to share fences (and those do indeed work!), textures, and shaders.



#3 BornToCode   Members   -  Reputation: 926

Like
0Likes
Like

Posted 29 August 2013 - 04:13 PM

The documentation to wglShareList is not very specific (and wrong/incomplete, because it only talks about sharing lists, not textures or other things), but the specification of WGL_ARB_create_context which is the more modern context sharing implementation is more precise. It states that GL objects for which it makes sense to be shared are shared, if the respective context versions allow for it. That means for example, shaders from a GL3/GL4 context are not shared with a GL2 context (but textures would be).

 

Now it is debatable whether sharing query objects makes sense or not, but it seems like the implementors seem to think it doesn't make a lot of sense (and I somewhat agree -- what exactly would you want e.g. the number of fragments rendered in another context, it's of no use).

 

It does make sense to share fences (and those do indeed work!), textures, and shaders.

What i was wanted to do is that when i call glEndQuery instead of waiting for the Query result. I would have it wait for the result on a queue in a background thread on another context which is shared. That way my program can continue executing, while it keep checking in the background thread if the result is ready. Once it is it would let the main thread know.


Edited by BornToCode, 29 August 2013 - 04:14 PM.


#4 BornToCode   Members   -  Reputation: 926

Like
0Likes
Like

Posted 30 August 2013 - 01:22 PM

It seems like in GL 4.4 you will be able to do what i am trying to accomplish using the ability to have query object outputs to a buffer.


Edited by BornToCode, 30 August 2013 - 01:23 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS