OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Minor change proposal : Blacklist usage of all unsized texture internat format


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Mon Aug 13, 2018 1:42 pm    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Tue Aug 14, 2018 6:15 am    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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
<> wrote:
Quote:

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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Tue Aug 14, 2018 3:06 pm    Post subject:
Re: Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

I repose the problem:

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

PS@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

robertosfield wrote:
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
<> wrote:
Quote:

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








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

_________________
Twirling twirling twirling toward freedom
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Tue Aug 14, 2018 5:03 pm    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

HI Julien,

On Tue, 14 Aug 2018 at 17:24, Julien Valentin
<> wrote:
Quote:
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 generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Wed Aug 15, 2018 12:00 am    Post subject:
Re: Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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


I found what I searched for in the spec
Quote:
section "8.5 Texture Image Specification":
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...

Further if I follow osg path to use osg conventions to patch changes if made
I will have to use
GLenum Texture::assumeSizedInternalFormat(GLint internalFormat, GLenum type)
which return sized internalFormat
but require a _sourceType to be setted (which would add setup requirements and so break usercode)
no...I stay on the idea users dealing with imageless textures should know what they're doing and don't want osg to possibly alter their setting

@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

robertosfield wrote:
HI Julien,

On Tue, 14 Aug 2018 at 17:24, Julien Valentin
<> wrote:
Quote:
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.
mp3butcher wrote:
I repose the problem:

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

PS@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 generated by Mail2Forum

_________________
Twirling twirling twirling toward freedom
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Wed Aug 15, 2018 7:45 am    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

On Wed, 15 Aug 2018 at 01:10, Julien Valentin
<> wrote:
Quote:
@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 ?!

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Wed Aug 15, 2018 9:12 am    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Wed Aug 15, 2018 1:54 pm    Post subject:
Re: Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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

robertosfield wrote:
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.


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

_________________
Twirling twirling twirling toward freedom
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Wed Aug 15, 2018 2:45 pm    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Wed Aug 15, 2018 2:50 pm    Post subject:
Re: Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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

ex for TextureRectangle:
        //ensure _internalFormat is sized
            GLenum sized_internalFormat =_internalFormat;
            if(!isSizedInternalFormat( sized_internalFormat))
                    sized_internalFormat=  assumeSizedInternalFormat(sized_internalFormat,_sourceType?_sourceType:GL_UNSIGNED_BYTE);
            extensions->glTexStorage2D( GL_TEXTURE_RECTANGLE, 1, sized_internalFormat, _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...


mp3butcher wrote:
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

robertosfield wrote:
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.


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

_________________
Twirling twirling twirling toward freedom
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Wed Aug 15, 2018 3:49 pm    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

Hi Julien,

On Wed, 15 Aug 2018 at 16:35, Julien Valentin
<> wrote:
Quote:
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);
)


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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Wed Aug 15, 2018 4:03 pm    Post subject:
Re: Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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

robertosfield wrote:
Hi Julien,

On Wed, 15 Aug 2018 at 16:35, Julien Valentin
<> wrote:
Quote:
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);
)


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.


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

_________________
Twirling twirling twirling toward freedom
Back to top
View user's profile Send private message Visit poster's website
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 513
Location: France

PostPosted: Wed Aug 15, 2018 8:57 pm    Post subject:
Re: Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

the killer feature requiring immutable texture is BindImageTexture...

mp3butcher wrote:
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

robertosfield wrote:
Hi Julien,

On Wed, 15 Aug 2018 at 16:35, Julien Valentin
<> wrote:
Quote:
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);
)


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.


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

_________________
Twirling twirling twirling toward freedom
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12215

PostPosted: Thu Aug 16, 2018 7:42 am    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

Hi Julien,

On Thu, 16 Aug 2018 at 02:30, Julien Valentin
<> wrote:
Quote:
Immutable Storage mandatory for lot of GL4 features:
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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Gedalia Pasternak
Guest





PostPosted: Thu Aug 16, 2018 3:47 pm    Post subject:
Minor change proposal : Blacklist usage of all unsized texture internat format
Reply with quote

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


On Thu, Aug 16, 2018 at 3:41 AM, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hi Julien,

On Thu, 16 Aug 2018 at 02:30, Julien Valentin
< (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Immutable Storage  mandatory for lot of GL4 features:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140

------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts EXTERNAL: Re: EXTERNAL: Re: Texture u... Rowley, Marlin R General 1 Thu Mar 14, 2019 5:56 pm View latest post
No new posts EXTERNAL: Re: Texture unit not turni... Rowley, Marlin R General 1 Thu Mar 14, 2019 2:06 pm View latest post
No new posts Texture unit not turning ON Rowley, Marlin R General 1 Wed Mar 13, 2019 6:37 pm View latest post
No new posts updatecallback deprecation proposal mp3butcher General 1 Wed Mar 06, 2019 12:27 am View latest post
No new posts How to change camera's yaw and pitch,... Rodrigo General [3rdparty] 3 Thu Jan 31, 2019 12:43 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP