multithreaded texture usage

If I have a texture in use by multiple threads and one thread calls:

glBindTexture(TexTarget, ColorTexture);
glTexParameterf(TexTarget, GL_TEXTURE_WRAP_S, TexWrapS);
glTexParameterf(TexTarget, GL_TEXTURE_WRAP_T, TexWrapT);
glTexParameteri(TexTarget, GL_TEXTURE_MIN_FILTER, MinFilter);
glTexParameteri(TexTarget, GL_TEXTURE_MAG_FILTER, MagFilter);

will those calls affect the other thread? eg. I want to use the same texture filtered with nearest on one thread and trilinear on another.

I guess what I am asking is if the texture wrap mode and texture filter mode are property of the texture sampler unit or the texture object.

My guess from reading the spec is it will not be propagated
to the other context as long as the texture object is already bound.

But at some point, the glTexParameter calls will affect the other
context.

ref:

Spec 3.1 Appendix D “Shared Objects and Multiple Contexts”

section D.2 “Propagation State Changes” page 292

Changes to an object may occur via any of the following means:

  • State-setting commands, such as TexParameter.
    […]

page 294

Rule 3 State changes to shared objects are not automatically propagated between contexts. If the state of a shared object T is changed in a context other than the current context, and T is already directly or indirectly attached to the current context, any operations on the current context involving T via those attachments are not guaranteed to use its new state.

hmmm… ok. It seems you are implying wrap/filter state information is part of the texture object state. So I can’t do what I want.

It seems unfortunate to me that the wrap/filter modes belong to the texture object state rather belonging to the texture sampler state or perhaps being a separate state object that is optionally attachable to the texture object. I can see how having the texture object remember the wrap/filter modes it was last used with might be a useful feature as it would save programmers from having to reset them each time you bind the texture… but I wonder if at the driver level they affect how the texture data is stored.

I don’t suppose there would be any way to work around this by having two textures objects share the same texture data array/buffer in GPU memory? I can’t think of any extensions off the top of my head that would help here.

I believe the state information you refer to, is part of the texture sampler unit (and not the texture object state). You should be able to bind the same texture to different texture unit (each with a different filter) and use multi-texturing to sample with both linear or trilinear. Please correct me if I misunderstood this :slight_smile:

you’ve misunderstood it.
all the states set using glTexParameter() functions belong to the currently active texture object, and sit in its knapsack forever more. Yes, you have to have 2 unique texture objects, replicating the image data etc. just so you can have different sampling filters in a single pass.
glTexEnv() functions set states that belong to the texture unit.
Yes, it is so wrong, but so are a lot of things with GL. Moaning doesn’t get you anywhere, as was so clearly demonstrated last year.

Wups sure, don’t know why I confused texEnv and texParam that night. Good thing you caught that Knackered.