From: Charles L. <ch...@cn...> - 2009-08-22 06:38:22
|
Devs, I have been examining the pipeline for textures. I have found that there is a large slow down whenever binding/unbinding textures. I also feel that there is little need to have the textures always clean up after themselves, as it would enable a scene optimizer to group like objects. Simply by asking "is the current texture the one that is active right now" we can avoid having to disable textures and re-deploy them when done. In a case like the field of lamps, we are able to bypass the field. It would also make it possible to have the texture be a persistent item, and having it pass on to its children. I propose: We do not unbind textures from OpenGL (until in the future we have an option where a texture is a some sort of TEXTURE OFF thing) We store a static pointer to the currently OpenGL binded texture. When we bind a texture, we set that. When we encounter a texture that has already been set, take no action. By performing this, the GL call count was less than half (now it's just over 1k per scene) I ran a few tests where I made the window small, thus avoiding pixel fill time. Without profiling, dumb textures: FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 Without profiling, smart-ish textures, smart matrixing: (Textures bind always, but never unbind) (smart matrix means only updating the matrix info if the object has assets attached to it) FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 Without profiling, smart textures: (Textures never unbind, and only bind when needed) FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 Without profiling, smart textures, smart matrixing: FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 Charles |
From: Josh <axl...@gm...> - 2009-08-22 11:59:40
|
This is actually what I am currently looking into. I'm trying to figure out if you can just leave textures bound and just enable or disable them. If we can do that, then we cold make use of the maximum number of bound textures to reduce binds. Josh Charles Lohr wrote: > Devs, > > I have been examining the pipeline for textures. I have found that > there is a large slow down whenever binding/unbinding textures. I also > feel that there is little need to have the textures always clean up > after themselves, as it would enable a scene optimizer to group like > objects. Simply by asking "is the current texture the one that is > active right now" we can avoid having to disable textures and re-deploy > them when done. In a case like the field of lamps, we are able to > bypass the field. It would also make it possible to have the texture be > a persistent item, and having it pass on to its children. > > I propose: > We do not unbind textures from OpenGL (until in the future we have an > option where a texture is a some sort of TEXTURE OFF thing) > We store a static pointer to the currently OpenGL binded texture. > When we bind a texture, we set that. When we encounter a texture that > has already been set, take no action. > > By performing this, the GL call count was less than half (now it's just > over 1k per scene) > > I ran a few tests where I made the window small, thus avoiding pixel > fill time. > > > Without profiling, dumb textures: > FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 > > Without profiling, smart-ish textures, smart matrixing: (Textures bind > always, but never unbind) (smart matrix means only updating the matrix > info if the object has assets attached to it) > FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 > > Without profiling, smart textures: (Textures never unbind, and only bind > when needed) > FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 > > Without profiling, smart textures, smart matrixing: > FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 > > > Charles > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Charles L. <ch...@cn...> - 2009-08-22 15:18:46
|
Additionally, I feel it would be pretty cool to let the user intentionally leave textures bound. They could add the texture to a parent node, then have it be applied to all of the children. I think it is a very simple solution. We just do exactly what I outlined, and we have to add some mechanism to turn textures off, like the texture has some flag in the XML that just means it's a texture disabler. I can make all of these changes very quickly if you give me the green light. Charles Josh wrote: > This is actually what I am currently looking into. > I'm trying to figure out if you can just leave textures bound and just > enable or disable them. > If we can do that, then we cold make use of the maximum number of bound > textures to reduce binds. > > Josh > > > Charles Lohr wrote: > >> Devs, >> >> I have been examining the pipeline for textures. I have found that >> there is a large slow down whenever binding/unbinding textures. I also >> feel that there is little need to have the textures always clean up >> after themselves, as it would enable a scene optimizer to group like >> objects. Simply by asking "is the current texture the one that is >> active right now" we can avoid having to disable textures and re-deploy >> them when done. In a case like the field of lamps, we are able to >> bypass the field. It would also make it possible to have the texture be >> a persistent item, and having it pass on to its children. >> >> I propose: >> We do not unbind textures from OpenGL (until in the future we have an >> option where a texture is a some sort of TEXTURE OFF thing) >> We store a static pointer to the currently OpenGL binded texture. >> When we bind a texture, we set that. When we encounter a texture that >> has already been set, take no action. >> >> By performing this, the GL call count was less than half (now it's just >> over 1k per scene) >> >> I ran a few tests where I made the window small, thus avoiding pixel >> fill time. >> >> >> Without profiling, dumb textures: >> FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 >> >> Without profiling, smart-ish textures, smart matrixing: (Textures bind >> always, but never unbind) (smart matrix means only updating the matrix >> info if the object has assets attached to it) >> FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >> >> Without profiling, smart textures: (Textures never unbind, and only bind >> when needed) >> FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >> >> Without profiling, smart textures, smart matrixing: >> FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >> >> >> Charles >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh <axl...@gm...> - 2009-08-22 15:51:02
|
Charles Lohr wrote: > Additionally, I feel it would be pretty cool to let the user > intentionally leave textures bound. They could add the texture to a > parent node, then have it be applied to all of the children. > That's how it works now. > I think it is a very simple solution. We just do exactly what I > outlined, and we have to add some mechanism to turn textures off, like > the texture has some flag in the XML that just means it's a texture > disabler. > > I can make all of these changes very quickly if you give me the green light. > > Na I wanna try my idea, which will include skipping texture re-binds. In the past, I think we did this but I may have had to remove it for some reason. > Charles > > > > Josh wrote: > >> This is actually what I am currently looking into. >> I'm trying to figure out if you can just leave textures bound and just >> enable or disable them. >> If we can do that, then we cold make use of the maximum number of bound >> textures to reduce binds. >> >> Josh >> >> >> Charles Lohr wrote: >> >> >>> Devs, >>> >>> I have been examining the pipeline for textures. I have found that >>> there is a large slow down whenever binding/unbinding textures. I also >>> feel that there is little need to have the textures always clean up >>> after themselves, as it would enable a scene optimizer to group like >>> objects. Simply by asking "is the current texture the one that is >>> active right now" we can avoid having to disable textures and re-deploy >>> them when done. In a case like the field of lamps, we are able to >>> bypass the field. It would also make it possible to have the texture be >>> a persistent item, and having it pass on to its children. >>> >>> I propose: >>> We do not unbind textures from OpenGL (until in the future we have an >>> option where a texture is a some sort of TEXTURE OFF thing) >>> We store a static pointer to the currently OpenGL binded texture. >>> When we bind a texture, we set that. When we encounter a texture that >>> has already been set, take no action. >>> >>> By performing this, the GL call count was less than half (now it's just >>> over 1k per scene) >>> >>> I ran a few tests where I made the window small, thus avoiding pixel >>> fill time. >>> >>> >>> Without profiling, dumb textures: >>> FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 >>> >>> Without profiling, smart-ish textures, smart matrixing: (Textures bind >>> always, but never unbind) (smart matrix means only updating the matrix >>> info if the object has assets attached to it) >>> FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >>> >>> Without profiling, smart textures: (Textures never unbind, and only bind >>> when needed) >>> FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >>> >>> Without profiling, smart textures, smart matrixing: >>> FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >>> >>> >>> Charles >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>> trial. Simplify your report design, integration and deployment - and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Hgengine-devs mailing list >>> Hge...@li... >>> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >>> >>> >>> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |