On 11 October 2013 22:51, Frédéric Delanoy wrote:
> -DWORD onesided_enable = FALSE;
> -DWORD twosided_enable = FALSE;
> +DWORD onesided_enable = 0;
> +DWORD twosided_enable = 0;
Actually, all of those initializations are redundant.
On 8 October 2013 13:44, Stefan Dösinger wrote:
> Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode
> is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If
> the application later calls PreLoad manually, texture2d_preload is
> called with SRGB_ANY. Because of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-08 12:06, schrieb Henri Verbeet:
> On 8 October 2013 00:27, Stefan Dösinger
> wrote:
>> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
>> index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++
On 8 October 2013 00:27, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
> index 52eac16..eb8ca7e 100644
> --- a/dlls/wined3d/surface.c
> +++ b/dlls/wined3d/surface.c
> @@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surf
Am 04.10.2013 um 17:15 schrieb Henri Verbeet :
> I guess that makes it ok in practice, but I'd still feel happier about
> this kind of patch if we actually enforced resource access flags
> first. (At which point you could also just check the access flags
> instead of the pool.)
My plan is to enfor
On 4 October 2013 15:51, Stefan Dösinger wrote:
> No codepath in wined3d_surface_blt will attempt to load a sysmem surface into
> a texture. fbo_blit_supported returns FALSE if src or destination are in
> sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills
> will go to a
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger :
> No codepath in wined3d_surface_blt will attempt to load a sysmem surface into
> a texture. fbo_blit_supported returns FALSE if src or destination are in
> sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills
> will go to a
Am 04.10.2013 um 15:28 schrieb Henri Verbeet :
> On 4 October 2013 15:02, Stefan Dösinger wrote:
>> Client storage only applies to GL textures, which won't be created for
>> sysmem surfaces.
>>
> I don't think that's necessarily true at the moment. In particular,
> ddraw blits can in principle
On 4 October 2013 15:02, Stefan Dösinger wrote:
> Client storage only applies to GL textures, which won't be created for sysmem
> surfaces.
>
I don't think that's necessarily true at the moment. In particular,
ddraw blits can in principle cause a texture to be created for sysmem
surfaces. There m
On 4 October 2013 00:03, Stefan Dösinger wrote:
> @@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
> wined3d_surface *surface, void *mem
> /* Now the surface memory is most up do date. Invalidate drawable
> and texture. */
> surface_validate_location(surface,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-03 16:05, schrieb Henri Verbeet:
> I don't think this patch makes sense before you actually unify the
> location management. In particular, after this patch you'd have
> location management in resources that really only does anything
> for
On 3 October 2013 15:03, Stefan Dösinger wrote:
> Am 2013-10-03 13:45, schrieb Henri Verbeet:
>> It sounds like you have some ordering issues in that patch set.
> Correct. Patches before patch 24 shouldn't be affected by that though.
> I didn't get around to splitting and recombining patch 24 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-03 13:45, schrieb Henri Verbeet:
> On 3 October 2013 13:22, Stefan Dösinger
> wrote:
>> Will be updated as well. See
>> http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html
>>
>>
for the surface part and more explanations.
On 3 October 2013 13:22, Stefan Dösinger wrote:
> Am 2013-10-03 13:14, schrieb Henri Verbeet:
>> On 3 October 2013 13:08, Stefan Dösinger
>> wrote:
>>> --- dlls/wined3d/volume.c | 46
>>> +++++-
>>> dlls/win
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-03 13:14, schrieb Henri Verbeet:
> On 3 October 2013 13:08, Stefan Dösinger
> wrote:
>> --- dlls/wined3d/volume.c | 46
>> +-----
>> dlls/wined3d/wined3d_private.h |
On 3 October 2013 13:08, Stefan Dösinger wrote:
> ---
> dlls/wined3d/volume.c | 46
> +-
> dlls/wined3d/wined3d_private.h | 6 --
> 2 files changed, 27 insertions(+), 25 deletions(-)
>
What about surfaces and buffers?
Please split this.
ng CS ops from inside the CS are probably blits, and
perhaps resource maps. The basic rule should probably be that anything
that makes wined3d_cs_emit_*() calls should only have callers outside
of wined3d, which shouldn't be too hard to verify.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-27 14:19, schrieb Henri Verbeet:
> Perhaps, I'm not sure. For that kind of comment to be useful it
> should have a clear set of implications, and I'm not sure it has
> that until we work out the details of the multi-threaded
> implementation
On 27 September 2013 13:05, Stefan Dösinger wrote:
> I think we should place comments like "This function is called through
> the command stream" for all functions that are called through the CS,
> similar to what we do for context activation.
>
Perhaps, I'm not sure. For that kind of comment to b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-27 00:15, schrieb Henri Verbeet:
> -swapchain->swapchain_ops->swapchain_present(swapchain,
> src_rect, dst_rect, dirty_region, flags); +
> wined3d_cs_emit_present(swapchain->device->cs, swapchain,
> src_rect, +dst_rect, dst_w
On 23 September 2013 21:05, Alexandre Julliard wrote:
> Henri Verbeet writes:
>
>> ---
>> dlls/wined3d/device.c | 51
>> +--------
>> dlls/wined3d/stateblock.c |5 +
>> 2 files changed, 20 insertions(+), 36 d
Henri Verbeet writes:
> ---
> dlls/wined3d/device.c | 51
> +
> dlls/wined3d/stateblock.c |5 +
> 2 files changed, 20 insertions(+), 36 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M dxg
On 20 September 2013 13:04, Stefan Dösinger wrote:
> +static BOOL wined3d_volume_can_evict(const struct wined3d_volume *volume)
> +{
> +if (volume->resource.pool != WINED3D_POOL_MANAGED)
> +return FALSE;
> +if (volume->download_count < 10)
> +return FALSE;
That doesn't look
On 20 September 2013 13:04, Stefan Dösinger wrote:
> -volume->flags &= ~(WINED3D_VFLAG_ALLOCATED |
> WINED3D_VFLAG_SRGB_ALLOCATED);
> +volume->flags &= ~(WINED3D_VFLAG_ALLOCATED | WINED3D_VFLAG_SRGB_ALLOCATED
> +| WINED3D_VFLAG_CLIENT_STORAGE);
>
Indentation looks a bit off here.
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://newtestbot.winehq.org/JobDetails.pl?Key=2232
Your paranoid andr
On 17 September 2013 21:07, Stefan Dösinger wrote:
> I might have misunderstood what you meant with "separate flags for
> each GL resource type". Did you mean something like this
>
> B8G8R8A8_UNORM.flags[texture2d] = RENDERTARGET | TEXTURE | ...;
> B8G8R8A8_UNORM.flags[renderbuffer] = RENDERTARGET
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 17:12, schrieb Henri Verbeet:
> The point is that the distinction you're making here between
> volumes and everything else is a bit arbitrary, and I think this
> patch as it is will make it more work rather than less to move
> towards hav
On 17 September 2013 16:52, Stefan Dösinger wrote:
> Am 2013-09-17 13:55, schrieb Henri Verbeet:
>> I don't like this approach much. I think we should either do the
>> right thing right away and have separate flags for each GL resource
>> type (i.e., vertex/index buffers, renderbuffers,
>> 1D/2D/3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 13:55, schrieb Henri Verbeet:
> I don't like this approach much. I think we should either do the
> right thing right away and have separate flags for each GL resource
> type (i.e., vertex/index buffers, renderbuffers,
> 1D/2D/3D/CUBE/RECT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 15:05, schrieb Henri Verbeet:
> I was mostly thinking of merging e.g. wined3d_surface_get_pitch()
> and wined3d_volume_get_pitch() into wined3d_resource_get_pitch(). I
> don't feel strongly about doing that first though, so if you're
> sa
On 17 September 2013 14:58, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-17 13:55, schrieb Henri Verbeet:
>> On 17 September 2013 11:39, Stefan Dösinger
>> wrote:
>>&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 13:55, schrieb Henri Verbeet:
> On 17 September 2013 11:39, Stefan Dösinger
> wrote:
>> --- dlls/wined3d/volume.c | 95
>> +++ 1 file
>> changed, 88 in
On 17 September 2013 11:39, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
> index 4928f92..eabf890 100644
> --- a/dlls/wined3d/wined3d_private.h
> +++ b/dlls/wined3d/wined3d_private.h
> @@ -2927,6 +2927,7 @@ extern enum wi
On 17 September 2013 11:39, Stefan Dösinger wrote:
> ---
> dlls/wined3d/volume.c | 95
> +++
> 1 file changed, 88 insertions(+), 7 deletions(-)
>
Can't most of this be done on the resource level instead?
On 11 September 2013 13:37, Stefan Dösinger wrote:
> The next element is a BYTE. The 8 bits padding were stupid considering
> that, it just generates a hole. Now I am removing one bit, which
> leaves one bit of padding left.
>
It doesn't really work like that, the layout is like this:
UINT (4)
WO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-11 13:32, schrieb Henri Verbeet:> On 11 September 2013
11:31, Stefan Dösinger wrote:
>> @@ -1880,9 +1888,8 @@ struct wined3d_device WORD d3d_initialized
>> : 1; WORD inScene : 1; /* A flag to check for
proper BeginScene /
On 11 September 2013 11:31, Stefan Dösinger wrote:
> -/* Reading the declaration makes only sense if the stateblock is
> finalized and the buffer bound to a stream */
> -if (device->isInDraw && buffer->resource.bind_count > 0)
> +/* Reading the declaration makes only sense if we have
On 11 September 2013 11:31, Stefan Dösinger wrote:
> @@ -330,7 +331,7 @@ static BOOL buffer_find_decl(struct wined3d_buffer *This)
> if(This->resource.usage & WINED3DUSAGE_STATICDECL) return FALSE;
> }
>
> -if (use_vs(state))
> +if (fixup_flags & WINED3D_BUFFER_FIXUP_USE_SHAD
On 11 September 2013 11:31, Stefan Dösinger wrote:
> @@ -1880,9 +1888,8 @@ struct wined3d_device
> WORD d3d_initialized : 1;
> WORD inScene : 1; /* A flag to check for proper
> BeginScene / EndScene call pairs */
> WORD softwareVertexProcessing : 1; /* process ve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-09 13:55, schrieb Henri Verbeet:
> Not strictly, but I think it helps with keeping track of how much
> bits are left and avoiding silly things like holes in the
> structure.
Fair enough. Please ignore patches 4 and 5 for today, I'll take m
On 9 September 2013 13:49, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-09 13:42, schrieb Henri Verbeet:
>> I think that's an unfortunate place to insert the field, and you
>> should update the padding.
>>
@@ -1880,9 +1889,7 @@ struct wined3d_device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-09 13:42, schrieb Henri Verbeet:
> I think that's an unfortunate place to insert the field, and you
> should update the padding.
>
>>> @@ -1880,9 +1889,7 @@ struct wined3d_device WORD
>>> d3d_initialized : 1; WORD inScene : 1;
On 9 September 2013 12:56, Stefan Dösinger wrote:
> -static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct
> wined3d_context *context)
> +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct
> wined3d_context *context,
> +const struct wined3d_state *sta
even just the use_map field.
> -static BOOL buffer_find_decl(struct wined3d_buffer *This)
> +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct
> wined3d_context *context)
Same.
> diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
> index
On 9 September 2013 12:56, Stefan Dösinger wrote:
> @@ -148,7 +149,7 @@ static void buffer_create_buffer_object(struct
> wined3d_buffer *This, const struc
> }
>
> if (This->buffer_type_hint == GL_ELEMENT_ARRAY_BUFFER_ARB)
> -device_invalidate_state(This->resource.device, STATE_I
rly, dlls/ddraw/device.c calls set_render_target to set the
> ddraw frontbuffer on release. The call fails now, but that doesn't
> cause any visible problems yet. There is a zombie wined3d surface
> left, but it goes away on ddraw shutdown or when a new ddraw
> IDirect3DDevice is
_target to set the
ddraw frontbuffer on release. The call fails now, but that doesn't
cause any visible problems yet. There is a zombie wined3d surface
left, but it goes away on ddraw shutdown or when a new ddraw
IDirect3DDevice is created.
However, when we create wined3d textures for standalone surf
ted when needed. Tests
> are also added.
>
> Thanks to Matteo Bruni for review and support.
>
> Try 2:
> - update with latest git
Hi, I have a few small nits still, please bear with me...
> ---
> dlls/d3d9/tests/visual.c | 80
> ++++++++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 13:41, schrieb Henri Verbeet:> It ends up being a
performance bottleneck in some cases. This is
> particularly visible in the 3DMark03 multi-texture fill-rate test,
> in other cases the impact is usually a bit more modest.
That's interest
On 3 September 2013 13:31, Stefan Dösinger wrote:
> The idea behind the clamps is that the fixed function pipeline is
> generally limited to the [0.0;1.0] range. bbf313e7 added a test for
> that, and there was e.g. 14706 (which doesn't contain much info tbh).
>
Yes, but that's for stage operations
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-03 09:47, schrieb Henri Verbeet:
> This originally came from the ARB fragment program implementation,
> but I don't see a justification for clamping there either. For the
> texture formats typically used with the fixed function pipe
> clampi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-30 17:50, schrieb Henri Verbeet:
> Well, regardless of which one it is, I don't see a similar check
> for 2D and cube textures at the moment. I think some tests would
> be welcome.
You are right, there's neither a check nor tests. I am certa
On 30 August 2013 00:19, Stefan Dösinger wrote:
> +if (format->flags & WINED3DFMT_FLAG_BLOCKS)
> +{
> +UINT width_mask = format->block_width - 1;
> +UINT height_mask = format->block_height - 1;
> +if (desc->width & width_mask || desc->height & height_mask)
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-30 17:31, schrieb Henri Verbeet:
> On 30 August 2013 00:19, Stefan Dösinger
> wrote:
>> +if (format->flags & WINED3DFMT_FLAG_BLOCKS) +{ +
>> UINT width_mask = format->block_width - 1; +UINT
>> height_mask = format->block_hei
On 30 August 2013 17:35, Stefan Dösinger wrote:
> Am 2013-08-30 17:31, schrieb Henri Verbeet:
>> Is this different from surfaces? IIRC surfaces are padded up to
>> the next multiple of the block size, although I may have that
>> wrong. Not a fan of the "(%p) : " trace formatting.
> Padding happens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-26 16:16, schrieb Matteo Bruni:
> 2013/8/26 Stefan Dösinger :
>> Try 2: *) Require only GPU access for buffers *) Reduce number of
>> checkGLcall invocations *) Remove a return from an ERR case ---
>> dlls/wined3d/ut
2013/8/26 Stefan Dösinger :
> Try 2:
> *) Require only GPU access for buffers
> *) Reduce number of checkGLcall invocations
> *) Remove a return from an ERR case
> ---
> dlls/wined3d/utils.c | 1 +
> dlls/wined3d/vo
Stefan Dösinger writes:
> ---
> dlls/wined3d/volume.c | 7 +++
> 1 file changed, 7 insertions(+)
It breaks the tests:
../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p
d3dx9_36_test.exe.so volume.c && touch volume.ok
volume.c:187: Test succeeded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-23 14:01, schrieb Henri Verbeet:
> On 23 August 2013 13:54, Stefan Dösinger
> wrote:
>> The rules for surfaces and volumes aren't applicable to buffers
>> anyway. A default pool buffer without D3DUSAGE_DYNAMIC is
>> mappable for example.
>
On 23 August 2013 13:54, Stefan Dösinger wrote:
> The rules for surfaces and volumes aren't applicable to buffers
> anyway. A default pool buffer without D3DUSAGE_DYNAMIC is mappable for
> example.
>
I don't think the differences are insurmountable, but the main point
is still that I think this is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-23 12:29, schrieb Henri Verbeet:
> On 23 August 2013 12:04, Stefan Dösinger
> wrote:
>>
>> Am 23.08.2013 um 11:34 schrieb Henri Verbeet
>> :
>>> Why does loading into a PBO require CPU access?
>> The only reason why we want to store a volu
On 23 August 2013 12:04, Stefan Dösinger wrote:
>
> Am 23.08.2013 um 11:34 schrieb Henri Verbeet :
>> Why does loading into a PBO require CPU access?
> The only reason why we want to store a volume in a PBO is to map it, which
> requires CPU access. If the volume doesn't allow CPU access I don't
Am 23.08.2013 um 11:34 schrieb Henri Verbeet :
> Why does loading into a PBO require CPU access?
The only reason why we want to store a volume in a PBO is to map it, which
requires CPU access. If the volume doesn't allow CPU access I don't see a
reason to load it into a PBO.
Well, there's RGB<-
On 22 August 2013 23:22, Stefan Dösinger wrote:
> @@ -145,6 +158,9 @@ static DWORD volume_access_from_location(DWORD location)
> case WINED3D_LOCATION_TEXTURE_RGB:
> return WINED3D_RESOURCE_ACCESS_GPU;
>
> +case WINED3D_LOCATION_BUFFER:
> +return WINED3D_R
On 22 August 2013 03:31, Gediminas Jakutis wrote:
> +{"GTX 770", CARD_NVIDIA_GEFORCE_GTX770},/* Geforce 700 -
> highend */
> {"GTX 770M",CARD_NVIDIA_GEFORCE_GTX770M}, /* Geforce 700 -
> midend high mobile */
That doesn't work, it will always match "GTX 770
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-22 15:33, schrieb Henri Verbeet:
> On 22 August 2013 14:57, Stefan Dösinger
> wrote:
>> +if (volume->locations & WINED3D_LOCATION_DISCARDED)
>> +{ +TRACE("Volume previously
>> discarded, nothing to d
On 22 August 2013 14:57, Stefan Dösinger wrote:
> +if (volume->locations & WINED3D_LOCATION_DISCARDED)
> +{
> +TRACE("Volume previously discarded, nothing to do.\n");
> +wined3d_volume_invalidate_location(volume,
> WINED3D_LOCATION_DISCARDED
On 22 August 2013 13:32, Stefan Dösinger wrote:
> Is it ok to worry about this later and just remove
> WINED3D_RESOURCE_ACCESS_SCRATCH for now?
>
Sure.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-22 13:14, schrieb Henri Verbeet:
> On 22 August 2013 13:07, Stefan Dösinger
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> Am 2013-08-22 12:58, schrieb Henri Verbeet:
>>> Yes, but if "pool" goes away we need some other way
a bunch of other restrictions we don't currently check on resource
creation either, but that's not the point here.) So we need some way
to determine if a resource is a scratch resource or not in wined3d, at
the very least on resource creation.
ol goes to d3d8/9, the checks should go to d3d8/9 as well.
There's an argument to be made that we shouldn't create wined3d
resources for scratch resources at all, but that'd mean cloning a big
amount of logic in those libs.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/
On 22 August 2013 11:53, Stefan Dösinger wrote:
> I think it's best to check the pool in operations that accept a
> resource as parameter. We already do that in most places.
Yes, but if "pool" goes away we need some other way to check for
scratch resources. It's just that in retrospect the access
is to
> eventually push the concept of pools out into d3d8 and d3d9, and
> just have access flags in wined3d, but we'd still need to be able
> to distinguish scratch resources from sysmem resources somehow. At
> the moment I'm thinking the better option would be to pass that
t either. The issue is that
scratch resources allow some extra formats over sysmem resources, but
can't be used for resource uploads. The idea is to eventually push the
concept of pools out into d3d8 and d3d9, and just have access flags in
wined3d, but we'd still need to be able to distingui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-22 09:11, schrieb Henri Verbeet:
> On 22 August 2013 00:30, Stefan Dösinger
> wrote:
>> +const char *wined3d_debug_location(DWORD location) +{ +char
>> buf[238];
> That number looks a bit arbitrary, although I suppose it's at
> least la
On 22 August 2013 00:30, Stefan Dösinger wrote:
> +const char *wined3d_debug_location(DWORD location)
> +{
> +char buf[238];
That number looks a bit arbitrary, although I suppose it's at least
large enough.
> +if (volume->resource.pool == WINED3D_POOL_SYSTEM_MEM
> +|| volume->
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-21 12:43, schrieb Alexandre Julliard:> 8 0x68e5fba9
wined3d_texture_decref+0x48(texture=)
[/home/julliard/wine/wine/dlls/wined3d/texture.c:449] in wined3d
(0x0032fb28)
This is an existing bug, when running the tests often enough with
ome/julliard/wine/wine/dlls/ntdll/heap.c:1771] in ntdll (0x0032f9a8)
3 0x68e0642e wined3d_resource_free_sysmem+0x2d(mem=0x1642c0)
[/home/julliard/wine/wine/dlls/wined3d/resource.c:361] in wined3d (0x0032f9d8)
4 0x68e06503 resource_cleanup+0xc2(resource=0x1651e0)
[/home/julliard/wine/wine/dlls/
On 20 August 2013 13:16, Stefan Dösinger wrote:
> Am 2013-08-20 13:12, schrieb Henri Verbeet:
>> Somewhat related, I don't think there's really a reason to have
>> both "allocatedMemory" and "heap_memory" anymore. It should
>> probably just be called "sysmem". That's a cleanup that doesn't
>> nece
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-20 13:12, schrieb Henri Verbeet:
> I think this should either be called
> wined3d_resource_allocate_sysmem() and live in resource.c, or
> accept any np2 alignment and be called something along the lines of
> wined3d_memalign(). The former
On 20 August 2013 12:07, Stefan Dösinger wrote:
> +void *wined3d_alloc_resource_mem(SIZE_T size)
> +{
> +void **p;
> +SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p);
> +void *mem;
> +
> +if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + align)))
> +return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 17:08, schrieb Stefan Dösinger:
> I'm not entirely sure about the SIZE_T align = RESOURCE_ALIGNMENT -
> 1 + sizeof(*p); line though. Msvcrt doesn't have the - 1, and
> allocating size + RESOURCE_ALIGNMENT bytes might be enough. msvcrt
> a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 14:34, schrieb Henri Verbeet:
> On 19 August 2013 14:20, Stefan Dösinger
> wrote:
>> Am 2013-08-19 13:53, schrieb Henri Verbeet:
>>> That's actually a bug in what I posted.
>> What's your suggested fix? Allocating size + align + alignmen
On 19 August 2013 14:20, Stefan Dösinger wrote:
> Am 2013-08-19 13:53, schrieb Henri Verbeet:
>> That's actually a bug in what I posted.
> What's your suggested fix? Allocating size + align + alignment, and
> adding alignment to mem if mem happens to be already aligned?
>
I think it needs to be "a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 13:53, schrieb Henri Verbeet:
> On 19 August 2013 13:38, Stefan Dösinger
> wrote:
>> I guess in theory any kind of payload could be added to your
>> implementation, but growing this larger than
>> RESOURCE_ALIGNMENT(=16) bytes moots the
er term sub-resources like surfaces and volumes as separate
objects will go away from the public interface completely, similar to
d3d10 and later, and we can just create them directly from the texture
in wined3d.
On 19 August 2013 13:38, Stefan Dösinger wrote:
> I guess in theory any kind of payload could be added to your
> implementation, but growing this larger than RESOURCE_ALIGNMENT(=16)
> bytes moots the point I guess.
The point is mostly that I don't think we want the wined3d_heap_memory
structure to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 12:39, schrieb Henri Verbeet:
> On 19 August 2013 10:52, Stefan Dösinger
> wrote:
>> +void wined3d_volume_set_texture_level(struct wined3d_volume
>> *volume, GLint level) +{ +volume->texture_level = level; +}
>>
> I think that's a s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 12:31, schrieb Henri Verbeet:
> On 19 August 2013 10:52, Stefan Dösinger
> wrote:
>> @@ -184,7 +184,16 @@ HRESULT CDECL wined3d_volume_map(struct
>> wined3d_volume *volume, volume, map_desc, box, flags);
>>
>> if (!volume->resource.allo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 12:29, schrieb Henri Verbeet:
> I don't think this is a good idea. How about something like the
> following? The corresponding free function would be trivial.
I guess this works for the purposes of this patchset. However, in my
command s
On 19 August 2013 10:52, Stefan Dösinger wrote:
> +void wined3d_volume_set_texture_level(struct wined3d_volume *volume, GLint
> level)
> +{
> +volume->texture_level = level;
> +}
>
I think that's a step in the wrong direction. I think this should be
set on volume creation. We do have a constr
On 19 August 2013 10:52, Stefan Dösinger wrote:
> +volume->flags |= WINED3D_VFLAG_LOCKABLE; /* FIXME */
You'll probably want to fix that :-) I think you can just leave the
flag out until you rename it to WINED3D_VFLAG_MAPPABLE in one of the
later patches.
On 19 August 2013 10:52, Stefan Dösinger wrote:
> @@ -184,7 +184,16 @@ HRESULT CDECL wined3d_volume_map(struct wined3d_volume
> *volume,
> volume, map_desc, box, flags);
>
> if (!volume->resource.allocatedMemory)
> -volume->resource.allocatedMemory = HeapAlloc(GetProcess
On 19 August 2013 10:52, Stefan Dösinger wrote:
> +struct wined3d_heap_memory *wined3d_alloc_resource_mem(UINT size)
> +{
> +struct wined3d_heap_memory *ret;
> +
> +ret = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*ret));
> +if (!ret)
> +return NULL;
> +
> +ret->a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henri, Matteo,
When reviewing those patches, please have a look at the attached
archive. It contains the rest of the volume cleanup patches and some
tests.
Cheers,
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Usin
On 22 July 2013 20:24, Matteo Bruni wrote:
> @@ -3614,10 +3614,19 @@ void wined3d_ffp_get_vs_settings(const struct
> wined3d_state *state, const struct
> & WINED3D_FFP_LIGHT_TYPE_MASK) <<
> WINED3D_FFP_LIGHT_TYPE_SHIFT(i);
> }
>
> +settings->ortho_fog = 0;
> if
Le 26/06/2013 09:10, Henri Verbeet a écrit :
On 25 June 2013 18:26, Stefan Dösinger wrote:
While I agree with Henri's statement to some extend - patch reviewing
is a terribly exhausting task - I think the statement was a bit harsh
to say to someone who donates his personal time to the project.
On 26 June 2013 03:53, Austin English wrote:
> My understanding was that using the _WIN64 macro was preferred. I can
> certainly do that instead. How's this?
>
I could probably live with that, though perhaps make it a helper
function, and I'm not entirely sure this will print something
meaningful
On 25 June 2013 18:26, Stefan Dösinger wrote:
> While I agree with Henri's statement to some extend - patch reviewing
> is a terribly exhausting task - I think the statement was a bit harsh
> to say to someone who donates his personal time to the project.
>
Well, I could try to sugarcoat it a bit,
1 - 100 of 3109 matches
Mail list logo
