November 2021 - Wine-Devel - list.winehq.org

Re: [PATCH 8/8] wined3d: Try to allocate new Vulkan BOs from the client thread for DISCARD maps.

by Zebediah Figura

On 11/4/21 11:19 AM, Matteo Bruni wrote: > On Thu, Nov 4, 2021 at 4:45 PM Zebediah Figura <zfigura(a)codeweavers.com> wrote: >> >> On 11/4/21 8:17 AM, Henri Verbeet wrote: >>> On Wed, 3 Nov 2021 at 21:47, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >>>> On 11/3/21 12:11 PM, Henri Verbeet wrote: >>>>> On Wed, 3 Nov 2021 at 00:37, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >>>>>> +static bool adapter_vk_alloc_bo(struct wined3d_device *device, struct wined3d_resource *resource, >>>>>> + unsigned int sub_resource_idx, struct wined3d_bo_address *addr) >>>>>> +{ >>>>>> + wined3d_not_from_cs(device->cs); >>>>>> + >>>>>> + if (resource->type == WINED3D_RTYPE_BUFFER) >>>>>> + { >>>>>> + struct wined3d_buffer_vk *buffer_vk = wined3d_buffer_vk(buffer_from_resource(resource)); >>>>>> + struct wined3d_client_bo_vk *client_bo; >>>>>> + >>>>>> + if (!(client_bo = heap_alloc(sizeof(*client_bo)))) >>>>>> + return false; >>>>>> + >>>>>> + if (!wined3d_buffer_vk_create_buffer_object(buffer_vk, NULL, &client_bo->bo)) >>>>>> + { >>>>>> + heap_free(client_bo); >>>>>> + return false; >>>>>> + } >>>>>> + >>>>>> + if (!client_bo->bo.b.map_ptr) >>>>>> + { >>>>>> + struct wined3d_client_bo_vk_map_ctx ctx = {.device = device, .client_bo = client_bo}; >>>>>> + >>>>>> + WARN_(d3d_perf)("BO %p (chunk %p, slab %p) is not persistently mapped.\n", &client_bo->bo, >>>>>> + client_bo->bo.memory ? client_bo->bo.memory->chunk : NULL, client_bo->bo.slab); >>>>>> + >>>>>> + wined3d_cs_map_object(device->cs, wined3d_client_bo_vk_map_cs, &ctx); >>>>>> + wined3d_cs_finish(device->cs, WINED3D_CS_QUEUE_MAP); >>>>>> + } >>>>> wined3d_cs_map_object() almost sounds like it would emit a >>>>> WINED3D_CS_OP_MAP, somewhat like wined3d_device_context_map() back >>>>> when that was still called wined3d_cs_map()... >>>> >>>> Indeed, except that WINED3D_CS_OP_MAP takes the resource. I don't think >>>> we want to change that, either, although we could create a new CS op >>>> instead of using WINED3D_CS_OP_CALLBACK. >>>> >>> Yeah, I'm not suggesting we change WINED3D_CS_OP_MAP. It's somewhat >>> moot for the Vulkan backend now, but I would argue that if we would >>> have to go through the CS to map the bo anyway, we might as well >>> either give up and just map the resource through the CS, or allocate >>> the staging memory on the CPU. >> >> I think the motivation for not just doing that was to make sure that we >> actually did allocate new memory, instead of repeatedly going through >> the slow path to use the same mapped memory. I don't remember if this >> happened in practice, but there's a comment to similar effect on one of >> Matteo's patches... > > That was more or less the idea, although the whole mechanism was a bit > different (and with GL posing more constraints). Specifically, we > can't / don't want to make GL calls from non-CS threads, but at the > same time we want to be able to create new BOs for DISCARD maps > (either because we use a separate BO for each wined3d buffer DISCARD > map or because we're suballocating and there is no free space but we > want to trigger the allocation of a new BO to suballocate from - > basically the same as the non-slab case of > wined3d_context_vk_create_bo()). > So yeah, I don't think you have to care about that case here in the VK > callback and it's probably nicer to do what Henri suggested i.e. go > explicitly through the CS for a "slow" alloc, since that way the > fallback is in generic code. > > Assuming I understood the whole thing correctly, I'm not up to speed > with this as much as I'd like... > For Vulkan I think it doesn't matter, since we can just map from the client thread. For GL we have to to map from the CS thread, but if we just map the old resource via wined3d_resource_map(), we'll use &wined3d_buffer_gl.bo instead of allocating new memory, which means that the client will continue to have no accessible memory to return for a discard map. Repeat ad infinitum. Allocating sysmem would help, but my understanding is that expanding the available GPU memory pool would be better. That's the theoretical problem; I don't remember if it caused problems in practice, but I have a suspicion that it did...

Nov. 4, 2021

Re: [PATCH 8/8] wined3d: Try to allocate new Vulkan BOs from the client thread for DISCARD maps.

by Matteo Bruni

On Thu, Nov 4, 2021 at 4:45 PM Zebediah Figura <zfigura(a)codeweavers.com> wrote: > > On 11/4/21 8:17 AM, Henri Verbeet wrote: > > On Wed, 3 Nov 2021 at 21:47, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > >> On 11/3/21 12:11 PM, Henri Verbeet wrote: > >>> On Wed, 3 Nov 2021 at 00:37, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > >>>> +static bool adapter_vk_alloc_bo(struct wined3d_device *device, struct wined3d_resource *resource, > >>>> + unsigned int sub_resource_idx, struct wined3d_bo_address *addr) > >>>> +{ > >>>> + wined3d_not_from_cs(device->cs); > >>>> + > >>>> + if (resource->type == WINED3D_RTYPE_BUFFER) > >>>> + { > >>>> + struct wined3d_buffer_vk *buffer_vk = wined3d_buffer_vk(buffer_from_resource(resource)); > >>>> + struct wined3d_client_bo_vk *client_bo; > >>>> + > >>>> + if (!(client_bo = heap_alloc(sizeof(*client_bo)))) > >>>> + return false; > >>>> + > >>>> + if (!wined3d_buffer_vk_create_buffer_object(buffer_vk, NULL, &client_bo->bo)) > >>>> + { > >>>> + heap_free(client_bo); > >>>> + return false; > >>>> + } > >>>> + > >>>> + if (!client_bo->bo.b.map_ptr) > >>>> + { > >>>> + struct wined3d_client_bo_vk_map_ctx ctx = {.device = device, .client_bo = client_bo}; > >>>> + > >>>> + WARN_(d3d_perf)("BO %p (chunk %p, slab %p) is not persistently mapped.\n", &client_bo->bo, > >>>> + client_bo->bo.memory ? client_bo->bo.memory->chunk : NULL, client_bo->bo.slab); > >>>> + > >>>> + wined3d_cs_map_object(device->cs, wined3d_client_bo_vk_map_cs, &ctx); > >>>> + wined3d_cs_finish(device->cs, WINED3D_CS_QUEUE_MAP); > >>>> + } > >>> wined3d_cs_map_object() almost sounds like it would emit a > >>> WINED3D_CS_OP_MAP, somewhat like wined3d_device_context_map() back > >>> when that was still called wined3d_cs_map()... > >> > >> Indeed, except that WINED3D_CS_OP_MAP takes the resource. I don't think > >> we want to change that, either, although we could create a new CS op > >> instead of using WINED3D_CS_OP_CALLBACK. > >> > > Yeah, I'm not suggesting we change WINED3D_CS_OP_MAP. It's somewhat > > moot for the Vulkan backend now, but I would argue that if we would > > have to go through the CS to map the bo anyway, we might as well > > either give up and just map the resource through the CS, or allocate > > the staging memory on the CPU. > > I think the motivation for not just doing that was to make sure that we > actually did allocate new memory, instead of repeatedly going through > the slow path to use the same mapped memory. I don't remember if this > happened in practice, but there's a comment to similar effect on one of > Matteo's patches... That was more or less the idea, although the whole mechanism was a bit different (and with GL posing more constraints). Specifically, we can't / don't want to make GL calls from non-CS threads, but at the same time we want to be able to create new BOs for DISCARD maps (either because we use a separate BO for each wined3d buffer DISCARD map or because we're suballocating and there is no free space but we want to trigger the allocation of a new BO to suballocate from - basically the same as the non-slab case of wined3d_context_vk_create_bo()). So yeah, I don't think you have to care about that case here in the VK callback and it's probably nicer to do what Henri suggested i.e. go explicitly through the CS for a "slow" alloc, since that way the fallback is in generic code. Assuming I understood the whole thing correctly, I'm not up to speed with this as much as I'd like...

Nov. 4, 2021

Re: [PATCH 8/8] wined3d: Try to allocate new Vulkan BOs from the client thread for DISCARD maps.

by Zebediah Figura

On 11/4/21 8:17 AM, Henri Verbeet wrote: > On Wed, 3 Nov 2021 at 21:47, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >> On 11/3/21 12:11 PM, Henri Verbeet wrote: >>> On Wed, 3 Nov 2021 at 00:37, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >>>> +static bool adapter_vk_alloc_bo(struct wined3d_device *device, struct wined3d_resource *resource, >>>> + unsigned int sub_resource_idx, struct wined3d_bo_address *addr) >>>> +{ >>>> + wined3d_not_from_cs(device->cs); >>>> + >>>> + if (resource->type == WINED3D_RTYPE_BUFFER) >>>> + { >>>> + struct wined3d_buffer_vk *buffer_vk = wined3d_buffer_vk(buffer_from_resource(resource)); >>>> + struct wined3d_client_bo_vk *client_bo; >>>> + >>>> + if (!(client_bo = heap_alloc(sizeof(*client_bo)))) >>>> + return false; >>>> + >>>> + if (!wined3d_buffer_vk_create_buffer_object(buffer_vk, NULL, &client_bo->bo)) >>>> + { >>>> + heap_free(client_bo); >>>> + return false; >>>> + } >>>> + >>>> + if (!client_bo->bo.b.map_ptr) >>>> + { >>>> + struct wined3d_client_bo_vk_map_ctx ctx = {.device = device, .client_bo = client_bo}; >>>> + >>>> + WARN_(d3d_perf)("BO %p (chunk %p, slab %p) is not persistently mapped.\n", &client_bo->bo, >>>> + client_bo->bo.memory ? client_bo->bo.memory->chunk : NULL, client_bo->bo.slab); >>>> + >>>> + wined3d_cs_map_object(device->cs, wined3d_client_bo_vk_map_cs, &ctx); >>>> + wined3d_cs_finish(device->cs, WINED3D_CS_QUEUE_MAP); >>>> + } >>> wined3d_cs_map_object() almost sounds like it would emit a >>> WINED3D_CS_OP_MAP, somewhat like wined3d_device_context_map() back >>> when that was still called wined3d_cs_map()... >> >> Indeed, except that WINED3D_CS_OP_MAP takes the resource. I don't think >> we want to change that, either, although we could create a new CS op >> instead of using WINED3D_CS_OP_CALLBACK. >> > Yeah, I'm not suggesting we change WINED3D_CS_OP_MAP. It's somewhat > moot for the Vulkan backend now, but I would argue that if we would > have to go through the CS to map the bo anyway, we might as well > either give up and just map the resource through the CS, or allocate > the staging memory on the CPU. I think the motivation for not just doing that was to make sure that we actually did allocate new memory, instead of repeatedly going through the slow path to use the same mapped memory. I don't remember if this happened in practice, but there's a comment to similar effect on one of Matteo's patches... > >> (Now that I think about it, *is* there any sort of a rule as to what >> deserves WINED3D_CS_OP_CALLBACK and what doesn't? I know that currently >> it's just a matter of init and destroy, but it seeems a bit arbitrary on >> reflection.) >> > For the most part, it's things that I don't think should have their > own wined3d_cs_op. WINED3D_CS_OP_CALLBACK is a little ugly, but it > works well enough for the moment. I suppose we could do something > along the lines of the following: > > struct wined3d_cs_resource_ops > { > void (*cs_resource_init)(struct wined3d_cs_resource *resource); > void (*cs_resource_cleanup)(struct wined3d_cs_resource *resource); > }; > > struct wined3d_cs_resource > { > struct wined3d_cs_resource_ops *ops; > }; > > and then > > struct wined3d_cs_init_resource > { > enum wined3d_cs_op opcode; > struct wined3d_cs_resource *resource; > }; > > static void wined3d_cs_exec_init_resource(struct wined3d_cs *cs, > const void *data) > { > const struct wined3d_cs_init_resource *op = data; > > op->resource->ops->cs_resource_init(op->resource); > } > > and equivalent cleanup variants. Something like wined3d_sampler_vk > would then include a wined3d_cs_resource structure, and call > "wined3d_cs_init_object(device->cs, &sampler_vk->cs_resource);". That > ends up being largely equivalent to the current scheme, although > perhaps a little more structured. > Seems reasonable.

Nov. 4, 2021

Re: [PATCH v2 7/7] wined3d: Try to allocate new Vulkan BOs from the client thread for DISCARD maps.

by Henri Verbeet

On Thu, 4 Nov 2021 at 16:31, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > That one occurred to me as well. (I wasn't sure if there was a reason it > wasn't done like that in the first place. Not that wined3d_bo_vk and > wined3d_bo_gl used to have anything in common, but at least "void *" > would have made more sense...) > It evolved from being a GLuint containing a GL buffer object id. When the wined3d_bo_vk structure was originally introduced, that changed to being a uintptr_t containing either a pointer to a wined3d_bo_vk structure or a GL buffer object id. The wined3d_bo_gl structure is a bit more recent still, and not all of the consequences from introducing that have entirely settled yet.

Nov. 4, 2021

Re: [PATCH 1/8] wined3d: Pass a wined3d_device_vk to wined3d_context_vk_create_bo().

by Zebediah Figura

On 11/4/21 8:17 AM, Henri Verbeet wrote: > On Wed, 3 Nov 2021 at 21:47, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >> On 11/3/21 12:10 PM, Henri Verbeet wrote: >>> On Wed, 3 Nov 2021 at 00:20, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >>>> With the goal of making the context_vk parameter optional, so that we can >>>> allocate new BOs from the client thread. >>>> >>> This would mainly be for the wined3d_buffer_vk_create_buffer_object() >>> call in patch 8/8, but in the Vulkan backend, we can always get the >>> context through "device_vk->context_vk", provided we're inside an >>> init_3d()/uninit_3d() pair. I.e., the Vulkan backend can make Vulkan >>> calls from applications threads, it just needs synchronisation. I.e., >>> I don't think the Vulkan backend needs this. >> >> It's true that this patch series is modeled more like the GL backend >> than it needs to be in general. >> > Which, to be clear, is largely fine with me, as long as the > justification is something along the lines of "consistency with the GL > backend", instead of "required to do maps with a NULL context". > >> I had gotten the impression that we didn't want to touch >> wined3d_context_vk outside of the CS thread, even though it is thread >> safe. If that's not the case, all the better, although I'm still more >> than a little confused about the seemingly arbitrary division between >> device and context in the Vulkan adapter. >> > It's true that it's largely arbitrary; for the purposes of the Vulkan > backend, the device and the context could/should be considered to be > the same object. (And perhaps significantly, within the Vulkan backend > you can get a wined3d_device_vk from a wined3d_context using > CONTAINING_RECORD.) If you feel strongly about this being confusing, > I'd certainly be fine with just getting rid of wined3d_context_vk, and > moving everything to wined3d_device_vk. That said, there are broadly > two considerations for things ending up in one or the other structure: > > - Things that have direct equivalents in the OpenGL backend > generally are in the corresponding structure. E.g., > "null_resources_vk" and "null_views_vk" in wined3d_device_vk are > equivalents of "dummy_textures" in wined3d_device_gl; > "free_*_query_pools" in wined3d_context_vk are equivalents of > "free_*_queries" in wined3d_context_gl. > - Things that mostly get accessed from context functions are in > wined3d_context_vk. E.g., "vk_framebuffer" is in that category. That > is itself somewhat influenced by equivalency to things in the GL > backend; wined3d_context_vk_apply_draw_state() is an equivalent of > context_(gl_)apply_draw_state(). > > The basic idea was that it would make it easier to find things for > people already familiar with the GL backend; it does mean some things > are somewhat arbitrary when considering the Vulkan backend on its own. > Thanks, those are good considerations. I would indeed prefer a more functional division, if not strongly per se. I guess I'd be interested to see how helpful the current organization is to someone less familiar with the structure of wined3d...

Nov. 4, 2021

Re: [PATCH v2 7/7] wined3d: Try to allocate new Vulkan BOs from the client thread for DISCARD maps.

by Zebediah Figura

On 11/4/21 7:31 AM, Henri Verbeet wrote: >> +static void wined3d_buffer_vk_set_bo(struct wined3d_buffer *buffer, >> + struct wined3d_context *context, struct wined3d_bo *bo) >> +{ >> + struct wined3d_bo_vk *prev_bo = (struct wined3d_bo_vk *)buffer->buffer_object; >> + struct wined3d_context_vk *context_vk = wined3d_context_vk(context); >> + struct wined3d_buffer_vk *buffer_vk = wined3d_buffer_vk(buffer); >> + struct wined3d_bo_vk *bo_vk = wined3d_bo_vk(bo); >> + >> + /* We can't just copy the contents of bo_vk into buffer_vk->bo, because the >> + * new BO might still be in use by the client thread. We could allow both to >> + * be valid, although knowing when to destroy a BO then becomes tricky, and >> + * ensuring it's not mapped more than once also becomes tricky. */ >> + > Would it make sense then to either make "buffer_vk->bo" a pointer, or > get rid of it entirely? Right now, we're handling the initial bo > different from subsequent ones, and I'm not sure there's a good reason > to justify that. It seems reasonable. I guess in the ideal case we're not going to make much use of buffer_vk->bo anyway. In that case I guess struct wined3d_client_bo_vk doesn't really have much reason to exist. I don't believe I had plans to put anything else in it; I just wanted a way to communicate that the BO belonged to a separate allocation. I'll try to order that patch before this one; it seems feasible. > > Incidentally, now that we have an actual wined3d_bo structure, it > would probably make sense to change the type of "buffer_object" in > e.g. struct wined3d_buffer, struct wined3d_bo_address, etc. from > uintptr_t (and variants) to a wined3d_bo pointer. That's not a > prerequisite for this series, but would probably be a nice cleanup. That one occurred to me as well. (I wasn't sure if there was a reason it wasn't done like that in the first place. Not that wined3d_bo_vk and wined3d_bo_gl used to have anything in common, but at least "void *" would have made more sense...) > >> @@ -3121,12 +3124,20 @@ static bool wined3d_cs_map_upload_bo(struct wined3d_device_context *context, str >> { >> /* Limit NOOVERWRITE maps to buffers for now; there are too many ways that >> * a texture can be invalidated to even count. */ >> - if (wined3d_map_persistent() && resource->type == WINED3D_RTYPE_BUFFER && (flags & WINED3D_MAP_NOOVERWRITE)) >> + if (wined3d_map_persistent() && resource->type == WINED3D_RTYPE_BUFFER >> + && (flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE))) >> { >> struct wined3d_client_resource *client = &resource->client; >> + struct wined3d_device *device = context->device; >> const struct wined3d_bo *bo; >> uint8_t *map_ptr; >> >> + if (flags & WINED3D_MAP_DISCARD) >> + { >> + if (!device->adapter->adapter_ops->adapter_alloc_bo(device, resource, sub_resource_idx, &client->addr)) >> + return NULL; >> + } >> + > Returning NULL here works, but "false" would be more appropriate. > Oops, holdover from an old version of this patch...

Nov. 4, 2021

Re: [PATCH v3 2/3] mshtml: Implement inline attributes parsing for createElement.

by Marvin

Hi, While running your changed tests, 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=101294 Your paranoid android. === w8adm (32 bit report) === mshtml: events.c:1089: Test failed: unexpected call img_onerror events: Timeout === w10pro64_ar (64 bit report) === mshtml: htmldoc.c:2541: Test failed: unexpected call UpdateUI htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS === w10pro64_ja (64 bit report) === mshtml: htmldoc.c:2541: Test failed: unexpected call UpdateUI htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS === w10pro64_he (testbot log) === WineRunTask.pl:error: The previous 1 run(s) terminated abnormally

Nov. 4, 2021

Re: [PATCH v2 5/7] wined3d: Protect wined3d_chunk_vk map fields with a mutex.

by Zebediah Figura

On 11/4/21 7:07 AM, Henri Verbeet wrote: > On Thu, 4 Nov 2021 at 06:04, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >> void *wined3d_allocator_chunk_vk_map(struct wined3d_allocator_chunk_vk *chunk_vk, >> struct wined3d_context_vk *context_vk) >> { >> struct wined3d_device_vk *device_vk = wined3d_device_vk(context_vk->c.device); >> const struct wined3d_vk_info *vk_info = context_vk->vk_info; >> + void *map_ptr; >> VkResult vr; >> >> TRACE("chunk %p, memory 0x%s, map_ptr %p.\n", chunk_vk, >> wine_dbgstr_longlong(chunk_vk->vk_memory), chunk_vk->c.map_ptr); >> >> + wined3d_allocator_chunk_vk_lock(chunk_vk); >> + >> if (!chunk_vk->c.map_ptr && (vr = VK_CALL(vkMapMemory(device_vk->vk_device, >> - chunk_vk->vk_memory, 0, VK_WHOLE_SIZE, 0, &chunk_vk->c.map_ptr))) < 0) >> + chunk_vk->vk_memory, 0, VK_WHOLE_SIZE, 0, &map_ptr))) < 0) >> { >> ERR("Failed to map chunk memory, vr %s.\n", wined3d_debug_vkresult(vr)); >> return NULL; >> } >> + chunk_vk->c.map_ptr = map_ptr; >> > That doesn't work. If the chunk was already mapped (i.e., > "chunk_vk->c.map_ptr" isn't NULL), this will overwrite > "chunk_vk->c.map_ptr" with the uninitialised "map_ptr". > Indeed; I'm surprised that gcc didn't catch that...

Nov. 4, 2021

[PATCH 2/2] evr/mixer: Set per-stream alpha to fully opaque.

by Nikolay Sivov

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> --- dlls/evr/mixer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dlls/evr/mixer.c b/dlls/evr/mixer.c index 2e03535fda3..fb7fcf79d9c 100644 --- a/dlls/evr/mixer.c +++ b/dlls/evr/mixer.c @@ -1326,6 +1326,7 @@ static void video_mixer_render(struct video_mixer *mixer, IDirect3DSurface9 *rt) video_mixer_normalize_rect(&dst, &stream_vis, &norm); video_mixer_scale_rect(&samples[sample_count].DstRect, rt_desc.Width, rt_desc.Height, &norm); + samples[sample_count].PlanarAlpha = DXVA2FloatToFixed(1.0f); sample_count++; } -- 2.33.0

Nov. 4, 2021

[PATCH 1/2] evr/mixer: Pass valid background color parameter to VideoProcessBlt().

by Nikolay Sivov

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> --- Conversion is using coefficients from SDTV ITU-R BT.601, which matches official dxva2 samples, except for RGB values shift by 16, which I don't see in ITU paper. dlls/evr/mixer.c | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/dlls/evr/mixer.c b/dlls/evr/mixer.c index 3a2b6830782..2e03535fda3 100644 --- a/dlls/evr/mixer.c +++ b/dlls/evr/mixer.c @@ -95,7 +95,11 @@ struct video_mixer IMFAttributes *internal_attributes; unsigned int mixing_flags; unsigned int is_streaming; - COLORREF bkgnd_color; + struct + { + COLORREF rgba; + DXVA2_AYUVSample16 ayuv; + } bkgnd_color; LONGLONG lower_bound; LONGLONG upper_bound; CRITICAL_SECTION cs; @@ -1277,7 +1281,6 @@ static void video_mixer_render(struct video_mixer *mixer, IDirect3DSurface9 *rt) zoom_rect.right = zoom_rect.bottom = 1.0f; } - SetRect(&params.TargetRect, 0, 0, rt_desc.Width, rt_desc.Height); video_mixer_scale_rect(&dst, rt_desc.Width, rt_desc.Height, &zoom_rect); for (i = 0; i < mixer->input_count; ++i) @@ -1329,6 +1332,9 @@ static void video_mixer_render(struct video_mixer *mixer, IDirect3DSurface9 *rt) if (SUCCEEDED(hr)) { + SetRect(&params.TargetRect, 0, 0, rt_desc.Width, rt_desc.Height); + params.BackgroundColor = mixer->bkgnd_color.ayuv; + if (FAILED(hr = IDirectXVideoProcessor_VideoProcessBlt(mixer->processor, rt, &params, samples, sample_count, NULL))) { @@ -1983,12 +1989,28 @@ static HRESULT WINAPI video_mixer_processor_GetBackgroundColor(IMFVideoProcessor return E_POINTER; EnterCriticalSection(&mixer->cs); - *color = mixer->bkgnd_color; + *color = mixer->bkgnd_color.rgba; LeaveCriticalSection(&mixer->cs); return S_OK; } +static void video_mixer_rgb_to_ycbcr(COLORREF rgb, DXVA2_AYUVSample16 *ayuv) +{ + int y, cb, cr, r, g, b; + + r = GetRValue(rgb); g = GetGValue(rgb); b = GetBValue(rgb); + /* Coefficients according to SDTV ITU-R BT.601 */ + y = (77 * r + 150 * g + 29 * b + 128) / 256 + 16; + cb = (-44 * r - 87 * g + 131 * b + 128) / 256 + 128; + cr = (131 * r - 110 * g - 21 * b + 128) / 256 + 128; + + ayuv->Y = y * 0x100; + ayuv->Cb = cb * 0x100; + ayuv->Cr = cr * 0x100; + ayuv->Alpha = 0xffff; +} + static HRESULT WINAPI video_mixer_processor_SetBackgroundColor(IMFVideoProcessor *iface, COLORREF color) { struct video_mixer *mixer = impl_from_IMFVideoProcessor(iface); @@ -1996,7 +2018,11 @@ static HRESULT WINAPI video_mixer_processor_SetBackgroundColor(IMFVideoProcessor TRACE("%p, %#x.\n", iface, color); EnterCriticalSection(&mixer->cs); - mixer->bkgnd_color = color; + if (mixer->bkgnd_color.rgba != color) + { + video_mixer_rgb_to_ycbcr(color, &mixer->bkgnd_color.ayuv); + mixer->bkgnd_color.rgba = color; + } LeaveCriticalSection(&mixer->cs); return S_OK; @@ -2528,6 +2554,7 @@ HRESULT evr_mixer_create(IUnknown *outer, void **out) object->upper_bound = MFT_OUTPUT_BOUND_UPPER_UNBOUNDED; video_mixer_init_input(&object->inputs[0]); video_mixer_update_zorder_map(object); + video_mixer_rgb_to_ycbcr(object->bkgnd_color.rgba, &object->bkgnd_color.ayuv); InitializeCriticalSection(&object->cs); if (FAILED(hr = MFCreateAttributes(&object->attributes, 0))) { -- 2.33.0

Nov. 4, 2021