Re: msvcrt/tests: Mark win8 behaviour as broken (try 2)

[Marvin]

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=24548

Your paranoid android.


=== WINEBUILD (build) ===
Patch failed to apply

Fix name order in the authors file.

[Tae Wong]

You’ve found Kazuyuki Sato in inverted name order. Apostrophes on the
O-section are not ignored.

O'Callahan, Robert
O'Neill, Damien
O'Regan, Mike
Oberhumer, Stefan
Oberndorfer, Peter
Ogburn, Walt
Ognyanoff, Damyan
Olsen, Henrik
Olsen, Magnus
Olson, Roger
Olver, Neil
Ortiz, Jose Manuel Ferrer
Osmundsen, Knut St.

It should be ignored so the section should be sorted as:

Oberhumer, Stefan
Oberndorfer, Peter
O'Callahan, Robert
Ogburn, Walt
Ognyanoff, Damyan
Olsen, Henrik
Olsen, Magnus
Olson, Roger
Olver, Neil
O'Neill, Damien
O'Regan, Mike
Ortiz, Jose Manuel Ferrer
Osmundsen, Knut St.

Re: d3dx9: Avoid expensive computations

[Matteo Bruni]

2013/2/26 Rico Schüller :
> Hi Nozomi,
>
> this is pretty fast. Just some numbers (run time on my machine, so it might
> not be that representative)...
>
> before: 43s
> previous patch: 27s
> this patch: 21s
> native: 16s
>
> So from the speed point of view, it's a lot closer than the rest.
>
> Though, I would split this into 2 patches, one for D3DXMatrixDeterminant and
> one for D3DXMatrixInverse.

That's probably a good idea.

> I think it's a nice step forward. Thought we
> might test the speed of an sse version and may use it later ...
>
> Are there any other opinions?
>

My main concern is that the effort in optimizing further those two
functions might not have significant effects on actual application
execution times (think diminishing returns). I'm not against making
the code faster, especially if that doesn't make the code unreadable,
but it might not be the best place to work on if you want to optimize
d3dx9. You might want to profile some applications and see what the
actual bottlenecks are.

Specifically on these functions, an SSE-based version will probably
run significantly faster, but you need to solve the issues with
compatibility with older CPUs e.g. by selecting the correct function
implementation at runtime in some fashion, as Henri mentioned. BTW
there might be other potential problems, such as applications setting
the SSE control register in some unexpected way (although that happens
with the FPU control word too).
You can also give a shot to GCC optimization options, such as
"-mfpmath=sse" (and a suitable -march value). Obviously we don't want
to use them in general but it might be interesting to see what GCC can
do there. Keep in mind that the compiler has to stay on the safe side
when optimizing and you might need to add attributes around to allow
more aggressive optimizations. From a quick Google search I found
http://locklessinc.com/articles/vectorize/ which seems to show the
general idea.


Cheers,
Matteo.

> Cheers
> Rico
>
>
>
> On 25.02.2013 12:34, Nozomi Kodama wrote:
>>
>> Rico,
>>
>> can you give a try to this patch?
>> If it is slightly slower than native, we could at first merge it.
>>
>>
>> Anyway, if the application is well coded, this function should not be
>> called often. Usually an application uses transformations matrices that
>> are a lot easier to inverse
>>
>> Nozomi
>>
>>
>> 
>> *De :* Henri Verbeet 
>> *À :* Rico Schüller 
>> *Cc :* wine-devel@winehq.org; Nozomi Kodama 
>> *Envoyé le :* Lundi 25 février 2013 0h08
>> *Objet :* Re: d3dx9: Avoid expensive computations
>>
>>
>> On 25 February 2013 10:24, Rico Schüller > > wrote:
>>  > I did some small tests for speed with the following results. You may
>> also
>>  > avoid such a lot of variable assignments like *pout = out and you may
>> use 4
>>  > vecs instead. This should save ~48 assignments and it should also
>> improve
>>  > the speed a bit more (~10%). Though, native is still 40% faster than
>> that.
>>  >
>> I'd somewhat expect native to use SSE versions of this kind of thing
>> when the CPU supports those instructions. You also generally want to
>> pay attention to the order in which you access memory, although
>> perhaps it doesn't matter so much here because an entire matrix should
>> be able to fit in a single cacheline, provided it's properly aligned.
>>
>>
>
>
>

Re: secur32: Report SecPkgContext_ConnectionInfo in bits, not bytes.

[Marvin]

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=24544

Your paranoid android.


=== W2KPROSP4 (32 bit schannel) ===
schannel.c:762: Test failed: conn_info.dwHashStrength = 128

=== WXPPROSP3 (32 bit schannel) ===
schannel.c:762: Test failed: conn_info.dwHashStrength = 128

=== W2K3R2SESP2 (32 bit schannel) ===
schannel.c:762: Test failed: conn_info.dwHashStrength = 128

Re: mmdevapi: Prevent 64 bit overflow within a few days of audio device use.

[Michael Stefaniuc]

Hello Joerg,

On 02/27/2013 02:46 PM, joerg-cyril.hoe...@t-systems.com wrote:

The idea to replace X * numerator / denominator
by X / den * mul + remainder from euclidian division
came from

can you please use an inline function for that?


http://blog.airsource.co.uk/index.php/2010/03/15/quelle-heure-est-il/


thanks
bye
michael

Re: [PATCH 2/4] vbscript: Added color constants.

[Marvin]

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=24538

Your paranoid android.


=== WINEBUILD (build) ===
Patch failed to apply

Re: [1/3] wininet: Remember that headers were not received.

[Jacek Caban]

Hi Ričardas,

On 02/27/13 00:07, Ričardas Barkauskas wrote:
> @@ -5708,6 +5708,7 @@ static INT HTTP_GetResponseHeaders(http_request_t 
> *request, BOOL clear)
>  
>  heap_free(request->rawHeaders);
>  request->rawHeaders = heap_strdupW(szDefaultHeader);
> +request->flags |= INTERNET_REQFLAG_NO_HEADERS;

I don't think we want to maintain valid request->flags for that
particular flag. Checking for request->rawHeaders should be enough. If
we avoided setting rawHeaders here, we'd achieve the same behaviour.

Jacek

Re: msvcrt/tests: Mark win8 behaviour as broken

[Piotr Caban]

On 02/26/13 23:57, André Hentschel wrote:

diff --git a/dlls/msvcrt/tests/time.c b/dlls/msvcrt/tests/time.c
index 30d9fa7..3d00769 100644
--- a/dlls/msvcrt/tests/time.c
+++ b/dlls/msvcrt/tests/time.c
@@ -181,8 +181,8 @@ static void test_gmtime(void)
  err = p_gmtime32_s(&gmt_tm_s, &gmt);
-ok(gmt_tm_s.tm_year==-1 || broken(gmt_tm_s.tm_year==70 && 
gmt_tm->tm_sec<0),
-"tm_year = %d\n", gmt_tm_s.tm_year);
+ok(gmt_tm_s.tm_year==-1 || broken(gmt_tm_s.tm_year==70),
+   "tm_year = %d, tm_sec = %d\n", gmt_tm_s.tm_year, gmt_tm->tm_sec);
This test was checking wrong structure. It should use gmt_tm_s struct 
for testing seconds instead of gmt_tm.