Semantics, shaders, and fixups
Ivan Gyurdiev
ivg231 at gmail.com
Mon Jul 3 07:12:32 CDT 2006
H. Verbeet wrote:
> On 03/07/06, Ivan Gyurdiev <ivg231 at gmail.com> wrote:
>> > Well, it is wrong.
>> How is it wrong?
>> In one case you have a semantic, and you use that to load up the correct
>> register (query shader, shader gives you the index to load). In the
>> other case you preinitialize the semantics with the declaration register
>> numbers - it's all the same thing really. I know this works, because
>> I've already written the code.
> In the sense that you're making up a semantic based on the register
> number, but not necessarily the correct one.
That's not particularly important. The shader semantics aren't correct
either - I see apps putting all kinds of data in TEXCOORD semantics that
have nothing to do with textures. When I tried to run that through
drawStridedSlow for software shaders it wouldn't work properly, since
drawStridedSlow was interpreting the data and making sure a matching
texture is found.
What's important is how you use the semantic to map to vshader inputs -
and that will work correctly. It also goes in its own function
(vshader_get_input(usage, usage_index) -> regnum (,writemask?) ), so no
more accessing semantics map from within drawprim directly.
> But perhaps if you take
> the data type into account when making up the semantic it might still
> work.
Why would I do that - just adds extra complexity that's not necessary,
and doesn't really make sense - you can't tell if a FLOAT3 means normal
or POSITION, or something else the app just made up and the shader knows
how to interpret.
>
>> > Keep in mind though
>> > that the d3d8 path was added specifically to fix the problem you
>> > described earlier :-).
>> I remember a bunch of dead code that looked like it was trying to write
>> to arrayUsageMap, but wasn't actually writing anything :)
> Maybe you're talking about a different piece of code.
Not really, just another piece of the same code that I removed earlier.
> What I was
> talking about was
> http://source.winehq.org/source/dlls/wined3d/drawprim.c#L404
That looks like this in my tree:
if (useVertexShaderFunction && (data || streamVBO) ) {
IWineD3DVertexShader* vshader = This->stateBlock->vertexShader;
unsigned int idx;
BOOL stride_used = vshader_get_input(vshader,
element->Usage, element->UsageIndex, &idx);
if (stride_used) {
TRACE("Loaded shader array %u [usage=%s, usage_idx=%u, "
"stream=%u, offset=%u, stride=%lu, VBO=%u]\n", idx,
debug_d3ddeclusage(element->Usage),
element->UsageIndex, element->Stream,
element->Offset, stride, streamVBO);
strided[idx].lpData = data;
strided[idx].dwType = element->Type;
strided[idx].dwStride = stride;
strided[idx].VBO = streamVBO;
strided[idx].usage = element->Usage;
strided[idx].usage_index = element->UsageIndex;
}
}
else {
TRACE("Loaded fixed function array %u [usage=%s, usage_idx=%u, "
"stream=%u, offset=%u, stride=%lu, VBO=%u]\n", fixed_idx,
debug_d3ddeclusage(element->Usage), element->UsageIndex,
element->Stream, element->Offset, stride, streamVBO);
strided[fixed_idx].lpData = data;
strided[fixed_idx].dwType = element->Type;
strided[fixed_idx].dwStride = stride;
strided[fixed_idx].VBO = streamVBO;
strided[fixed_idx].usage = element->Usage;
strided[fixed_idx].usage_index = element->UsageIndex;
fixed_idx++;
}
then loadNumberedArrays is:
for (i = 0; i < nstreams; i++) {
if (strided[i].lpData == NULL)
continue;
TRACE_(d3d_shader)("Loading array %u [usage=%s, usage_idx=%u,
VBO=%u]\n",
i, debug_d3ddeclusage(strided[i].usage),
strided[i].usage_index, strided[i].VBO);
if(curVBO != strided[i].VBO) {
GL_EXTCALL(glBindBufferARB(GL_ARRAY_BUFFER_ARB,
strided[i].VBO));
checkGLcall("glBindBufferARB");
curVBO = strided[i].VBO;
}
GL_EXTCALL(glVertexAttribPointerARB(i,
WINED3D_ATR_SIZE(strided[i].dwType),
WINED3D_ATR_GLTYPE(strided[i].dwType),
WINED3D_ATR_NORMALIZED(strided[i].dwType),
strided[i].dwStride,
strided[i].lpData));
GL_EXTCALL(glEnableVertexAttribArrayARB(i));
}
More information about the wine-devel
mailing list