d3dx9: Implement D3DXSHMultiply5

wined3d: Add a registry key to configure buffer object placement

This can provide huge speed improvements in some games, but please test it properly
before recommending it in HOWTOs.

d3d9: Make IDirect3DDevice9Ex::PresentEx hookable.

Fraps hooks this without minding the existing code.

wined3d: Completely reset the state on reset.

wined3d: Send palette updates through the command stream.

Right now the main purpose of this patch is to avoid a context
activation issue in the ddraw tests that was triggered by the
context_acquire call in the main thread. It is barely tested and missing
some pieces, like a synchronization concept that is better than just
waiting for the CS to finish.

d3d9/tests: D3DLOCK_NO_DIRTY_UPDATE on managed textures is temporarily broken.

d3d8/tests: D3DLOCK_NO_DIRTY_UPDATE on managed textures is temporarily broken.

wined3d: Fence preload operations.

Otherwise texture data might get lost, thanks to surface/volume_evict_sysmem:

1) preload(texture)
2) map(texture)
    -> Loads sysmem / sets it with discard map.
3) unmap(texture)
    -> enqueues a resource_changed operation
4) preload is executed.
    -> Uploads data written in 3. Discards sysmem. Questionable if
       DISCARD was passed, but without it, no harm done.
    -> texture is only up to date location.
5) resource_changed executed.
    -> Discards texture.

And data is lost. This patch prevents that by stalling the map until the
PreLoad is done.

What's left open is finding out why anyone (I'm looking at you EVE
online) preloads a texture right before mapping it...

wined3d: Use an event to block the worker thread when it is idle.

I could not find a canonical implementation for this. Suggestions are
welcome.

The main goal was to avoid SetEvent / WaitForSingleObject / ResetEvent
calls at all costs. They go straight to wineserver, bringing it to 25%
CPU time and cutting framerates in half. Hence the extra BOOL to tell
cs_submit when to set the event.

Finding the correct spin count is tricky. The value I set is high enough
to prevent 3DMark2001 car chase high detail from waiting. This benchmark
maps a lot of in-use managed buffers and thus waits for the CS. But what
the ideal number is depends a lot on the game and CPU.

A better heuristic is needed. E.g. we could tell the worker thread when
the main thread is waiting for a resource to become idle and avoid
waiting for the event in that case. We may have to use POSIX
synchronization primitives for efficiency. On the other hand, the
current implementation probably still spins way too much for an
application that throttles the framerate to 30 fps by waiting in its own
code. So it is probably only good enough for Microsoft Powerpoint.

We should also think about blocking the main thread with events if it is
waiting for the worker thread when waiting for resources, the swap
counter or space in the command Stream. This should preserve power when
vsync is turned on.

wined3d: Don't switch directly from one context to another (hack).

Switching from one context to another non-NULL context and then deleting
the original context triggers a bug in the Nvidia blob that causes a
crash on process cleanup. Other context changes on the same thread can
undo the damage. So usually we don't see the problem because the device
creation / destruction hides the problem.

The next patch however will eliminate the GL context for all threads
except the worker thread, uncovering this bug. Clearing the context
before activating the new one avoids the problem. This can be seen in
the ddraw overlay and d3d8/9 stateblock tests.

I must admit that I don't fully understand it yet. I haven't tried to
reproduce the issue in a stand-alone application yet, and for some
reason the crash occurs in the worker thread instead of the main thread,
but long after the worker thread has ended, and after THREAD_DETACH and
PROCESS_DETACH events have been processed. Lots of context activation /
deactivation activity in the worker can also hide the bug. In theory the
single threaded command stream should show this problem if an
application only creates a IDirect3D9 object without creating a device,
destroys it and then exits.

wined3d: Invoke surface_unload through the CS in wined3d_surface_update_desc.

This fixes another case where we use a GL context in the main thread and
crash fglrx in doing so.

wined3d: Delete GL contexts through the CS in uninit_3d.

wined3d: Delete GL contexts through the CS in reset.

Let's see if this fixes the remaining fglrx crashes...

wined3d: Ignore WINED3D_MAP_NO_DIRTY_UPDATE in resource_map.

TODO: This flag and add_dirty_rect need tests.

The primary purpose of this patch is to fix a memory leak in World of
Warcraft. WoW uses WINED3D_MAP_NO_DIRTY_UPDATE | WINED3D_MAP_DISCARD on
sysmem surfaces. A new block of memory is allocated, but never assigned
to heap_mem because wined3d_cs_emit_resource_changed is not called.

The bigger picture is that we don't know how this flag and AddDirtyRect
/ AddDirtyBox are supposed to work. Msdn mentions some interaction with
update_surface and update_texture, but personally I think it is more
likely that this functionality is used to update separate rectangles in
a texture, similar to what can be achieved by mapping a buffer twice.

wined3d: Recreate ctx and dummy textures through the CS after resets.

wined3d: Create the initial context through the CS.

Very hacky.

wined3d: Create dummy textures through the CS.

Hacky version. Just good enough to see if the double context during init is what makes fglrx
crash.

wined3d: Remove software cursor support.

This has been broken since quite some time and only serves to crash fglrx by acquiring a context
in the main thread.

FIXME: Make sure wined3d_device_show_cursor returns the correct value if a software cursor is set.

wined3d: Don't glFinish after a depth buffer blit.

wined3d: Unload resources through the CS in device_reset.

wined3d: Unload resources through the CS in uninit_3d.

wined3d: Clean up texture resources through the cs.

wined3d: Clean up surfaces through the cs.

wined3d: Clean up volume resource data through the CS.

wined3d: Clean up buffer resource data through the CS.

wined3d: Clean up resource data through the CS.

wined3d: Create VBOs through the command stream.

A stop-gap solution to make fglrx happier until buffers are updated.

wined3d: Don't request the frontbuffer to create dummy textures.

wined3d: Unset some objects in state_init_default.

FIXME: Many more are needed.

wined3d: Put update_surface checks back in place

Unfortunately I can't remove the code from surface_update_from_surface
yet because blits depend on them.

wined3d: Implement DISCARD resource maps with heap memory.

wined3d: Implement DISCARD resource maps with buffers.

wined3d: Separate resource map and draw buffers

wined3d: Wrap GL BOs in a structure

The idea is to use those structures for mapping through the command stream and caching
them for DISCARD maps.

wined3d: Dirtify changed textures through the command stream.

This makes sure unsynchronized maps (NOOVERWRITE /DISCARD) are reflected
in the volume's location flags at the right time.

wined3d: Make resource maps and unmaps a priority command.

wined3d: Fence present calls.

wined3d: Fence clear calls.

wined3d: Fence color_fill operations.

wined3d: Fence blit operations.

wined3d: Fence render targets and depth stencils

wined3d: Fence texture reads in draws

This is probably stricter than necessary. GL BOs and allocated sysmem
are just staging resources. After they have been uploaded into the GL
texture, it's in theory OK to write new data buffer without interfering
with old draws. However, it is impossible to tell when if data has been
transfered into the texture because texture loads are delayed until draw
time. Specifically, it is difficult to separate two consecutive maps
from a map, draw, map sequence, where the draw hasn't been executed by
the time the second map occurs.

The other problem is that sRGB may cause a texture load from
buffer/sysmem even though the GL texture is thought to be loaded. This
is limited to situations where sRGB textures are supported, but
sRGB_decode isn't.

wined3d: Dirtify resources on unmap

wined3d: Put this into the query poll patch

wined3d: Fence update_texture and update_surface calls

wined3d: Use finer-grained buffer fencing

TODO: This could be more efficient. Find out which streams are
referenced in a vertex declaration at decl creation time and fence the
buffers in those streams only once.

wined3d: Don't lock the src volume in device_update_volume

This will attempt to wait for the CS, but this code is executed by the CS, so
it will, among other problems, break the single producer, single consumer
assumption of the work queue.

wined3d: Create buffers before mapping them.

wined3d: Send flips through the command stream

TODO: This remove this patch and flip_surface / surface_flip.

wined3d: Handle evit_managed_resources through the CS

wined3d: Don't reset the query state if it doesn't have a ctx

The CS recreates occlusion queries and changes the context variable.
This leads to incorrect query results.

TODO: Before sending, find out why the line was there in the first place
and if it is needed with the multithreaded and/or singlethreaded CS.

wined3d: Get rid of the surface_upload_data glFinish

wined3d: Send update_texture calls through the CS

wined3d: Send surface preloads through the CS

wined3d: Send texture preloads through the CS

wined3d: Send update_surface commands through the CS

wined3d: CS debug message cleanup

wined3d: Destroy shaders through the CS

wined3d: Destroy vertex declarations through the CS

wined3d: Control WINED3D_BUFFER_DISCARD from the worker thread

wined3d: Remove restated queries from the poll list

wined3d: Don't poll queries that failed to start

wined3d: Separate main and worker thread query state

wined3d: Use glBufferSubData instead of glMapBufferRange

This is faster on Nvidia once we're stuck in double-buffer mode for some
reason (e.g. using threaded cs). For other cards, we want to be able to
do mapbuffer through the CS.

winex11: complain if glFlush or glFinish are called

wined3d: Send buffer preloads through the CS

Think about making this a fast command. Might help if the driver
supports async data transfer, but synchronization side effects, esp. wrt
the dirty area list, have to be considered.

wined3d: Add a debug FIXME to catch cs->finish calls

wined3d: Ignore buffer->resource.map_count in the CS

This fixes sporadic test failures caused by preload refusing to load
data into the GL buffer.

It's fine to preload or create a VBO if a DISCARD or NOOVERWRITE map is
happening at the same time. A non-dynamic map will finish the CS before
incrementing map_count.

wined3d: Remove another glFinish

I don't think this is needed any more.

wined3d: Destroy queries through the CS

wined3d: Poll queries automatically in the CS

Hopefully this is faster than a communication roundtrip between the main
and worker threads. The priority queue can be removed again as well.

wined3d: Use the priority queue to retrieve query data

wined3d: Introduce a separate queue for priority commands

wined3d: Check our CS state to find out if a query is done

wined3d: Add query support to the command stream

wined3d: wined3d_*_query_issue never fails

wined3d: Access the buffer dirty areas through the CS

This avoids the following issues:

1) The worker thread uploading a dirtified area before the application
unlocks the buffer and marking it clean

2) The worker thread uploading data from the old memory and marking the
area clean although the data was written to a new block of memory.

However, this adds more synchronization than necessary. The first
problem could be solved by moving dirtification to unmap, e.g. via a
flag in each dirty area. The second problem can be fixed by not
dirtifying in map if map_mem != resource.allocatedMemory and dirtifying
the entire buffer in buffer_swap_memory (DISCARD dirtifies the entire
buffer anyway, and this could be the reason why).

If one of those ideas is used, access to the dirty area array needs to
be protected by locks.

wined3d: Accelerate READONLY buffer maps

FIXME: ProcessVertices can write to buffers

wined3d: Accelerate DISCARD buffer maps

TODO: Make this generic for all resources.
TODO2: Merge this with the patch that controlls BUFFER_DISCARD in the CS thread
TODO3: Clean up the map_mem allocation mess.

wined3d: Separate buffer map write and draw read memory pointers

TODO: Think about making this generic for all resources.
TODO 2: The name collision of map_mem and map_ptr is unfortunate.

wined3d: Don't call glFinish before swapping

The code is probably not ready yet, so delay this patch until everything
is CSified. Right now I need it for performance testing.

wined3d: Don't synchronize NOOVERWRITE buffer maps

TODO: Put the patch that makes PreLoad ignore the mapped state here.

wined3d: Use double-buffered buffers for multithreaded CS

wined3d: Don't preload buffers on unmap

wined3d: Replace the linked lists with a ringbuffer

wined3d: Get rid of the end_scene flush and finish

Either keep the patch this way, or send a flush through the CS. I'm not
sure it's worth it though, this has never had any real performance
impact.

wined3d: send resource maps through the command stream

Slow version only. Good enough to dodge some Nvidia bugs in the ddraw tests.

wined3d: Send surface maps through the command stream

Slow version only. Good enough to dodge some nvidia bugs in the ddraw
tests.

wined3d: Send color fills through the command stream

wined3d: Don't force strict draw ordering for multithreaded CS

Shouldn't be needed any more

wined3d: Add cs waiting debug code

wined3d: Get rid of WINED3D_BUFFER_FLUSH

wined3d: Send blits through the command stream.

This needs more work. This patch breaks error handling, and the split
between surface_blt and surface_blt_ugly isn't particularly nice.

wined3d: Run the cs asynchronously

wined3d: Wait for the cs to finish before destroying the device

wined3d: Prevent the command stream from running ahead too far

wined3d: Send light updates through the command stream

wined3d: Send int constant updates through the command stream

wined3d: Send bool constant updates through the command stream

wined3d: Send primitive type updates through the command stream