Re: wined3d: Use BOOL type where appropriate

2013-10-11 Thread Henri Verbeet
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.

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

2013-10-08 Thread Henri Verbeet
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

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

2013-10-08 Thread Stefan Dösinger
-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 +++

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

2013-10-08 Thread 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 > +++ b/dlls/wined3d/surface.c > @@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surf

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Stefan Dösinger
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Stefan Dösinger
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Stefan Dösinger
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread 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 cause a texture to be created for sysmem surfaces. There m

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Henri Verbeet
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,

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

2013-10-03 Thread Stefan Dösinger
-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

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

2013-10-03 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

2013-10-03 Thread Stefan Dösinger
-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.

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

2013-10-03 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

2013-10-03 Thread Stefan Dösinger
-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 |

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

2013-10-03 Thread Henri Verbeet
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?

Re: [PATCH 2/5] wined3d: Move location management into the resource.

2013-10-01 Thread Henri Verbeet
Please split this.

Re: [PATCH 1/5] wined3d: Send present operations through a command stream.

2013-09-27 Thread Henri Verbeet
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.

Re: [PATCH 1/5] wined3d: Send present operations through a command stream.

2013-09-27 Thread Stefan Dösinger
-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

Re: [PATCH 1/5] wined3d: Send present operations through a command stream.

2013-09-27 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Send present operations through a command stream.

2013-09-27 Thread Stefan Dösinger
-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

Re: [PATCH 3/5] wined3d: Introduce a function to initialize swapchain specific device state.

2013-09-24 Thread Henri Verbeet
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

Re: [PATCH 3/5] wined3d: Introduce a function to initialize swapchain specific device state.

2013-09-23 Thread Alexandre Julliard
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

Re: [PATCH 2/6] wined3d: Add support for converted volumes.

2013-09-20 Thread Henri Verbeet
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

Re: [PATCH 6/6] wined3d: Use GL_APPLE_client_storage for volumes if available.

2013-09-20 Thread Henri Verbeet
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.

Re: [PATCH 3/8] wined3d: Check for support before creating volume textures.

2013-09-18 Thread 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://newtestbot.winehq.org/JobDetails.pl?Key=2232 Your paranoid andr

Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.

2013-09-18 Thread Henri Verbeet
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

Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.

2013-09-17 Thread Stefan Dösinger
-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

Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.

2013-09-17 Thread Henri Verbeet
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

Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.

2013-09-17 Thread Stefan Dösinger
-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

Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.

2013-09-17 Thread Stefan Dösinger
-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

Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.

2013-09-17 Thread Henri Verbeet
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

Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.

2013-09-17 Thread Stefan Dösinger
-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

Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.

2013-09-17 Thread Henri Verbeet
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

Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.

2013-09-17 Thread Henri Verbeet
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?

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context.

2013-09-11 Thread Henri Verbeet
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

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context.

2013-09-11 Thread Stefan Dösinger
-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 /

Re: [PATCH 5/5] wined3d: Explicitly pass the state information to buffer_internal_preload

2013-09-11 Thread Henri Verbeet
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

Re: [PATCH 3/5] wined3d: Pass stream info and needed fixups to buffer_find_decl.

2013-09-11 Thread Henri Verbeet
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

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context.

2013-09-11 Thread 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 / EndScene call pairs */ > WORD softwareVertexProcessing : 1; /* process ve

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context

2013-09-09 Thread Stefan Dösinger
-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

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context

2013-09-09 Thread Henri Verbeet
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

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context

2013-09-09 Thread Stefan Dösinger
-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;

Re: [PATCH 5/5] wined3d: Explicitly pass the state information to buffer_internal_preload

2013-09-09 Thread Henri Verbeet
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

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context

2013-09-09 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Don't mess with the device in buffer_create_buffer_object

2013-09-09 Thread Henri Verbeet
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

Re: [PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.

2013-09-04 Thread Henri Verbeet
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

Re: [PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.

2013-09-04 Thread Stefan Dösinger
_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

Re: [PATCH] wined3d: Fix per-stage constant in GLSL fixed function pipeline + add tests. (try 2)

2013-09-04 Thread Matteo Bruni
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 > ++++++++

Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.

2013-09-03 Thread Stefan Dösinger
-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

Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.

2013-09-03 Thread Henri Verbeet
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

Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.

2013-09-03 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions

2013-08-30 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions

2013-08-30 Thread 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_height - 1; > +if (desc->width & width_mask || desc->height & height_mask) > +

Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions

2013-08-30 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions

2013-08-30 Thread Henri Verbeet
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

Re: [PATCH 2/7] wined3d: Use PBOs for dynamic volumes (try 2)

2013-08-26 Thread Stefan Dösinger
-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

Re: [PATCH 2/7] wined3d: Use PBOs for dynamic volumes (try 2)

2013-08-26 Thread 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/utils.c | 1 + > dlls/wined3d/vo

Re: [PATCH 4/6] wined3d: Enforce volume mapping restrictions

2013-08-23 Thread Alexandre Julliard
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

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

2013-08-23 Thread Stefan Dösinger
-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. >

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

2013-08-23 Thread 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. > I don't think the differences are insurmountable, but the main point is still that I think this is

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

2013-08-23 Thread Stefan Dösinger
-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

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

2013-08-23 Thread 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 volume in a PBO is to map it, which > requires CPU access. If the volume doesn't allow CPU access I don't

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

2013-08-23 Thread Stefan Dösinger
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<-

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

2013-08-23 Thread Henri Verbeet
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

Re: wined3d: Recognize Nvidia GeForce GTX 770

2013-08-22 Thread Henri Verbeet
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

Re: [PATCH 6/6] wined3d: Implement basic volume location management (try 2)

2013-08-22 Thread Stefan Dösinger
-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

Re: [PATCH 6/6] wined3d: Implement basic volume location management (try 2)

2013-08-22 Thread Henri Verbeet
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

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Henri Verbeet
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.

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Henri Verbeet
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.

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Stefan Dösinger
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/

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Henri Verbeet
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

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Stefan Dösinger
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

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Henri Verbeet
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

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Implement basic volume location management

2013-08-22 Thread 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 large enough. > +if (volume->resource.pool == WINED3D_POOL_SYSTEM_MEM > +|| volume->

Re: wined3d: Add a function for allocating aligned resource, memory (try 3)

2013-08-21 Thread Stefan Dösinger
-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

Re: wined3d: Add a function for allocating aligned resource, memory (try 3)

2013-08-21 Thread Alexandre Julliard
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/

Re: [PATCH 1/5] wined3d: Add a function for allocating aligned resource memory (try 2)

2013-08-20 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Add a function for allocating aligned resource memory (try 2)

2013-08-20 Thread Stefan Dösinger
-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

Re: [PATCH 1/5] wined3d: Add a function for allocating aligned resource memory (try 2)

2013-08-20 Thread Henri Verbeet
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

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread 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 + alignment, and > adding alignment to mem if mem happens to be already aligned? > I think it needs to be "a

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Store the mipmap level in the volume

2013-08-19 Thread Henri Verbeet
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.

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread 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 point I guess. The point is mostly that I don't think we want the wined3d_heap_memory structure to

Re: [PATCH 5/5] wined3d: Store the mipmap level in the volume

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 3/5] wined3d: Properly allocate heap memory for volumes

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 5/5] wined3d: Store the mipmap level in the volume

2013-08-19 Thread 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 step in the wrong direction. I think this should be set on volume creation. We do have a constr

Re: [PATCH 4/5] wined3d: Move volume booleans into a flags field

2013-08-19 Thread Henri Verbeet
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.

Re: [PATCH 3/5] wined3d: Properly allocate heap memory for volumes

2013-08-19 Thread 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.allocatedMemory) > -volume->resource.allocatedMemory = HeapAlloc(GetProcess

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure

2013-08-19 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Keep GL_UNPACK_CLIENT_STORAGE_APPLE off by default

2013-08-19 Thread Stefan Dösinger
-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

Re: [PATCH 1/2] wined3d: Implement special fog behavior for orthogonal projection matrices.

2013-07-23 Thread Henri Verbeet
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

Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.

2013-06-26 Thread Christian Costa
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.

Re: wined3d: print the architecture when showing driver problems

2013-06-26 Thread Henri Verbeet
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

Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.

2013-06-26 Thread Henri Verbeet
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   2   3   4   5   6   7   8   9   10   >