January 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 3/5] wined3d: Prune invalid states from the state table.

by Stefan Dösinger

On Friday 29 January 2010 00:55:19 Henri Verbeet wrote: > Almost. The texture_stages limit is supposed to indicate the number of > texture stages the GL implementation can support, I don't think > there's a reason to change that. What needs to change is that we > assign its value based on the fragment pipeline caps instead of based > on the GL extensions. Texture stages are a direct3d concept. On the GL side we have MAX_GENERAL_COMBINERS_NV, 8(atifs extension hardcoded), MAX_TEXTURES(ffp) or the arbfp shader instruction limit. How those translate into the d3d limit is an implementation detail of the fragment pipeline and none of the GL extension loading code's business. Plus, we need the raw GL limit intact as well. Let's take for example gl max_textures vs gl max_samplers vs d3d MaxSimultaneousTextures. Assume a geforce 7 card. max_textures = 4, arbfs pipeline. In this situation this code will result in a GL error: glActiveTexture(GL_TEXTURE5); glBindTexture(GL_TEXTURE_2D, tex); glEnable(GL_TEXTURE_2D); However, on the d3d side this is perfectly valid and working OK: SetPixelShader(NULL); SetTexture(0, tex); SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_PREVIOUS); SetTexture(1, tex); SetTextureStageState(1, D3DTSS_COLOROP, D3DTOP_PREVIOUS); SetTexture(2, tex); SetTextureStageState(2, D3DTSS_COLOROP, D3DTOP_PREVIOUS); SetTexture(3, tex); SetTextureStageState(3, D3DTSS_COLOROP, D3DTOP_PREVIOUS); SetTexture(4, tex); SetTextureStageState(4, D3DTSS_COLOROP, D3DTOP_PREVIOUS); SetTexture(5, tex); SetTextureStageState(5, D3DTSS_COLOROP, D3DTOP_PREVIOUS); SetTextureStageState(6, D3DTSS_COLOROP, D3DTOP_DISABLE); So (gl)max_textures=4, (gl)max_samplers=16, (d3d)MaxSimultaneousTextures=8 Furthermore we can't store MaxSimultaneousTextures in the GL limits, as it can depend on the device creation parameters. E.g. the app creates the device with D3DCREATE_SOFTWARE_VERTEXPROCESSING. This way the vertex pipeline's limits don't have any relation to the GL vertex limits, and we don't know what the app will do when we initialize the adapter. > > Please use the number of texture blend stages reported from the fragment > > pipeline rather than gl_limits.texture_stages. texture_stages only works > > with the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok > > by chance on most GL cards). > > If those aren't the same, the code initializing the texture_stages > limit is broken, not the code using it. Your code is manipulating the input into the pipeline code, it is talking in D3D terms, so the D3D limits apply, not the GL limits. > > There's a deeper issue with how we manage texture limits, because > > currently the extension loading code picks limits.texture_stages, already > > anticipating which pipeline we'll choose later. We should handle this in > > the way shader > > True, but that code was there before the concept of a fragment > pipeline was introduced in wined3d. I introduced the separation of d3d fragment pipeline limits from gl fragment pipeline limits when I introduced the different fragment piplines - see the pipeline.get_caps() function. Later on I did the same for shader limits. It is far from perfect though, on the vertex side we're still mixing them up. I can't find the original patch in git since it was a long time ago in spring 08, here are a few following patches though: 9a6bc683e11bf508a37769640d56f201462b935a 462ddaa25404cd1a07135f5d7acdd2e298d7dfad

Jan. 29, 2010

Re: Loader, mapping and sharing issues with main exe

by Alexandre Julliard

Jason Edmeades <jason.edmeades(a)googlemail.com> writes: > What I dont understand is why the NtClose for the handle does not > remove it from the 'open' list - I think from my reading of the > fd_destroy code it will put it onto the closed list if there are other > references to the same inode, although thats where my debugging will > head next. Loading a dll keeps a reference to the file object, because it needs to be returned in debug events. Probably it would be possible to reference the mapping object instead and reopen the file from it. -- Alexandre Julliard julliard(a)winehq.org

Jan. 29, 2010

Re: [d3d10core/tests] Fix a test failure when no adapters are present

by Paul Vriens

On 01/28/2010 05:48 PM, Henri Verbeet wrote: > Paul Vriens wrote: >> Doesn't the DXGI_ERROR_NOT_FOUND return value tell us there is no D3D10 >> capable adapter (instead of any adapter)? >> > Possibly, but my understanding was that on Vista and higher DXGI is > shared across pretty much the entire graphics subsystem. > > Henri I did some tests with VMware Workstation 7.0 and Vista Ultimate but wasn't able to provoke this particular error. I tried with an installed SDK (to get d3d10ref.dll) and with and without the accelerated option. Maybe it's when using the old VMware drivers in the guest on a host with a higher version of VMware? I did see some exclamation marks on the VMware tools icon in the screenshot on winetestbot (which could indicate that a newer version of the tools/drivers is available). (Can't say anything about VirtualBox) -- Cheers, Paul.

Jan. 29, 2010

Re: [2/5] d3d9: Test invalid buffer lock parameters

by Henri Verbeet

On 28 January 2010 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Copyright (C) 2010 Stefan Dösinger(For CodeWeavers) Please use UTF-8 like the other source files. (I'd also suggest a space and a lowercase 'F').

Jan. 29, 2010

Re: relay log problem

by Ken Thomases

On Jan 28, 2010, at 5:21 PM, Michael Stefaniuc wrote: > On 01/28/2010 10:59 PM, Henri Verbeet wrote: >> On 28 January 2010 22:39, Stefan Leichter<Stefan.Leichter(a)camline.com> wrote: >>> Is this a know problem? Is a work around available? >>> >> Yeah, that's a known problem. As a workaround you can use ">>" >> (append) instead of ">" to redirect to the file. You'll still need the >> "2>&1" to redirect stderr to stdout, of course. > That won't workaround the problem. The problem is that there are multiple threads/programs that write at the same time to stdout/stderr. > I have seen it with fixme/err/warn messages too; even with crash dumps. Using >> in the shell causes the stdout file descriptor to be opened with O_APPEND. Using 2>&1 makes stderr dup the file descriptor, so it gets the same flag. With O_APPEND, the kernel ensures that all writes append to the file. Multiple threads or programs using an O_APPEND descriptor can't overwrite each other. If the code uses multiple writes for a single line, then those multiple writes can be interleaved, but can't overwrite. And, for the most part, Wine's debug logging uses single writes so it won't even interleave. Regards, Ken

Jan. 29, 2010

Re: Student Interested in Google Summer of Code 2010

by Gerald Pfeifer

On Wed, 27 Jan 2010, Tom Wickline wrote: > The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is > installed from ports. > > # flex --version > flex version 2.5.4 > > The version check passes on Linux and OpenSolaris but FreeBSD has a > harder time with it. > > Gerald has a workaround for this.. Shall I call it a bug? since a > newer version is actually installed but the version check fails. It's not a bug in Wine or Wine's configure scripts. What happens on your system, or any "standard" FreeBSD system with the flex package installed is that the default path has /usr/bin before /usr/local/bin, so /usr/bin/flex which is 2.5.4 (as per your example) is found before, or should I say: instead, /usr/local/bin/flex which is the good one. > But if you download the Wine source and try to compile your out of > luck unless you remove the version check from configure, which is what > Ive done as a temporary fix. Real fixes are setting your path to take /usr/local/bin before /usr/bin or probably better setting FLEX=/usr/local/bin/flex in your environment which tells configure and other tools to use that version of flex instead of the one in the base system. I would not recommend Wine trying to second guess which of several versions of flex on a system to use as opposed to following the common standard of use the first instance in the search path. I hope this makes sense? Gerald -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

Jan. 29, 2010

Re: relay log problem

by Henri Verbeet

On 29 January 2010 00:21, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > On 01/28/2010 10:59 PM, Henri Verbeet wrote: >> >> On 28 January 2010 22:39, Stefan Leichter<Stefan.Leichter(a)camline.com> >> wrote: >>> >>> Is this a know problem? Is a work around available? >>> >> Yeah, that's a known problem. As a workaround you can use ">>" >> (append) instead of ">" to redirect to the file. You'll still need the >> "2>&1" to redirect stderr to stdout, of course. > > That won't workaround the problem. > Seems to work for me.

Jan. 29, 2010

Re: Quick multiple-patch submission question

by Henri Verbeet

On 29 January 2010 00:28, Juan Lang <juan.lang(a)gmail.com> wrote: >> When submitting multiple patches that apply to the same component but >> each patch is unrelated (ie. each one fixes a different issue), is it >> still appropriate to label the patches with the [PATCH X/Y] notation? >> In the case I have at hand the patches are even for different files of >> the same component, so the apply order completely doesn't matter. > > In this case it's not needed. I don't bother with the patch x/y > notation, others do.. either way is fine. Yeah. Note that git format-patch will create a series unless you tell it not to though, so at least in my case it's mostly a matter of not bothering with removing it. (And I guess on some level also confidence that the patches I'm sending are correct.)

Jan. 29, 2010

Re: [PATCH 3/5] wined3d: Prune invalid states from the state table.

by Henri Verbeet

On 29 January 2010 00:27, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Please use the number of texture blend stages reported from the fragment > pipeline rather than gl_limits.texture_stages. texture_stages only works with > the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok by chance > on most GL cards). > If those aren't the same, the code initializing the texture_stages limit is broken, not the code using it. > There's a deeper issue with how we manage texture limits, because currently > the extension loading code picks limits.texture_stages, already anticipating > which pipeline we'll choose later. We should handle this in the way shader True, but that code was there before the concept of a fragment pipeline was introduced in wined3d. > constants are handled: Rename limits.texture_stages to > limits.max_nv_general_combiners, make only the nvrc and nvts pipelines read > this extension specific value, and use the pipeline reported d3d texture blend > stages in fragment pipeline independent code. We're also (still) mixing up > blend stages with fixed function vertex coordinates. > Almost. The texture_stages limit is supposed to indicate the number of texture stages the GL implementation can support, I don't think there's a reason to change that. What needs to change is that we assign its value based on the fragment pipeline caps instead of based on the GL extensions.

Jan. 28, 2010

Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match

by Charles Davis

srrose wrote: > What does this mean? Iim using a USB 2.0 Flash Drive and a LAUNCHU3.EXE > file says it is linked to a missing export. It then says > KERNEL32.DLL:GetVolumeMountPointW. > Can you help me? Thank you!! Yes... but you're on the wrong list. User questions need to go to wine-users. And another thing: don't hijack other people's threads. That's considered bad netiquette. By the way, when an export is missing from a DLL, that's a bug. File one at http://bugs.winehq.org . (Be sure to follow the guidelines!) Now if you're interested in fixing that bug... well, that's another story entirely. We welcome new developers; we really need the help. Chip

Jan. 28, 2010