Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
On 24 June 2013 16:44, Matteo Bruni wrote: > @@ -1673,6 +1673,8 @@ struct texture_stage_op > unsignedaarg2 : 8; > unsignedaarg0 : 8; > > +DWORD constant; > + > struct color_fixup_desc color_fixup; > unsignedtex_type : 3; > unsigneddst : 1; > > You don't need this if you use uniforms. > Also adding a test would be nice probably. > Yeah, that's the main issue. We don't want a shader for every possible set of per-stage constant values. The one you missed is that if we implement this, we should also set the appropriate caps bit. The most obvious issue is of course the subject line. Sure, typos happen, but it's just plain sloppy. At least try to pretend you put some effort into making sure the patch is as good as it can be before submitting it.
Re: [PATCH] advapi32: RegDeleteKey tests
George Stephanos wrote: > +res = RegOpenKeyExA( hkey, "subkey1", 0, KEY_READ, &hkeysub1 ); > +ok(res != ERROR_SUCCESS, "test key found in user's classes: %d\n", res); ... > +res = RegOpenKeyExA( hklm, "subkey1", 0, KEY_READ, &hklmsub1 ); > +ok(res != ERROR_SUCCESS, "test key found in hklm: %d\n", res); Testing for res != ERROR_SUCCESS is not very useful, please check for a particular error code. Also please close successfully opened handles. -- Dmitry.
Re: d3dx9: Implement adjacency in D3DXCreateSphere
Hello
Thank you for the feedback, Rico.
But, there is a problem with this patch. Native d3dx9 does not call
GenerateAdjacency. It hardcodes the adjacency. That is proved by the case
D3DXCreateSpehere(device, 0.0f, 10,10,adjacency) where native gives different
result using GenerateAdjacency or not. I need thinking more how to hardcode
adjacency.
The side effect is to show there is a bug in our built-in GenerateAdjacency
Nozomi
De : Rico Schüller
À : Nozomi Kodama
Cc : wine-devel@winehq.org
Envoyé le : Vendredi 21 juin 2013 23h24
Objet : Re: d3dx9: Implement adjacency in D3DXCreateSphere
On 20.06.2013 21:25, Nozomi Kodama wrote:
> + if (adjacency)
> + {
> + DWORD *buffer, size;
> + ID3DXBuffer *temp;
> +
> + size = 3 * sphere->lpVtbl->GetNumFaces(sphere) * sizeof(DWORD);
> + hr = D3DXCreateBuffer(size, &temp);
> + if (hr != D3D_OK)
> + return hr;
> +
> + buffer = (DWORD *)(ID3DXBuffer_GetBufferPointer(temp));
Are the outer parentheses needed? Is the cast needed?
> + hr = sphere->lpVtbl->GenerateAdjacency(sphere, -0.01f, buffer);
> + if (hr != D3D_OK)
> + return hr;
This may leak the temp ID3DXBuffer in the error case.
Cheers
Rico
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
I'm not Henri but I can mention a number of issues (which might or
might not match with Henri's).
+for (stage = 0; stage < MAX_TEXTURES && settings->op[stage].cop
!= WINED3D_TOP_DISABLE; ++stage)
You probably want to generate this code only for texture stages
actually using constants.
Yes. I was thinking about that first but chose the easiest way. Will fix.
+{
+float constant[4];
+
+constant[0] = ((settings->op[stage].constant >> 16) & 0xff) / 255.0f;
+constant[1] = ((settings->op[stage].constant >> 8) & 0xff) / 255.0f;
+constant[2] = ( settings->op[stage].constant& 0xff) / 255.0f;
+constant[3] = ((settings->op[stage].constant >> 24) & 0xff) / 255.0f;
No need to open code it, the macro D3DCOLORTOGLFLOAT4 does just that.
Ok. I will sue it.
+
+shader_addline(buffer, "const vec4 const%d = ", stage);
+shader_glsl_append_imm_vec4(
buffer, constant);
+shader_addline(buffer, ";\n");
I assume it would be better to make these proper uniforms and update
their value in shader_glsl_load_constants() instead.
I was wondering when the shader was regenerated and how changing
constant would affect it.
Indeed this seems more correct.
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c
index 5b7fb3c..083a0d7 100644
--- a/dlls/wined3d/utils.c
+++ b/dlls/wined3d/utils.c
@@ -3312,6 +3312,8 @@ void gen_ffp_frag_op(const struct
wined3d_context *context, const struct wined3d
settings->op[i].aarg1 = aarg1;
settings->op[i].aarg2 = aarg2;
+settings->op[i].constant = state->texture_states[i][
WINED3D_TSS_CONSTANT];
+
if (state->texture_states[i][WINED3D_TSS_RESULT_ARG] ==
WINED3DTA_TEMP)
settings->op[i].dst = tempreg;
else
diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
index dca0d61..c1d6c91 100644
--- a/dlls/wined3d/wined3d_private.h
+++ b/dlls/wined3d/wined3d_private.h
@@ -1673,6 +1673,8 @@ struct texture_stage_op
unsignedaarg2 : 8;
unsignedaarg0 : 8;
+DWORD constant;
+
struct color_fixup_desc color_fixup;
unsignedtex_type : 3;
unsigneddst : 1;
You don't need this if you use uniforms.
Yes indeed.
Also adding a test would be nice probably.
I will try to do so if it's not too hard altough I guess there're
probably some template I can reuse in the existing tests.
That said, maybe Henri already has a patch for it.
If Henri or Stefan have already a patch for it or plan to fix it once
Wine 1.6 is released I can drop my patch otherwise I don't mind fix it
to do things the right way.
Thanks for you feedback
Christian
Re: msvcr90/tests: skip tests of function ?_name_internal_method if it is not present
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26093 Your paranoid android. === WXPX64 (32 bit msvcr90) === No test summary line found
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
2013/6/24 Christian Costa :
> Le 24/06/2013 09:24, Henri Verbeet a écrit :
>
>> On 23 June 2013 21:57, Christian Costa wrote:
>>>
>>> When D3DTA_CONSTANT is use in a texture stage, the generated shader uses
>>> variables that are not defined making thus the compilation to fail.
>>> This patch declare these variables with the value from the related
>>> texture stage state D3D_TSS_CONSTANT.
>>> This fixes the text display in Spin Tires demo.
>>
>> This patch has several issues. Even without those, it should probably
>> be deferred anyway.
>>
>>
>>
> Even deferred, can you elaborate a bit so I can fix them. Unless you have
> already something.
>
>
I'm not Henri but I can mention a number of issues (which might or
might not match with Henri's).
+for (stage = 0; stage < MAX_TEXTURES && settings->op[stage].cop
!= WINED3D_TOP_DISABLE; ++stage)
You probably want to generate this code only for texture stages
actually using constants.
+{
+float constant[4];
+
+constant[0] = ((settings->op[stage].constant >> 16) & 0xff) / 255.0f;
+constant[1] = ((settings->op[stage].constant >> 8) & 0xff) / 255.0f;
+constant[2] = ( settings->op[stage].constant& 0xff) / 255.0f;
+constant[3] = ((settings->op[stage].constant >> 24) & 0xff) / 255.0f;
No need to open code it, the macro D3DCOLORTOGLFLOAT4 does just that.
+
+shader_addline(buffer, "const vec4 const%d = ", stage);
+shader_glsl_append_imm_vec4(
buffer, constant);
+shader_addline(buffer, ";\n");
I assume it would be better to make these proper uniforms and update
their value in shader_glsl_load_constants() instead.
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c
index 5b7fb3c..083a0d7 100644
--- a/dlls/wined3d/utils.c
+++ b/dlls/wined3d/utils.c
@@ -3312,6 +3312,8 @@ void gen_ffp_frag_op(const struct
wined3d_context *context, const struct wined3d
settings->op[i].aarg1 = aarg1;
settings->op[i].aarg2 = aarg2;
+settings->op[i].constant = state->texture_states[i][
WINED3D_TSS_CONSTANT];
+
if (state->texture_states[i][WINED3D_TSS_RESULT_ARG] == WINED3DTA_TEMP)
settings->op[i].dst = tempreg;
else
diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
index dca0d61..c1d6c91 100644
--- a/dlls/wined3d/wined3d_private.h
+++ b/dlls/wined3d/wined3d_private.h
@@ -1673,6 +1673,8 @@ struct texture_stage_op
unsignedaarg2 : 8;
unsignedaarg0 : 8;
+DWORD constant;
+
struct color_fixup_desc color_fixup;
unsignedtex_type : 3;
unsigneddst : 1;
You don't need this if you use uniforms.
Also adding a test would be nice probably.
That said, maybe Henri already has a patch for it.
Re: ws2_32: Fix interface-bound filter to accept locally generated targeted packets.
On Mon, Jun 24, 2013 at 2:33 AM, Jonas Maebe wrote: > ... > The added "struct sock_filter ip_memaddr" field doesn't seem to be used. It's set in the initialization of "generic_interface_filter", which is used to setup "specific_interface_filter" for individual sockets. Only the field corresponding to the interface index and, now, the destination IP get set explicitly in interface_bind(), everything else is from "generic_interface_filter". Best, Erich
Re: ol32: Make enumx implementation look more like a COM interface.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> > The patch actually removes the casts, the only cast that remains is the >> > cast >> > on the caller's side for the vtable pointer (which is much cleaner IMO >> > since >> > every COM object implements IUnknown), but the implementation itself is >> > cast >> > free, and looks now as an actual COM object. >> >> Not really. An actual COM object would contain a pointer to a vtable for >> the correct interface. IUnknown is not much better than void*. > > enumx doesn't need anything else besides IUnknown interface, having right > inteface definition won't change anything. enumx is not a real interface. The real interfaces are IEnumSTATPROPSETSTG and IEnumSTATPROPSTG, and that's what the vtables should be, in the corresponding objects. The common code can be shared with helper functions. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH]winhttp:session.c fix a bug(return value is null)
On Mon, 2013-06-24 at 19:57 +0900, 中川祥 wrote:
> diff --git a/dlls/winhttp/session.c b/dlls/winhttp/session.c
> index 660eae5..dfe23d4 100644
> --- a/dlls/winhttp/session.c
> +++ b/dlls/winhttp/session.c
> @@ -1316,6 +1316,8 @@ BOOL WINAPI WinHttpDetectAutoProxyConfigUrl( DWORD
> flags, LPWSTR *url )
> {
> static int fixme_shown;
> if (!fixme_shown++) FIXME("discovery via DHCP not supported\n");
> +flags = WINHTTP_AUTO_DETECT_TYPE_DNS_A;
> +ret=TRUE;
> }
> if (flags & WINHTTP_AUTO_DETECT_TYPE_DNS_A)
> {
We shouldn't perform DNS detection if the app didn't ask for it. Do you have an
app
that fails because we return an error here?
Re: ol32: Make enumx implementation look more like a COM interface.
Alexandre Julliard wrote: > > The patch actually removes the casts, the only cast that remains is the cast > > on the caller's side for the vtable pointer (which is much cleaner IMO since > > every COM object implements IUnknown), but the implementation itself is cast > > free, and looks now as an actual COM object. > > Not really. An actual COM object would contain a pointer to a vtable for > the correct interface. IUnknown is not much better than void*. enumx doesn't need anything else besides IUnknown interface, having right inteface definition won't change anything. -- Dmitry.
Re: ol32: Make enumx implementation look more like a COM interface.
Dmitry Timoshkov writes: > The patch actually removes the casts, the only cast that remains is the cast > on the caller's side for the vtable pointer (which is much cleaner IMO since > every COM object implements IUnknown), but the implementation itself is cast > free, and looks now as an actual COM object. Not really. An actual COM object would contain a pointer to a vtable for the correct interface. IUnknown is not much better than void*. -- Alexandre Julliard julli...@winehq.org
Re: ol32: Make enumx implementation look more like a COM interface.
Alexandre Julliard wrote: > > This patch should be quite obvious in its intent: it changes vtable type > > to IUnknown which helps to remove This* to IUnknown* casts in order to > > avoid obvious problems with vtable pointer placement inside of object > > implementation. Basically this is just a clean up patch. > > > > Is there anything else to clear the pending patch state? > > It's just moving the casts around, it doesn't seem like much of an > improvement. The patch actually removes the casts, the only cast that remains is the cast on the caller's side for the vtable pointer (which is much cleaner IMO since every COM object implements IUnknown), but the implementation itself is cast free, and looks now as an actual COM object. I found this 'This' to object cast while investigating a crash in the COM code and decided to fix it since it's clearly wrong and may lead to other problems. -- Dmitry.
Re: ol32: Make enumx implementation look more like a COM interface.
Dmitry Timoshkov writes: > This patch should be quite obvious in its intent: it changes vtable type > to IUnknown which helps to remove This* to IUnknown* casts in order to > avoid obvious problems with vtable pointer placement inside of object > implementation. Basically this is just a clean up patch. > > Is there anything else to clear the pending patch state? It's just moving the casts around, it doesn't seem like much of an improvement. -- Alexandre Julliard julli...@winehq.org
Re: ws2_32: Fix interface-bound filter to accept locally generated targeted packets.
On 24 Jun 2013, at 04:30, Erich E. Hoover wrote: <0001-ws2_32-Fix-interface-bound-filter-to-accept-locally-.patch> The added "struct sock_filter ip_memaddr" field doesn't seem to be used. Jonas
Re: wbemprox: Implement Win32_OperatingSystem.LocalDateTime.
On Sun, 2013-06-23 at 18:55 +0200, Sylvain Petreolle wrote:
> +static WCHAR *get_localdatetime(void)
> +{
> +static const WCHAR fmtW[] =
> +
> {'%','0','4','u','%','0','2','u','%','0','2','u','%','0','2','u','%','0','2','u','%','0','2','u',
> + '.','%','0','6','u','+','0','0','0',0};
> +SYSTEM_TIMEOFDAY_INFORMATION ti;
> +TIME_FIELDS tf;
> +WCHAR *ret;
> +
> +if (!(ret = heap_alloc( 26 * sizeof(WCHAR) ))) return NULL;
> +
> +NtQuerySystemInformation( SystemTimeOfDayInformation, &ti, sizeof(ti),
> NULL );
> +RtlTimeToTimeFields( &ti.liKeBootTime, &tf );
> +sprintfW( ret, fmtW, tf.Year, tf.Month, tf.Day, tf.Hour, tf.Minute,
> tf.Second, tf.Milliseconds * 1000 );
> +return ret;
> +}
This will not return local time.
Re: wbemprox: Implement some properties of Win32_BIOS. (resend 4)
On Sat, 2013-06-22 at 12:17 +0900, Kim Jung Eon (김중언) wrote:
> static const struct column col_bios[] =
> {
> +{ prop_biosversionW, CIM_STRING|CIM_FLAG_ARRAY},
> { prop_descriptionW, CIM_STRING },
> { prop_manufacturerW, CIM_STRING },
> { prop_releasedateW, CIM_DATETIME },
> @@ -508,6 +511,7 @@ struct record_baseboard
> };
> struct record_bios
> {
> +const struct array *biosversion;
> const WCHAR *description;
> const WCHAR *manufacturer;
> const WCHAR *releasedate;
> @@ -695,9 +699,13 @@ static const struct record_baseboard data_baseboard[] =
> {
> { baseboard_manufacturerW, baseboard_serialnumberW, baseboard_tagW }
> };
> +static const struct array data_bios_biosversion =
> +{
> +1, (void*)bios_versionW
> +};
This can't work. BIOSVersion is of type CIM_STRING|CIM_FLAG_ARRAY, which
translates
to a pointer to an array of string pointers.
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
Le 24/06/2013 09:24, Henri Verbeet a écrit : On 23 June 2013 21:57, Christian Costa wrote: When D3DTA_CONSTANT is use in a texture stage, the generated shader uses variables that are not defined making thus the compilation to fail. This patch declare these variables with the value from the related texture stage state D3D_TSS_CONSTANT. This fixes the text display in Spin Tires demo. This patch has several issues. Even without those, it should probably be deferred anyway. Even deferred, can you elaborate a bit so I can fix them. Unless you have already something.
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
On 23 June 2013 21:57, Christian Costa wrote: > When D3DTA_CONSTANT is use in a texture stage, the generated shader uses > variables that are not defined making thus the compilation to fail. > This patch declare these variables with the value from the related texture > stage state D3D_TSS_CONSTANT. > This fixes the text display in Spin Tires demo. This patch has several issues. Even without those, it should probably be deferred anyway.
Re: wined3d: print the architecture when showing driver problems
On 23 June 2013 07:10, Austin English wrote: > Please consider applying before the release of 1.6. It has no > functional changes, but would really help when diagnosing user > problems. > This is not really a wined3d patch. That said, while I agree that printing the architecture would be useful here, you can probably avoid the #ifdef by using something along the lines of sizeof(void *) == 8 ? "64-bit" : "32-bit", although ideally we'd probably get the actual architecture from somewhere like ntdll.
Re: po: Update Simplified Chinese translation (resend)
(Sorry to Hin-Tak for reposting, I didn't reply all) Thanks for your comment, Hin-Tak. I categorized your comment as follow: 1. Difference between SC and TC: 活跃连接 - 作用中的連線 句柄 - 控制代碼 (yes I hate it but it has been used in SC for a long time) 接口 - 介面 (as in programming and network interface) 优先级 - 優先權 行 - 列 对象 - 物件 I won't change this part. 2. TC translations that I agree paged - 已分页 - 置換頁 nonpaged - 未分页 - 非置換頁 Quoted from *Memory Pools* in MSDN[1], "*The nonpaged pool consists of virtual memory addresses that are guaranteed to reside in physical memory as long as the corresponding kernel objects are allocated. Thepaged pool consists of virtual memory that can be paged in and out of the system.*" I think 可换页 and 不可换页 are more accurate. 3. TC translations that I don't agree Processor Affinity - 处理器关联 - 處理器親和度 >From *SetProcessAffinityMask function* in MSDN[2]: "*A process affinity mask is a bit vector in which each bit represents a logical processor on which the threads of the process are allowed to run*" 親和度 is directly translated from affinity. To me this word suggests that this is a preference - a process prefers to run on the given processors, but not limited to. Maybe that is a standard terminology in Taiwan and it's fine. However we don't have a standard translation in Mainland China. In SC MSDN is is translated to 关联, while in SC Win 7 it is translated to 相关性. For now I think we can keep this translation until we come up with a better translation. USER Objects - 用户对象 - USER 物件 The difference between 对象 and 物件 is listed in item 1. The question is whether we should translate USER. It's capitalized here because it's capitalized in *GetGuiResources function*[3]. However I don't think it has any special meaning. It's not capitalized in *User Objects*[4]. So I think we should translate it. 4. The other details 列表中没有内容 - 列表中没有条目 I don't think we have to translate entry to 条目 everywhere. The former sounds better to me. later version - 更高版本 - 更新版本 Yeah 更新 sounds better. Again thanks for your review. It's too late for me now. I'll post a patch tomorrow. Feel free to point out my mistake :) [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa965226%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms686223%28v=vs.85%29.aspx [3] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683192%28v=vs.85%29.aspx [4] http://msdn.microsoft.com/en-us/library/windows/desktop/ms725486%28v=vs.85%29.aspx
