GPipe: Binding textures to geometry
I'm by no means an GL expert, but I think it should be possible to attach a texture index to vertices, so that only one fragment shader is needed instead of one for every texture. Currently, I'm duplicating the whole graphics pipeline for virtually every triangle, and it seems that is what's killing performance. Random minor nitpick: The matrix multiplications in the example are done on the CPU, not GPU. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
I'm guessing you're trying to have different pictures on each side of the example cube? You could use a Texture3D and have an extra depth component for each uv-coordinate. But you could also pair up each side with a separate texture as your doing now, and it will still only use one shader (but different sampler uniforms). For best performance however, you should put all six sides in a single 2D image and reference into this "texture-atlas". About performance, I'll release a new version in a week or so that will increase the performance for the example and most other usage scenarios. The matrix multiplications are done on the CPU intentionally since its an operation on constant values. Cheers Tobias
To: hopengl@haskell.org From: barsoap@web.de Date: Thu, 25 Feb 2010 23:15:15 +0100 Subject: [HOpenGL] GPipe: Binding textures to geometry
I'm by no means an GL expert, but I think it should be possible to attach a texture index to vertices, so that only one fragment shader is needed instead of one for every texture. Currently, I'm duplicating the whole graphics pipeline for virtually every triangle, and it seems that is what's killing performance.
Random minor nitpick: The matrix multiplications in the example are done on the CPU, not GPU.
-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
_________________________________________________________________ Klicka här! http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx
Tobias Bexelius
I'm guessing you're trying to have different pictures on each side of the example cube? You could use a Texture3D and have an extra depth component for each uv-coordinate.
I'm rendering Glyphs, so I have a significant amount of small textures (say, a hundred), replicated over properly positioned, orthogonal projected geometry. My concern is that using a Texture3D (or tiled Texture2D) would boycott performance by forcing construction of a new texture way more often than necessary (as I can't pre-construct the whole unicode range and the needed glyph set will change over time), but I admittedly don't have the numbers to back that up. I'm going to investigate.
But you could also pair up each side with a separate texture as your doing now, and it will still only use one shader (but different sampler uniforms). For best performance however, you should put all six sides in a single 2D image and reference into this "texture-atlas".
From my current understanding of GPipe, using a chain of paint* invocations invokes multiple full-screen render passes, am I correct? In practice, rendering a single "H" reports frame times of mostly around 1.5ms, some 5ms and a few 20-30ms. rendering "Hello, World" takes about 20ms, and a-zA-Z0-9 a full 80ms, a thousand 'x's 1.3 seconds, spending 81% of the time in alpha-blended paintColor -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
participants (2)
-
Achim Schneider -
Tobias Bexelius