StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
8233737
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-11-22T20:58:57.653
FavoriteCount
0
LastActivityDate
2011-11-22T20:58:57.653
LastEditDate
LastEditorUserId
0
OwnerUserId
161554
ParentId
8227259
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
It almost depends of what you are meaning. Branching in a shader program affect performances in GPU terms: if your vertex arrays are very long, I would avoid branching; instead use preprocessor and link multiple different programs. Having a single-complex-huge shader program boost performance in CPU terms: each glUseProgram takes time, and you may want to call it only once (al least less). Are the CPU advantages greater than the GPU advantages? Answering to this question answer your question. ... Personally I go with preprocessor and I avoid branching for fundamental purposes. Each shader program has well-defined interfaces, and different objects implements them; attaching different objects complete the program implementation. Implementing a #include directive helps a lot. Common declarations are included in different objects, and only statically accessed attributes and uniforms are effectively linked into the program. This is an example of a shader program of mine: <pre><code>#include </Derm/Shaders/IProjectVertex> #include </Derm/Shaders/Compatibility> #include </Derm/Shaders/Standard/ShaderInputs> #include </Derm/Shaders/Standard/IColorVertex> // --- Vertex shader outputs // This shader output interface BEGIN_OUTPUT_BLOCK(FragmentShaderVaryings) // Processed vertex color vec4 ds_Color; // Processed vertex texture coordinate END_OUTPUT_BLOCK() // Vertex shader entry point void main() { // Compute transformed vertex position gl_Position = ProjectVertexPosition(ds_VertexPosition); #if defined(DS_COLOR_PER_VERTEX) // Support vertex color ds_Color = ComputeVertexColor(); #endif // Support vertex texturing #if defined(DS_TEXTURE) ds_TexCoords = ds_VertexTexCoord; #endif } </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhen should I stop complicating a GLSL-ES shader and start splitting them in smaller, simpler ones?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USLuca
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POWhen should I stop complicating a GLSL-ES shader and start splitting them in smaller, simpler ones?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.