[osg-users] Minor change proposal : Blacklist usage of all unsized texture internat format

[Julien Valentin]

Hi,

the support for unsized internal format is quite oldish...
it's quite a miracle that calls to glTexImage2D still work with both internalformat (rawdatadescription) and format (memory layout) set to GL_RGBA
-How can GLknow what we want in that case? there's definitly a default sized internalformat for GL_RGBA ...-

In my sense

-unsized internal formats should not have been supported by osg at the first place.

-the argument 'format' in osg usage of glTexImage ( _sourceFormat ? _sourceFormat : _internalFormat) is completely wrong
(you can't substitute a format with a sizedinternalFormat, that's 2 different stuff)


In the case with image attached
we can deduce a proper _internalformat from Image::_pixelFormat (customisation of this behavior is the reason of being of _internalFormatMode),

In the case no image is setted (_internalFormatMode==USE_USER_DEFINED_FORMAT)
we only can deduce format (_sourceFormat) and type(_internalFormatType) from a sized internalformat.
internalformat concernq GPUside representation and is mandatory to be specified by user.

My proposal would be
-to black list unsized format in order user code work both with the presence or not of glTexStorage
-to force user to set its own sourceFormat when no image attached

Is it so controversal?

Cheers,
Julien[/list]

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74505#74505

[Robert Osfield]

Hi Jilien,

My priority for the OpenSceneGraph is stability and backwards compatibility.

So if you are suggesting that is something the breaks backwards
compatibility/change behaviour then it's a problem.

OpenSceneGraph and OpenGL have evolved together over nearly two
decades, both are now in mature phase of their life. New features of
OpenGL/OpenSceneGraph can't break the old features that existing users
are using. Breaking old features just creates pain for users and more
support work.

So for this task rather than black listing the priority has to how to
wokr out how to keep existing applications working without changes.

Robert.



On Tue, 14 Aug 2018 at 02:30, Julien Valentin

Post by Julien Valentin
Hi,
the support for unsized internal format is quite oldish...
it's quite a miracle that calls to glTexImage2D still work with both internalformat (rawdatadescription) and format (memory layout) set to GL_RGBA
-How can GLknow what we want in that case? there's definitly a default sized internalformat for GL_RGBA ...-
In my sense
-unsized internal formats should not have been supported by osg at the first place.
-the argument 'format' in osg usage of glTexImage ( _sourceFormat ? _sourceFormat : _internalFormat) is completely wrong
(you can't substitute a format with a sizedinternalFormat, that's 2 different stuff)
In the case with image attached
we can deduce a proper _internalformat from Image::_pixelFormat (customisation of this behavior is the reason of being of _internalFormatMode),
In the case no image is setted (_internalFormatMode==USE_USER_DEFINED_FORMAT)
we only can deduce format (_sourceFormat) and type(_internalFormatType) from a sized internalformat.
internalformat concernq GPUside representation and is mandatory to be specified by user.
My proposal would be
-to black list unsized format in order user code work both with the presence or not of glTexStorage
-to force user to set its own sourceFormat when no image attached
Is it so controversal?
Cheers,
Julien[/list]
------------------------
Twirling twirling twirling toward freedom
------------------
http://forum.openscenegraph.org/viewtopic.php?p=74505#74505
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Julien Valentin]

I repose the problem:

Deductions when can do to help user setting its Texture (fill unsetted)
-Texture::_internalformat ->sourceFormat
-Image::_pixelformat->_internalFormat,_sourceFormat

glTexStorage only allow SIZED internalFormat whereas glTexImage allow both sized and unsized

Texture with Image already had glTexStorage support and there was no problem since _internalFormat is set based on a deduction from Image::_pixelFormat

I had glTexStorage for ImageLess Texture code path and now we see a problem: we don't have a _pixelFormat to deduce _intenalFoamt

One solution would be to add setup an other 'osg only' conventions to translate unsized to sized internalFormat.

Problem would be
-it add more convolution to understand what osg do with textures :/
-it could perhaps introduce divergence among diff hardware
(ex: I don't read anywhere that _internalFormat=GL_RGBA is understand as GL_RGBA8 or GL_RGBA16 on all machines)

So if noone have a better idea, my proposal is to simply to ban usage unsized _internalFormats. I think it would sanitize osg

Please, argue on this base

***@Roberts: If you call my proposal backward compatibility breaking, I think it would involve less pain for user code maintanability than the change you've made on _textureunit,..
i had to debug to see i can't anymore put the same texture on differents textureunits (and lot of code change were involved:/)...
And I think I'm not the only one using this "niche feature"...

Cheers

Post by Robert Osfield
Hi Jilien,
My priority for the OpenSceneGraph is stability and backwards compatibility.
So if you are suggesting that is something the breaks backwards
compatibility/change behaviour then it's a problem.
OpenSceneGraph and OpenGL have evolved together over nearly two
decades, both are now in mature phase of their life. New features of
OpenGL/OpenSceneGraph can't break the old features that existing users
are using. Breaking old features just creates pain for users and more
support work.
So for this task rather than black listing the priority has to how to
wokr out how to keep existing applications working without changes.
Robert.
On Tue, 14 Aug 2018 at 02:30, Julien Valentin

Post by Julien Valentin
Hi,
the support for unsized internal format is quite oldish...
it's quite a miracle that calls to glTexImage2D still work with both internalformat (rawdatadescription) and format (memory layout) set to GL_RGBA
-How can GLknow what we want in that case? there's definitly a default sized internalformat for GL_RGBA ...-
In my sense
-unsized internal formats should not have been supported by osg at the first place.
-the argument 'format' in osg usage of glTexImage ( _sourceFormat ? _sourceFormat : _internalFormat) is completely wrong
(you can't substitute a format with a sizedinternalFormat, that's 2 different stuff)
In the case with image attached
we can deduce a proper _internalformat from Image::_pixelFormat (customisation of this behavior is the reason of being of _internalFormatMode),
In the case no image is setted (_internalFormatMode==USE_USER_DEFINED_FORMAT)
we only can deduce format (_sourceFormat) and type(_internalFormatType) from a sized internalformat.
internalformat concernq GPUside representation and is mandatory to be specified by user.
My proposal would be
-to black list unsized format in order user code work both with the presence or not of glTexStorage
-to force user to set its own sourceFormat when no image attached
Is it so controversal?
Cheers,
Julien[/list]
------------------------
Twirling twirling twirling toward freedom
------------------
http://forum.openscenegraph.org/viewtopic.php?p=74505#74505
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74517#74517

[Robert Osfield]

HI Julien,

On Tue, 14 Aug 2018 at 17:24, Julien Valentin

Post by Julien Valentin
So if noone have a better idea, my proposal is to simply to ban usage unsized _internalFormats. I think it would sanitize osg

I have already rejected that idea.

Your changes to use glTextureStorage in master have broken the OSG for
existing users as reported elsewhere. I don't think it's acceptable.
Your changes have introduced a regression and we need to fix this, not
push the blame for this regression onto users for not explicitly
setting the internal format where applications were perfectly OK
previously.

You need to start thinking about backwards compatibility.

If glTextureStorage adds a requirement that the internal format is set
then perhaps we should just disable it's use when the internal format
is not set and just rely upon glTextureStorage when it is. This way
original usage will use the original code paths and not break
anything.

Robert.

[Julien Valentin]

If others users express themself on the subject It would be great...


I found what I searched for in the spec

The internal component resolution is the number of bits allocated to each value in a texture image. If internalformat is specified as a base internal format, the GL stores the resulting texture with internal component resolutions of its own choosing.

So GL implementation do whatever it want with base internal format.
If osg doesnt take care of these base internal formats, it can exibit behavior divergence among different hardwares...which is bad...

@Robert:
Please, don't rush in rejection, take your time to understand my point.
(I think I have enough developped it...to be understable)
and please explain me at last what do you mean by "not setting internalFormat". It doesn't make any sense to me ?!

Cheers

HI Julien,
On Tue, 14 Aug 2018 at 17:24, Julien Valentin

Post by Julien Valentin
So if noone have a better idea, my proposal is to simply to ban usage unsized _internalFormats. I think it would sanitize osg

I have already rejected that idea.
Your changes to use glTextureStorage in master have broken the OSG for
existing users as reported elsewhere. I don't think it's acceptable.
Your changes have introduced a regression and we need to fix this, not
push the blame for this regression onto users for not explicitly
setting the internal format where applications were perfectly OK
previously.
You need to start thinking about backwards compatibility.
If glTextureStorage adds a requirement that the internal format is set
then perhaps we should just disable it's use when the internal format
is not set and just rely upon glTextureStorage when it is. This way
original usage will use the original code paths and not break
anything.
Robert.

Post by Julien Valentin
Deductions we can do to help user setting its Texture (fill unsetted)
-Texture::_internalformat ->sourceFormat
-Image::_pixelformat->_internalFormat,_sourceFormat
glTexStorage only allow SIZED internalFormat whereas glTexImage allow both sized and unsized
Texture with Image already had glTexStorage support and there was no problem since _internalFormat is set based on a deduction from Image::_pixelFormat
I added glTexStorage for ImageLess Texture code path and now we see a problem: we don't have a _pixelFormat to deduce _intenalFoamt
One solution would be to add an other 'osg only' conventions to translate unsized to sized internalFormat.
Problem would be
-it add more convolutions to understand what osg do with textures :/
-it could perhaps introduce divergence among diff hardware
(ex: I don't read anywhere that _internalFormat=GL_RGBA is understand as GL_RGBA8 or GL_RGBA16 on all machines)
So if noone have a better idea, my proposal is to simply ban usage of unsized _internalFormats. I think it would sanitize osg
Please, argue on this base
i had to debug to see i can't anymore put the same texture on differents textureunits (and lot of code change were involved:/)...
And I think I'm not the only one using this "niche feature"...
Cheers

------------------
Post generated by Mail2Forum

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74521#74521

[Robert Osfield]

On Wed, 15 Aug 2018 at 01:10, Julien Valentin

Post by Julien Valentin
Please, don't rush in rejection, take your time to understand my point.
(I think I have enough developped it...to be understable)
and please explain me at last what do you mean by "not setting internalFormat". It doesn't make any sense to me ?!

I fully understand your point of view. I have totally different
opinion on what we should do because I'm project lead and have a
responsibility to the community so my priorities aren't the same as
yours

Your approach has been rejected. It's not a matter of convincing me
or others, as it won't change why your approach has been rejected. We
can't go breaking existing users code which your change already have
done and we need to figure out how to resolve this regression without
pushing changes on users own code.

If you are unwilling to come up with a way to resolve this regression
without forcing changes on user code then I will have to step in and
either revert your changes or refactor things.

Robert.

[Robert Osfield]

Hi Julian,

I have been looking through the glTexStorage changes and the
background to this GL feature.

It doesn't look like to me that glTexStorage* has any functionality
benefit over just using the original glTexImage* code. Yes
glTexStorage is the "modern" way to do things in recent GL version
(now part of the core in GL4.2), and yes it's cleaner if you are
writing clean room code, but I can't see any actual benefit to OSG
users who don't have to grapple with the low level set up details.

At this point the cleanest thing for the OSG to do is not use
glTexStoage at all. We can simplify all the code paths and make the
behaviours more consistent.

For maintaining the OSG is far better to reduce the number of separate
code code paths that do the same thing but in different ways. I now
believe the glTexStorge merges were a step back for maintainability.

Is there anything that reverting all the glTexStorage changes that
users won't be able to do?

--

For those who want to use bleeding stuff I now think you should start
thinking in terms of have Vulkan as your base. Within the year I'll
have a Vulkan based scene graph open sourced and heading towards 1.0.
So there will be a good migration path in the not too distant future.
The pressure on using bleeding edge features in the OSG is now far
lower.

For those who have large applications to maintain that are based on
the OSG then their focus is maintaining that and avoiding regressions
when they update to new versions of the OSG.

Robert.

[Julien Valentin]

Hi Robert

Seriously?!
Do I have to teach you benefit of using immutable memory?
No I will not do that...
Rather I'd prefer you finish what you're doing and come back with more attention

Take your time to gauge next week or something because I'm really tired of monologing...

Cheers

Post by Robert Osfield
Hi Julian,
I have been looking through the glTexStorage changes and the
background to this GL feature.
It doesn't look like to me that glTexStorage* has any functionality
benefit over just using the original glTexImage* code. Yes
glTexStorage is the "modern" way to do things in recent GL version
(now part of the core in GL4.2), and yes it's cleaner if you are
writing clean room code, but I can't see any actual benefit to OSG
users who don't have to grapple with the low level set up details.
At this point the cleanest thing for the OSG to do is not use
glTexStoage at all. We can simplify all the code paths and make the
behaviours more consistent.
For maintaining the OSG is far better to reduce the number of separate
code code paths that do the same thing but in different ways. I now
believe the glTexStorge merges were a step back for maintainability.
Is there anything that reverting all the glTexStorage changes that
users won't be able to do?
--
For those who want to use bleeding stuff I now think you should start
thinking in terms of have Vulkan as your base. Within the year I'll
have a Vulkan based scene graph open sourced and heading towards 1.0.
So there will be a good migration path in the not too distant future.
The pressure on using bleeding edge features in the OSG is now far
lower.
For those who have large applications to maintain that are based on
the OSG then their focus is maintaining that and avoiding regressions
when they update to new versions of the OSG.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74531#74531

[Robert Osfield]

Hi Julien,

I wanting to know what problems the glTexStorage solves that aren't
addressed by original non glTexImage code. I want know the
justification for the extra complexity and the pain that it has caused
other users with regressions.

The OSG is not a clean room OpenGL scene graph implementation that
just takes OpenGL 4.6 and attempts to implement what is deemed best
practice for the most recent versions of GL. It supports a wide range
of different OpenGL versions across a wide range of platforms.
Maintaining that is my priority.

Each feature we add to the OSG needs to be justified by what
functionality it provides to end users, ticking boxes of what latest
GL features are supported is irrelevant, it's only functionality that
is of relevance.

As project lead the buck stops with me for trying to figure out how to
resolve bugs and maintain the code, I don't get to check in code and
then move onto my next favourite shiny toy, if I did the OSG would end
up in a completely in usable quagmire.

So if I ask a question and you don't even begin to provide an answer,
I have to really wonder if you have any real justification behind the
changes you are pushing.

Robert.

[Julien Valentin]

Ok
I'll do the pr you want from me
(with this ugly patch code:

Code:

ex for Texture2D:
if( useTexStorrage)
extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels >0)?_numMipmapLevels:1,
_sourceFormat ? assumeSizedInternalFormat(_internalFormat,_sourceFormat) :
assumeSizedInternalFormat(_internalFormat,GL_UNSIGNED_BYTE),
_textureWidth, _textureHeight);
)


just to demo good will on it but I protest:
when you break feature you say it's a "niche feature" (use differents texture units of the same Texture in different StateSets)
but when I propose to break a minor niche feature (image less texture setup),
there's no possible discussion...

Post by Julien Valentin
Hi Robert
Seriously?!
Do I have to teach you benefit of using immutable memory?
No I will not do that...
Rather I'd prefer you finish what you're doing and come back with more attention
Take your time to gauge next week or something because I'm really tired of monologing...
Cheers

Post by Robert Osfield
Hi Julian,
I have been looking through the glTexStorage changes and the
background to this GL feature.
It doesn't look like to me that glTexStorage* has any functionality
benefit over just using the original glTexImage* code. Yes
glTexStorage is the "modern" way to do things in recent GL version
(now part of the core in GL4.2), and yes it's cleaner if you are
writing clean room code, but I can't see any actual benefit to OSG
users who don't have to grapple with the low level set up details.
At this point the cleanest thing for the OSG to do is not use
glTexStoage at all. We can simplify all the code paths and make the
behaviours more consistent.
For maintaining the OSG is far better to reduce the number of separate
code code paths that do the same thing but in different ways. I now
believe the glTexStorge merges were a step back for maintainability.
Is there anything that reverting all the glTexStorage changes that
users won't be able to do?
--
For those who want to use bleeding stuff I now think you should start
thinking in terms of have Vulkan as your base. Within the year I'll
have a Vulkan based scene graph open sourced and heading towards 1.0.
So there will be a good migration path in the not too distant future.
The pressure on using bleeding edge features in the OSG is now far
lower.
For those who have large applications to maintain that are based on
the OSG then their focus is maintaining that and avoiding regressions
when they update to new versions of the OSG.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74533#74533

[Robert Osfield]

Hi Julien,

On Wed, 15 Aug 2018 at 16:35, Julien Valentin

Post by Julien Valentin
I'll do the pr you want from me
if( useTexStorrage)
extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels >0)?_numMipmapLevels:1,
assumeSizedInternalFormat(_internalFormat,GL_UNSIGNED_BYTE),
_textureWidth, _textureHeight);
)

It is indeed ugly change, the best way to avoid this code complexity
would be to push the test into a dedicated helper method such
selectInternalFormat(). I don't saying this is the actual solution to
go for but that's the general way to avoid extra tests from
obfuscating local code.

--

However, having don't a first pass look into the wider glTexStorage
issue I'm truck by just by adding glTexStorage* usage is what is
complicating all the texture setup code, as glTexStorage isn't
available everywhere we can't remove the old glTexImage calls, so we
are stuck with two code paths, in some case these two code paths have
lots of nested if () blocks within them so it's a substantial amount
of code that is being added.

Every line of extra code is an extra potential sight for bugs, every
extra optional code path adds another platform combination that needs
testing - and as us developers are limited resource each of these code
paths has less usage exposure, the less exposure the more likely bugs
are likely to creep into the code without being spotted.

So for code quality we need to avoid optional code path where
possible. If we have to introduce an optional code path it has to be
justified by real functionality.

So for the topic of glTexStorage I'm asking do we *really* need it,
what things can't be done without it's usage.

What is the killer feature that requires use of glTexSorage? This is
an honest question, I want to know.

Robert.

[Julien Valentin]

Immutable Storage mandatory for lot of GL4 features:
TextureImage synchronization,TextureView, persistance mapping, virtual texture and surely other stuff I didn't used yet

Further it's better for the driver checks

Post by Robert Osfield
Hi Julien,
On Wed, 15 Aug 2018 at 16:35, Julien Valentin

Post by Julien Valentin
I'll do the pr you want from me
if( useTexStorrage)
extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels >0)?_numMipmapLevels:1,
assumeSizedInternalFormat(_internalFormat,GL_UNSIGNED_BYTE),
_textureWidth, _textureHeight);
)

It is indeed ugly change, the best way to avoid this code complexity
would be to push the test into a dedicated helper method such
selectInternalFormat(). I don't saying this is the actual solution to
go for but that's the general way to avoid extra tests from
obfuscating local code.
--
However, having don't a first pass look into the wider glTexStorage
issue I'm truck by just by adding glTexStorage* usage is what is
complicating all the texture setup code, as glTexStorage isn't
available everywhere we can't remove the old glTexImage calls, so we
are stuck with two code paths, in some case these two code paths have
lots of nested if () blocks within them so it's a substantial amount
of code that is being added.
Every line of extra code is an extra potential sight for bugs, every
extra optional code path adds another platform combination that needs
testing - and as us developers are limited resource each of these code
paths has less usage exposure, the less exposure the more likely bugs
are likely to creep into the code without being spotted.
So for code quality we need to avoid optional code path where
possible. If we have to introduce an optional code path it has to be
justified by real functionality.
So for the topic of glTexStorage I'm asking do we *really* need it,
what things can't be done without it's usage.
What is the killer feature that requires use of glTexSorage? This is
an honest question, I want to know.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74535#74535

[Julien Valentin]

the killer feature requiring immutable texture is BindImageTexture...

Post by Julien Valentin
TextureImage synchronization,TextureView, persistance mapping, virtual texture and surely other stuff I didn't used yet
Further it's better for the driver checks

Post by Robert Osfield
Hi Julien,
On Wed, 15 Aug 2018 at 16:35, Julien Valentin

Post by Julien Valentin
I'll do the pr you want from me
if( useTexStorrage)
extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels >0)?_numMipmapLevels:1,
assumeSizedInternalFormat(_internalFormat,GL_UNSIGNED_BYTE),
_textureWidth, _textureHeight);
)

It is indeed ugly change, the best way to avoid this code complexity
would be to push the test into a dedicated helper method such
selectInternalFormat(). I don't saying this is the actual solution to
go for but that's the general way to avoid extra tests from
obfuscating local code.
--
However, having don't a first pass look into the wider glTexStorage
issue I'm truck by just by adding glTexStorage* usage is what is
complicating all the texture setup code, as glTexStorage isn't
available everywhere we can't remove the old glTexImage calls, so we
are stuck with two code paths, in some case these two code paths have
lots of nested if () blocks within them so it's a substantial amount
of code that is being added.
Every line of extra code is an extra potential sight for bugs, every
extra optional code path adds another platform combination that needs
testing - and as us developers are limited resource each of these code
paths has less usage exposure, the less exposure the more likely bugs
are likely to creep into the code without being spotted.
So for code quality we need to avoid optional code path where
possible. If we have to introduce an optional code path it has to be
justified by real functionality.
So for the topic of glTexStorage I'm asking do we *really* need it,
what things can't be done without it's usage.
What is the killer feature that requires use of glTexSorage? This is
an honest question, I want to know.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum

------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74536#74536

[Robert Osfield]

Hi Julien,

On Thu, 16 Aug 2018 at 02:30, Julien Valentin

Post by Julien Valentin
TextureImage synchronization,TextureView, persistance mapping, virtual texture and surely other stuff I didn't used yet

Thanks, this is what I was missing. I had been searching online for
discussion about glTexStorage vs glTexImage but didn't come across
compelling reasons.

If these modern features don't work without glTexStorage usage then do
we have to have a flag in osg::Texture saying it's being actively
used? Or is good enough to just make sure glTexStorage is used widely
enough and all GL4 usage that depends upon it all check the
GLExtensions.

Robert.

[Gedalia Pasternak]

glTexStorage is much faster then glTexImage because it allocates the whole
memory buffer in one shot, glTeximage take quite a bit longer to allocate
the memory, not sure if it's 1.3333x or even longer than that due to
reallocing and moving the memory if needed. I'm running off 3.4 and made a
number of fixes to try and make sure glTexStorage was used all of the time.
-gedalia

Post by Robert Osfield
Hi Julien,
On Thu, 16 Aug 2018 at 02:30, Julien Valentin

Post by Julien Valentin
TextureImage synchronization,TextureView, persistance mapping, virtual

texture and surely other stuff I didn't used yet
Thanks, this is what I was missing. I had been searching online for
discussion about glTexStorage vs glTexImage but didn't come across
compelling reasons.
If these modern features don't work without glTexStorage usage then do
we have to have a flag in osg::Texture saying it's being actively
used? Or is good enough to just make sure glTexStorage is used widely
enough and all GL4 usage that depends upon it all check the
GLExtensions.
Robert.
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org