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

Semantics, shaders, and fixups

by Ivan Gyurdiev

Hi, Here's another problem with shaders. Vertex shader input is marked up with tags that hint at the data usage - semantics. For the fixed pipeline, those tags must be 100% correct, because they tell the pipeline how to interpret the data - is that the position stream, or the color stream, or the texcoord stream. For shaders, however, I think this is not the case. Since the app has control of the shader, it doesn't need to give meanings to the different semantics. I've looked at two demos, which demonstrate various problems. Demo #1: Instancing: http://www.humus.ca/index.php?page=3D&ID=52 This demo has hlsl shaders, which make use of the TEXCOORD8 semantic. This is an invalid semantic, according to the way we map things, since only 0-7 texcoords are supported. Furthermore, comments make it clear that this is not texture data. It would seem that the semantic is just meant to relay the data to the vertex shader input that is marked dcl_texcoord8. This means that we need to support all semantic names and indices 0-15 as possible labels for shader input data. MSDN even mentions that texcoord can be used for user-defined data. This presentation: http://www.ati.com/developer/gdc/D3DTutorial1_Shaders.pdf , has examples which make use of position > 0, normal > 0, etc, which are all invalid on the fixed function pipeline. I am currently working on a very large patch, which will restructure strided data to address this problem, but that's not all. 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 I just made it work today, by storing a fake semantic for d3d8 shaders. The result is that in the demo above, everything turned green, and very wrong. Why? Looking at the demo it seems that it loads registers that contain user-defined data in all the declaration inputs, without paying any attention to the "meaning" of that register, since it controls the shader. As a result, we are flipping random data, that could be important, and not red and blue. In this particular case, it's a relative address token, which means that's absolutely critical that it gets the right value - that's why everything breaks. Therefore, how can we rely on a semantic tag for shader fixups? Seems we can't do that. 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. Any thoughts?

July 3, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by James Hawkins

On 7/3/06, Chris <chris.kcat(a)gmail.com> wrote: > On Monday 03 July 2006 01:46, you wrote: > > What's wrong with wineconsole? > > wineconsole by itself doesn't seem to do anything, and using --help didn't > work (and there seems to be no man page). Running 'wineconsole wcmd.exe' > started a command prompt in the activating terminal just like wcmd.exe > normally does, except the console output is forced to 80x25 output with no > back buffer (Windows' cmd.exe can have a configurable-sized back-buffer and > can be resized), and the error/fixme/trace's from the apps run from it are > displayed improperly (I suppose because they end lines with \n, and in > wineconsole's console it needs \r\n). > try 'wineconsole --backend=user wcmd.exe'. Works great for me. -- James Hawkins

July 3, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by Chris

On Monday 03 July 2006 01:46, you wrote: > What's wrong with wineconsole? wineconsole by itself doesn't seem to do anything, and using --help didn't work (and there seems to be no man page). Running 'wineconsole wcmd.exe' started a command prompt in the activating terminal just like wcmd.exe normally does, except the console output is forced to 80x25 output with no back buffer (Windows' cmd.exe can have a configurable-sized back-buffer and can be resized), and the error/fixme/trace's from the apps run from it are displayed improperly (I suppose because they end lines with \n, and in wineconsole's console it needs \r\n).

July 3, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by James Hawkins

On 7/3/06, Chris <chris.kcat(a)gmail.com> wrote: > On Sunday 02 July 2006 23:58, you wrote: > > The case I care about most is: > > in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch > > file. > > > > We need to be able to support both cases. > > How about leaving wcmd.exe alone (or renaming it to winecmd.exe), and wait on > making cmd.exe until a replacement that behaves like Windows' cmd.exe, then? > You can have both that way. I'm mostly concerned about apps and/or people > that expect cmd.exe to behave like Windows' version, when Wine's wcmd.exe > doesn't. > What's wrong with wineconsole? A separate command prompt is opened that behaves like cmd.exe. -- James Hawkins

July 3, 2006

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

by Joris Huizer

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

July 3, 2006

Re: RESEND: enhmetafile: Read and write support for little-endian EMFs on big-endian machines

by Phil Krylov

Hi, Is anything wrong with that patch? On 25/06/06, Phil Krylov <phil(a)newstar.rinet.ru> wrote: > Hi, > > This version has no ugly macros and adds read support. Diffed against current > CVS. > > ChangeLog: > > enhmetafile: Read and write support for little-endian EMFs on big-endian > machines. -- Ph.

July 3, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by Chris

On Sunday 02 July 2006 23:58, you wrote: > The case I care about most is: > in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch > file. > > We need to be able to support both cases. How about leaving wcmd.exe alone (or renaming it to winecmd.exe), and wait on making cmd.exe until a replacement that behaves like Windows' cmd.exe, then? You can have both that way. I'm mostly concerned about apps and/or people that expect cmd.exe to behave like Windows' version, when Wine's wcmd.exe doesn't.

July 3, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by Dan Kegel

>>> [wcmd needs to start a window.] >> Have you ever seen this be a problem in the real world? > >Yes. Start Progman, or some ther "shell" application, without an xterm (eg. >through your WM or by running wine progman.exe &), then attempt to execute >wcmd.exe (a standard operation I'd think, if you want to have a Windows shell >running and subsequently want to get a Windows command line). You lose the >ability to control wcmd, and can't kill it without manually running kill or >killall on the process. The case I care about most is: in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch file. We need to be able to support both cases. However, I'm not sure we need to solve the case you are discussing any time soon. Users who want to do what you're describing can run 'wineconsole'. Eventually, yes, it'd be nice to teach our cmd how to do that without nuking the use case I'm most worried about. - Dan

July 3, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by Chris

On Sunday 02 July 2006 16:31, you wrote: > Have you ever seen this be a problem in the real world? Yes. Start Progman, or some ther "shell" application, without an xterm (eg. through your WM or by running wine progman.exe &), then attempt to execute wcmd.exe (a standard operation I'd think, if you want to have a Windows shell running and subsequently want to get a Windows command line). You lose the ability to control wcmd, and can't kill it without manually running kill or killall on the process. > >To be "ready", wouldn't it need to open up its own terminal window for > > input and output in Wine's desktop space (eg. the virtual desktop if it's > > in use, or the standard desktop)? > > No. That would destroy its usefulness in background applications. Wouldn't not doing it destroy its usefulness? If wcmd is supposed to act like Windows' cmd, then it should act like Windows' cmd, eg. opening its own console window in Wine's desktop space and running there. If it doesn't, it would lead to compatibility issues for programs that try to use a cmd.exe window itself since the behavior is different.

July 3, 2006

Re: Slow EULA display patch

by Dan Hipschman

On Sun, Jul 02, 2006 at 04:35:11PM -0700, Dan Kegel wrote: > FWIW, Dan H also explored a change to make a riched "run" struct be > refcounted; that gave a 4x speedup. Then he switched to using > git bisect to find the cause of the regression, and shelved the > refcounting patch. That wasn't the real reason I scratched the refcount idea. To make it work correctly, I had to add copy-on-write and once I did this the performance dropped again. However, the problem I was trying to solve was that ME_SplitRunSimple calls ME_VSplitString, which makes a copy of a large suffix of its string argument. The process then occurs again iteratively on the suffix, so a lot of copys are being made. Instead of this, if we only copied the part of the suffix we need, and then use the same base string in every iteration, we could eliminate another n-squared algorithm. The 4x speedup might have been, in part, a side effect of something that got broken by the incorrectly reference counted strings. Sorry I didn't mention this before.

July 3, 2006