Fabian Maurer <dark.shadow4(a)web.de> writes:
> +static void test_evr_filter_aggregations(void)
> +{
> + const IID * iids[] = {
> + &IID_IAMCertifiedOutputProtection, &IID_IAMFilterMiscFlags, &IID_IBaseFilter,
> + &IID_IKsPropertySet, &IID_IMediaEventSink, &IID_IMediaSeeking, &IID_IQualityControl,
> + &IID_IQualProp, &IID_IEVRFilterConfig, &IID_IMFGetService, &IID_IMFVideoPositionMapper,
> + &IID_IMFVideoRenderer, &IID_IQualityControl
> + };
> + int i;
> +
> + if(!strcmp(winetest_platform, "wine"))
> + {
> + skip("Not supported yet.\n");
> + return;
> + }
I don't think it's useful to have a test that doesn't test anything. You
should mark the tests as todo but still run them. If that's not
possible, it should wait until we have something to test.
--
Alexandre Julliard
julliard(a)winehq.org
On 20 September 2017 at 19:53, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
> Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com>
> ---
> Tests (later on in the patch series) show that calling GenerateMips()
> on a texture without the D3D11_RESOURCE_MISC_GENERATE_MIPS flag does
> nothing. In theory, the whole check could be done on the d3d11 side
> but that turns out to be somewhat awkward, in practice, so I'm going
> to add a wined3d flag and pass it around instead.
>
In principle that's fine, but like this it's unused. (For what it's
worth, I don't necessarily think it needs to be used a lot initially.
Even if it's only used to print the FIXME or not in
wined3d_texture_generate_mipmaps() that would be a start.)
There's also the matter of how this relates to
WINED3DUSAGE_AUTOGENMIPMAP. This flag is for manual mipmap generation,
while WINED3DUSAGE_AUTOGENMIPMAP is for automatic mipmap generation,
but it's not pretty that one is a texture flag while the other is a
resource usage flag.
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
https://testbot.winehq.org/JobDetails.pl?Key=33206
Your paranoid android.
=== w7u (32 bit install) ===
The task timed out
On Wed, 20 Sep 2017, André Hentschel wrote:
> Signed-off-by: André Hentschel <nerv(a)dawncrow.de>
> ---
> dlls/ntdll/signal_arm64.c | 41 +++++++++++++++++++++++++++++++++++++----
> 1 file changed, 37 insertions(+), 4 deletions(-)
Now that you're implementing this, I think it'd make sense to complete the
arm64 CONTEXT struct (compared to the win10 sdk); our version is lacking
the float registers (and debug registers) at the end, when compared with
the version of the struct in the public SDK. And contrary to ARM, support
for the float registers is on by default in all toolchains, so there's no
combination where one would be building wine for arm64 where that wouldn't
work.
Our version also defines the X registers slightly differently, the public
SDK uses an union that allows accessing them both via member names and via
an array - although it should end up as the same binary representation. I
haven't sent any patch for bringing this up to date yet since I wasn't
touching this area yet.
// Martin
Alexander Coffin <alexcoffin1999(a)gmail.com> writes:
> @@ -1478,7 +1557,9 @@ void WCMD_execute (const WCHAR *command, const WCHAR *redirects,
> switch (i) {
>
> case WCMD_CALL:
> + push_errorlevel_changed();
> WCMD_call (p);
> + pop_errorlevel_changed();
This seems to be the only place that does this, so I don't see why you
need to manage your own stack instead of saving/restoring things on the
process stack.
Also returning a success/failure value from the various functions that
implement commands would probably be cleaner than adding a global
'changed' flag.
--
Alexandre Julliard
julliard(a)winehq.org
Hi!
I am trying to find better way to collect and report information about game
I want to make run under wine "Elite: Dangerous". At the launch of the game
game compiles both regular shaders it is using in game and also compute
shaders it's using for scenery generation. During that initial compilation
game hangs and I see lot of these and similar errors:
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x800002c2.
fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0x00199983.
fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader
#162:
fixme:d3d_shader:print_glsl_info_log Compute info
fixme:d3d_shader:print_glsl_info_log ------------
fixme:d3d_shader:print_glsl_info_log 0(22) : warning C7050: "R0.zw"
might be used before being initialized
fixme:d3d_shader:print_glsl_info_log 0(23) : warning C7050: "R1.zw"
might be used before being initialized
So question is - is there's a way to debug these more in detail? Are any
such info useful for people working on d3d11 support?
Thank you for any hints,
Respectfully,
Peteris Krisjanis.
Hi Jonathan,
For a quick test I made modification in your tests, see the attachment.
With that modification, tests still pass on Windows but not on Wine
(with or without your patches). This shows that there is something wrong
with default security descriptor.
I don't know what's the exact problem you're trying to fix, but it's
likely that fixing default security descriptor is what would fix your
problem, I would suggest to concentrate on that first.
Thanks,
Jacek
André Hentschel <nerv(a)dawncrow.de> writes:
> + "ldr x15, [x0, #0x100]\n\t"
> + "mov sp, x15\n\t"
> + "ldr x15, [x0, #0x108]\n\t"
> + "ldr x0, [x0, #0x8]\n\t"
> + "br x15\n\t"
This doesn't look very different from the previous try, and it still has
the same problem.
--
Alexandre Julliard
julliard(a)winehq.org