May 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 4/6] wined3d: Prefer GLSL 1.50 shaders in draw_test_quad().

by Henri Verbeet

On 29 May 2017 at 10:53, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + BOOL use_glsl_150 = gl_info->glsl_version >= 150; That doesn't work in Wine :D I wouldn't necessarily mind if it did though.

May 29, 2017

Re: [PATCH] comctl32/listview: Do not select the first list item when drawing a marquee rectangle

by Hugh McMaster

On Wednesday, 24 May 2017 4:34 AM, Nikolay Sivov wrote: > I see what you mean, when you start selecting with marquee first item in > report mode is always selected. This patch fixes that, but breaks ICON > mode it seems - sometimes items are not selected when they are clearly > intersect with marquee rectangle. Sorry for the delayed reply. Yes, I see what you mean by ICON mode. > Admittedly this selection mode is > already funny in ICON mode, it does not use dead zones properly, so > slight movement selects things, while it should check with icon > rectangle when resized horizontally, and allow about half icon rectangle > intersect marquee vertically before setting item state. Personally, I don't see any noticeable difference in ICON mode selection behaviour when the patch is applied. But one thing is certain - the selection behaviour for that mode is largely broken.

May 29, 2017

Re: [v5 PATCH 1/3] wined3d: Send texture updates through the command stream.

by Stefan Dösinger

Hi Masanori, I am sorry, I forgot to reply until I saw your patch resend this morning. Henri's reply (https://www.winehq.org/pipermail/wine-patches/2017-May/162123.html) suggests that he doesn't see the command emitting as the pressing issue in this patch series. So your original approach is fine for now and we can adjust this specific aspect later. Since he didn't sign off on the patches I assume there is something else he doesn't like. I guess it is still the lack of integration with location tracking (https://www.winehq.org/pipermail/wine-devel/2017-April/117453.html) Regarding the options with blit emitting (and again, it's not important right now), I was thinking about something like this: /* FIXME: Better name */ static void wined3d_cs_blt_helper(dst_resource, src_resource, ...) { /* Most code from wined3d_cs_exec_blt_sub_resource goes here */ /* but not wined3d_resource_release() calls */ } static void wined3d_cs_exec_blt_sub_resource(struct wined3d_cs *cs, const void *data) { const struct wined3d_cs_blt_sub_resource *op = data; wined3d_cs_blt_helper(op->src, op->dst, ...); if (op->src_resource) wined3d_resource_release(op->src_resource); wined3d_resource_release(op->dst_resource); } static void wined3d_cs_exec_update_texture(struct wined3d_cs *cs, const void *data) { /* This looks very similar to your code from may 25, except that it calls wined3d_cs_blt_helper instead of emit_blt_sub_resource. */ wined3d_resource_release(src); wined3d_resource_release(dst); } /* Of course you still need the individual wined3d_cs_emit() calls */ Am 2017-05-25 um 16:19 schrieb Masanori Kakura: > On Wed, 24 May 2017 16:08:30 +0200 > Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > >> Am 2017-05-24 um 15:49 schrieb Masanori Kakura: >>> + for (j = 0; j < layer_count; ++j) >>> + { >>> + wined3d_cs_emit_blt_sub_resource(cs, >>> + &dst_texture->resource, j * dst_level_count + i, &box, >>> + &src_texture->resource, j * src_level_count + i + src_skip_levels, &box, >>> + 0, NULL, WINED3D_TEXF_POINT); >>> + } >> I don't like emitting new operations in the CS handler instead of doing >> the actual operation. Maybe this can be avoided with some refactoring of >> wined3d_cs_exec_blt_sub_resource? > > I wrote 2 new patches but I'm not sure which is better. > > ----- Patch 1 (modify wined3d_cs_exec_blt_sub_resource) ----- > static void wined3d_cs_exec_blt_sub_resource(struct wined3d_cs *cs, const void *data) > { > /* ... */ > > error: > if (op->opcode == WINED3D_CS_OP_BLT_SUB_RESOURCE) > { > if (op->src_resource) > wined3d_resource_release(op->src_resource); > wined3d_resource_release(op->dst_resource); > } > } > > static void wined3d_cs_exec_update_texture(struct wined3d_cs *cs, const void *data) > { > /* ... */ > > for (i = 0; i < level_count; ++i) > { > width = wined3d_texture_get_level_width(dst_texture, i); > height = wined3d_texture_get_level_height(dst_texture, i); > depth = wined3d_texture_get_level_depth(dst_texture, i); > wined3d_box_set(&box, 0, 0, width, height, 0, depth); > > for (j = 0; j < layer_count; ++j) > { > const struct wined3d_cs_blt_sub_resource op_blt = {WINED3D_CS_OP_UPDATE_TEXTURE, > &dst_texture->resource, j * dst_level_count + i, box, > &src_texture->resource, j * src_level_count + i + src_skip_levels, box, > 0, NULL, WINED3D_TEXF_POINT}; > > wined3d_cs_exec_blt_sub_resource(cs, &op_blt); > } > } > > wined3d_resource_release(&src_texture->resource); > wined3d_resource_release(&dst_texture->resource); > } > > ----- Patch 2 (write codes directly) ----- > static void wined3d_cs_exec_update_texture(struct wined3d_cs *cs, const void *data) > { > /* ... */ > > /* Update every surface level of the texture. */ > for (i = 0; i < level_count; ++i) > { > width = wined3d_texture_get_level_width(dst_texture, i); > height = wined3d_texture_get_level_height(dst_texture, i); > depth = wined3d_texture_get_level_depth(dst_texture, i); > wined3d_box_set(&box, 0, 0, width, height, 0, depth); > > for (j = 0; j < layer_count; ++j) > { > struct wined3d_resource *dst_resource = &dst_texture->resource; > unsigned int dst_sub_resource_idx = j * dst_level_count + i; > unsigned int src_sub_resource_idx = j * src_level_count + i + src_skip_levels; > > if (dst_resource->type == WINED3D_RTYPE_TEXTURE_2D) > { > struct wined3d_surface *dst_surface, *src_surface; > > dst_surface = dst_texture->sub_resources[dst_sub_resource_idx].u.surface; > src_surface = src_texture->sub_resources[src_sub_resource_idx].u.surface; > > if (FAILED(wined3d_surface_blt(dst_surface, (const RECT *)&box, src_surface, > (const RECT *)&box, 0, NULL, WINED3D_TEXF_POINT))) > FIXME("Blit failed.\n"); > } > else if (dst_resource->type == WINED3D_RTYPE_TEXTURE_3D) > { > unsigned int update_w, update_h, update_d; > unsigned int row_pitch, slice_pitch; > struct wined3d_context *context; > struct wined3d_bo_address addr; > > update_w = box.right - box.left; > update_h = box.bottom - box.top; > update_d = box.back - box.front; > > if (box.left || box.top || box.front) > { > FIXME("Source box %s not supported for %s resources.\n", > debug_box(&box), debug_d3dresourcetype(dst_resource->type)); > continue; > } > > context = context_acquire(cs->device, NULL, 0); > > if (!wined3d_texture_load_location(src_texture, src_sub_resource_idx, > context, src_texture->resource.map_binding)) > { > ERR("Failed to load source sub-resource into %s.\n", > wined3d_debug_location(src_texture->resource.map_binding)); > context_release(context); > continue; > } > > if (update_w == width && update_h == height && update_d == depth) > { > wined3d_texture_prepare_texture(dst_texture, context, FALSE); > } > else if (!wined3d_texture_load_location(dst_texture, dst_sub_resource_idx, > context, WINED3D_LOCATION_TEXTURE_RGB)) > { > ERR("Failed to load destination sub-resource.\n"); > context_release(context); > continue; > } > > wined3d_texture_get_memory(src_texture, src_sub_resource_idx, &addr, src_texture->resource.map_binding); > wined3d_texture_get_pitch(src_texture, src_sub_resource_idx % src_texture->level_count, > &row_pitch, &slice_pitch); > > wined3d_texture_bind_and_dirtify(dst_texture, context, FALSE); > wined3d_texture_upload_data(dst_texture, dst_sub_resource_idx, context, &box, > wined3d_const_bo_address(&addr), row_pitch, slice_pitch); > wined3d_texture_validate_location(dst_texture, dst_sub_resource_idx, WINED3D_LOCATION_TEXTURE_RGB); > wined3d_texture_invalidate_location(dst_texture, dst_sub_resource_idx, ~WINED3D_LOCATION_TEXTURE_RGB); > > context_release(context); > } > else > { > FIXME("Not implemented for %s resources.\n", debug_d3dresourcetype(dst_resource->type)); > } > } > } > > wined3d_resource_release(&src_texture->resource); > wined3d_resource_release(&dst_texture->resource); > } >

May 29, 2017

Re: [v6 PATCH 2/3] wined3d: Add dirty region tracking.

by 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 https://testbot.winehq.org/JobDetails.pl?Key=31231 Your paranoid android. === w1064 (64 bit visual) === visual.c:8016: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

May 28, 2017

about donat enikeev csmt on graphics tab in winecfg

by CARLOS RODRIGUEZ

Hi henri I read your discussion about normal user dont need touch that However various titles needs csmt, mainly for solve graphics issues case duke nuke forever (dont show anything without csmt), resident evil 6 (only see light without csmt) Or flickering graphics case im alive, senran kagura shinovi versus, bayonetta, vanquish Resolve audio sincronization in prerenderer sequences case front mission evolved And possible many other titles Put option in winecfg could be usefull for new users I agree about you said related csmt dont be stay active for default for now, but solve before problems described Maybe can add some note in csmt like that: mainly for resolve graphics issues for now or something similar Thanks

May 27, 2017

Re: [PATCH v7 02/26] x86/mm: Relocate page fault error codes to traps.h

by Borislav Petkov

On Fri, May 26, 2017 at 08:40:26PM -0700, Ricardo Neri wrote: > This change was initially intended to only rename the error codes, > without functional changes. Would making change be considered a change > in functionality? How? The before-and-after asm should be the identical. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

May 27, 2017

Re: [PATCH v7 00/26] x86: Enable User-Mode Instruction Prevention

by Neri, Ricardo

Hi again Ingo, Thomas, On Wed, 2017-05-17 at 11:42 -0700, Ricardo Neri wrote: > Hi Ingo, Thomas, > > On Fri, 2017-05-05 at 11:16 -0700, Ricardo Neri wrote: > > This is v7 of this series. The six previous submissions can be found > > here [1], here [2], here[3], here[4], here[5] and here[6]. This > > version > > addresses the comments received in v6 plus improvements of the > > handling > > of exceptions unrelated to UMIP as well as corner cases in > > virtual-8086 > > mode. Please see details in the change log. > > Since there have been no more comments in the version and if this series > look good to you, could this be considered to be merged into the tip > tree? > > The only remaining item is a cleanup patch that Borislav Petkov > suggested [1]. I could work on it incrementally on top of this series. More items have accumulated from the latest review from Borislav Petkov. These items are preparatory changes and are mostly minimal and would impact functionality. There have been no comments on other parts of the implementation. If I spin a v8 of the series, would it be considered sufficiently mature to be included in v4.13? Thanks and BR, Ricardo > > Thanks and BR, > Ricardo > > [1]. https://lkml.org/lkml/2017/5/4/244 > > > > > >

May 27, 2017

Re: [PATCH v7 02/26] x86/mm: Relocate page fault error codes to traps.h

by Ricardo Neri

On Sun, 2017-05-21 at 16:23 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:00AM -0700, Ricardo Neri wrote: > > Up to this point, only fault.c used the definitions of the page fault error > > codes. Thus, it made sense to keep them within such file. Other portions of > > code might be interested in those definitions too. For instance, the User- > > Mode Instruction Prevention emulation code will use such definitions to > > emulate a page fault when it is unable to successfully copy the results > > of the emulated instructions to user space. > > > > While relocating the error code enumeration, the prefix X86_ is used to > > make it consistent with the rest of the definitions in traps.h. Of course, > > code using the enumeration had to be updated as well. No functional changes > > were performed. > > > > Cc: Thomas Gleixner <tglx(a)linutronix.de> > > Cc: Ingo Molnar <mingo(a)redhat.com> > > Cc: "H. Peter Anvin" <hpa(a)zytor.com> > > Cc: Andy Lutomirski <luto(a)kernel.org> > > Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> > > Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > > Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> > > Cc: x86(a)kernel.org > > Reviewed-by: Andy Lutomirski <luto(a)kernel.org> > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > > --- > > arch/x86/include/asm/traps.h | 18 +++++++++ > > arch/x86/mm/fault.c | 88 +++++++++++++++++--------------------------- > > 2 files changed, 52 insertions(+), 54 deletions(-) > > ... > > > @@ -1382,7 +1362,7 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code, > > * space check, thus avoiding the deadlock: > > */ > > if (unlikely(!down_read_trylock(&mm->mmap_sem))) { > > - if ((error_code & PF_USER) == 0 && > > + if ((error_code & X86_PF_USER) == 0 && > > if (!(error_code & X86_PF_USER)) This change was initially intended to only rename the error codes, without functional changes. Would making change be considered a change in functionality? The behavior would be preserved, though. Thanks and BR, Ricardo > > With that fixed: > > Reviewed-by: Borislav Petkov <bp(a)suse.de> Thank you for your review! BR, Ricardo > > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

May 27, 2017

Re: [PATCH v7 04/26] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b

by Ricardo Neri

On Wed, 2017-05-24 at 15:37 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:02AM -0700, Ricardo Neri wrote: > > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software > > Developer's Manual volume 2A states that when ModRM.mod !=11b and > > ModRM.rm = 100b indexed register-indirect addressing is used. In other > > words, a SIB byte follows the ModRM byte. In the specific case of > > SIB.index = 100b, the scale*index portion of the computation of the > > effective address is null. To signal callers of this particular situation, > > get_reg_offset() can return -EDOM (-EINVAL continues to indicate that an > > error when decoding the SIB byte). > > > > An example of this situation can be the following instruction: > > > > 8b 4c 23 80 mov -0x80(%rbx,%riz,1),%rcx > > ModRM: 0x4c [mod:1b][reg:1b][rm:100b] > > SIB: 0x23 [scale:0b][index:100b][base:11b] > > Displacement: 0x80 (1-byte, as per ModRM.mod = 1b) > > > > The %riz 'register' indicates a null index. > > > > In long mode, a REX prefix may be used. When a REX prefix is present, > > REX.X adds a fourth bit to the register selection of SIB.index. This gives > > the ability to refer to all the 16 general purpose registers. When REX.X is > > 1b and SIB.index is 100b, the index is indicated in %r12. In our example, > > this would look like: > > > > 42 8b 4c 23 80 mov -0x80(%rbx,%r12,1),%rcx > > REX: 0x42 [W:0b][R:0b][X:1b][B:0b] > > ModRM: 0x4c [mod:1b][reg:1b][rm:100b] > > SIB: 0x23 [scale:0b][.X: 1b, index:100b][.B:0b, base:11b] > > Displacement: 0x80 (1-byte, as per ModRM.mod = 1b) > > > > Cc: Borislav Petkov <bp(a)suse.de> > > Cc: Andy Lutomirski <luto(a)kernel.org> > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > > Cc: Colin Ian King <colin.king(a)canonical.com> > > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > > Cc: Peter Zijlstra <peterz(a)infradead.org> > > Cc: Nathan Howard <liverlint(a)gmail.com> > > Cc: Adan Hawthorn <adanhawthorn(a)gmail.com> > > Cc: Joe Perches <joe(a)perches.com> > > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > > Cc: x86(a)kernel.org > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > > --- > > arch/x86/mm/mpx.c | 20 ++++++++++++++++++-- > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c > > index ebdead8..7397b81 100644 > > --- a/arch/x86/mm/mpx.c > > +++ b/arch/x86/mm/mpx.c > > @@ -110,6 +110,14 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > > regno = X86_SIB_INDEX(insn->sib.value); > > if (X86_REX_X(insn->rex_prefix.value)) > > regno += 8; > > <--- newline. I will add a new line here. > > > + /* > > + * If ModRM.mod !=3 and SIB.index (regno=4) the scale*index > > + * portion of the address computation is null. This is > > + * true only if REX.X is 0. In such a case, the SIB index > > + * is used in the address computation. > > + */ > > + if (X86_MODRM_MOD(insn->modrm.value) != 3 && regno == 4) > > + return -EDOM; > > break; > > > > case REG_TYPE_BASE: > > @@ -159,11 +167,19 @@ static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs) > > goto out_err; > > > > indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX); > > - if (indx_offset < 0) > > <--- newline. I will add a new line here. > > > + /* > > + * A negative offset generally means a error, except > > an > > > + * -EDOM, which means that the contents of the register > > + * should not be used as index. > > + */ > > + if (indx_offset == -EDOM) > > + indx = 0; > > + else if (indx_offset < 0) > > goto out_err; > > + else > > + indx = regs_get_register(regs, indx_offset); > > > > base = regs_get_register(regs, base_offset); > > - indx = regs_get_register(regs, indx_offset); > > eff_addr = base + indx * (1 << X86_SIB_SCALE(sib)); > > } else { > > addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM); > > -- > > 2.9.3 > > > > -- > Regards/Gruss, > Boris. Thanks for reviewing! BR, Ricardo > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

May 27, 2017

Re: [PATCH] msvcp140: Implement _To_wide (v2).

by Stefan Dösinger

Am 2017-05-26 um 13:17 schrieb Stefan Dösinger: > + return MultiByteToWideChar(CP_ACP, 0, src, -1, dst, strlen(src) + 1); Do not commit this yet, there is another version coming. The maximum length is limited to MAX_PATH, and Nikolai says the test randomly crashes on his Windows. It seems Microsoft lets interns write APIs nowadays.

May 26, 2017