July 2006 - Wine-Devel - list.winehq.org

Re: Semantics, shaders, and fixups

by H. Verbeet

On 03/07/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > >>> and I just made it work today, > >>> by storing a fake semantic for d3d8 shaders. > By the way, I am still keeping that fake semantic around - it is useful > - it allows me to have a single code path for loading arrays, instead of > the two we currently have, which is a mess.. Well, it is wrong. However, as long as we've got some way of detecting that it's a fake, I suppose it might still work. Keep in mind though that the d3d8 path was added specifically to fix the problem you described earlier :-).

July 3, 2006

Re: Semantics, shaders, and fixups

by H. Verbeet

On 03/07/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > So, are the names in the D3DVSD_REGISTER enumeration meaningless? >From the shader's point of view, yes. > Why is D3DVSDE_POSITION called that way? IIRC the names somehow correspond to the way inputs are mapped for fixed function, but I'm not too sure on the details. > If that works for d3d8, why doesn't it work for d3d9? > D3D9 have types as well on each semantic, and D3DCOLOR is one of the types. It probably would. At the time, the arrayUsageMap was more convenient to use though. > I see - I must have misunderstood that we need the fixup to be applied > because of the way OpenGL expects the color data after the shader is > executed. It's because of the way OpenGL (or rather D3D :-)) expects the data on input to the vertex processing stage. Because vertex shaders replace the fixed function vertex processing stage, we can change the way it expects the data rather than fixing up the data itself. > You're saying that's just the standard way to assign a > D3DCOLOR to x,y,z,w components... Yes. Also see MSDN for D3DVSDT_D3DCOLOR vs D3DVSDT_UBYTE4.

July 3, 2006

RE: Win64 patch 1/5 (configure)

by Ge van Geldorp

> From: Alexandre Julliard [mailto:julliard(a)winehq.org] > > > Changelog: > > Ge van Geldorp <ge(a)gse.nl> > > - Allow relocation on x86_64 > > Is that really needed for Win64? And if so, shouldn't it use > a more appropriate address? The standard load address for 64-bit PE executables is the same as for 32-bit, 0x400000. This is also the standard load address for 64-bit ELF executables. If the Wine loader is not relocated, it won't be able to load the majority of PE executables. Ofcourse, there's no problem with 64-bit Winelib executables. As to the more appropriate address, I'm not sure. I just wanted to get it out of the way. I suppose it could be moved to somewhere around or above 0x7bf0000000000000. Ge van Geldorp.

July 3, 2006

Re: Semantics, shaders, and fixups

by Ivan Gyurdiev

>>> and I just made it work today, >>> by storing a fake semantic for d3d8 shaders. By the way, I am still keeping that fake semantic around - it is useful - it allows me to have a single code path for loading arrays, instead of the two we currently have, which is a mess..

July 3, 2006

Re: Semantics, shaders, and fixups

by Ivan Gyurdiev

H. Verbeet wrote: > On 03/07/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: >> Demo #2: Many Per Pixel Lights, >> http://www.zanir.szm.sk/dx/017_Many_Per_Pixel_Lights.zip >> This is a d3d8 demo. The shader inputs are not marked with a semantic - >> the declaration data is mapped 1:1 to the shader inputs, so a specific >> register number is designated as the D3DVSDE_DIFFUSE register. Now, >> consider that we use the semantic to implement shader fixup - flipping >> red and blue on color inputs. Previously this fixup did not work at all >> on d3d8 shaders (as far as I can tell), > And it shouldn't. As you said, d3d8 shaders don't have a usage / > semantic defined per register. So, are the names in the D3DVSD_REGISTER enumeration meaningless? Why is D3DVSDE_POSITION called that way? >> and I just made it work today, >> by storing a fake semantic for d3d8 shaders. > You can't do that. In d3d8 there's no way to figure out how a register > is going to be used. For d3d8 the only way to determine if we need > fixups is to look at the register's data type. That's exactly what the > patch / hack I sent you a while ago did. If that works for d3d8, why doesn't it work for d3d9? D3D9 have types as well on each semantic, and D3DCOLOR is one of the types. >> Also, I don't understand why we're applying fixups on shader input >> either. Can someone explain why this fixup is needed exactly? If we need >> to flip red and blue because the format is backwards, shouldn't this be >> done at the end of the pipeline, at the point of interpretation by GL. >> Flipping things at an intermediate point can affect all kinds of >> calculations in the shader. At the end of the pipeline we can also >> reliably tell what's to be interpreted as color data, instead of >> following semantic hints. > It's not an intermediate point, but rather how the data is visible > inside the d3d shader. We don't look at the usage / semantic of the > register as much as we look at the data type that usage implies (for > d3d9 that is, d3d8 has an explicit data types and no usage). For the > "color" datatype, the blue component of the color is the first > component, x. We actually need to do it on input *because* of the > calculations you talk about. Consider this: How would the data look if > we did the fixups on the input data before sending it to the shader? I see - I must have misunderstood that we need the fixup to be applied because of the way OpenGL expects the color data after the shader is executed. You're saying that's just the standard way to assign a D3DCOLOR to x,y,z,w components...

July 3, 2006

Re: Semantics, shaders, and fixups

by H. Verbeet

On 03/07/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > Demo #2: Many Per Pixel Lights, > http://www.zanir.szm.sk/dx/017_Many_Per_Pixel_Lights.zip > This is a d3d8 demo. The shader inputs are not marked with a semantic - > the declaration data is mapped 1:1 to the shader inputs, so a specific > register number is designated as the D3DVSDE_DIFFUSE register. Now, > consider that we use the semantic to implement shader fixup - flipping > red and blue on color inputs. Previously this fixup did not work at all > on d3d8 shaders (as far as I can tell), And it shouldn't. As you said, d3d8 shaders don't have a usage / semantic defined per register. > and I just made it work today, > by storing a fake semantic for d3d8 shaders. You can't do that. In d3d8 there's no way to figure out how a register is going to be used. For d3d8 the only way to determine if we need fixups is to look at the register's data type. That's exactly what the patch / hack I sent you a while ago did. > Therefore, how can we rely on a semantic tag for shader fixups? Seems we > can't do that. For d3d8 we can't, but for d3d8 the register shouldn't *have* that tag in the first place, since there's no way we can make up a correct one. The dolphin demo in the d3d8 sdk is another demo that breaks if you do this. (It stores texture coordinates in register 6, which happens to correspond to D3DVSDE_SPECULAR). > Also, I don't understand why we're applying fixups on shader input > either. Can someone explain why this fixup is needed exactly? If we need > to flip red and blue because the format is backwards, shouldn't this be > done at the end of the pipeline, at the point of interpretation by GL. > Flipping things at an intermediate point can affect all kinds of > calculations in the shader. At the end of the pipeline we can also > reliably tell what's to be interpreted as color data, instead of > following semantic hints. It's not an intermediate point, but rather how the data is visible inside the d3d shader. We don't look at the usage / semantic of the register as much as we look at the data type that usage implies (for d3d9 that is, d3d8 has an explicit data types and no usage). For the "color" datatype, the blue component of the color is the first component, x. We actually need to do it on input *because* of the calculations you talk about. Consider this: How would the data look if we did the fixups on the input data before sending it to the shader?

July 3, 2006

Re: [setupapi] fix return values and GUID string in SetupDiOpenClassRegKeyExW

by Damjan Jovanovic

--- Joris Huizer <jorishuizer(a)planet.nl> wrote: > Damjan Jovanovic wrote: > > + guidStringWithBraces[0] = (WCHAR) '{'; > > + CopyMemory(&guidStringWithBraces[1], > lpGuidString, > > + (MAX_GUID_STRING_LEN - 3)*sizeof(WCHAR)); > > + guidStringWithBraces[MAX_GUID_STRING_LEN - 2] > = (WCHAR) '}'; > > + guidStringWithBraces[MAX_GUID_STRING_LEN - 1] > = 0; > > + RpcStringFreeW(&lpGuidString); > > Just wondering, shouldn't that be something like > > guidStringWithBraces[0] = (WCHAR) '{'; > CopyMemory(&guidStringWithBraces[1], > lpGuidString, > (MAX_GUID_STRING_LEN - 3)*sizeof(WCHAR)); > guidStringWithBraces[1 + strlenW(lpGuidString)] > = (WCHAR) '}'; > guidStringWithBraces[2 + strlenW(lpGuidString)] > = 0; > RpcStringFreeW(&lpGuidString); > > HTH, > > Joris It works as it is, and all GUID strings are the same length, so MAX_GUID_STRING_LEN is faster since it evaluates at compile time. Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

July 3, 2006

Re: Slow EULA display patch

by Alexandre Julliard

Daniel Steven Hipschman <dsh(a)linux.ucla.edu> writes: > ChangeLog: > * Sped up GetTextExtentExPointW by adding a new freetype GDI font function > WineEngGetTextExtentExPoint and a new DC function pGetTextExtentExPoint. Looks good, but you should remove the non-Ex entry points in freetype.c and the DC table, there's no reason to have both. -- Alexandre Julliard julliard(a)winehq.org

July 3, 2006

Re: Win64 patch 1/5 (configure)

by Alexandre Julliard

Ge van Geldorp <ge(a)gse.nl> writes: > Changelog: > Ge van Geldorp <ge(a)gse.nl> > - Allow relocation on x86_64 Is that really needed for Win64? And if so, shouldn't it use a more appropriate address? -- Alexandre Julliard julliard(a)winehq.org

July 3, 2006

Re: mapi32: Write-strings warnings fix

by Alexandre Julliard

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > @@ -113,8 +114,8 @@ > } > if (message->nFileCount) FIXME("Ignoring attachments\n"); > > - subject = message->lpszSubject ? message->lpszSubject : ""; > - body = message->lpszNoteText ? message->lpszNoteText : ""; > + subject = message->lpszSubject ? message->lpszSubject : empty; > + body = message->lpszNoteText ? message->lpszNoteText : empty; These are not part of a Win32 API structure, there's no reason they can't be made const. -- Alexandre Julliard julliard(a)winehq.org

July 3, 2006