Re: Texture and Multithread questions

Tech-Archive recommends: Fix windows errors by optimizing your registry



On 29 juil, 18:17, Wyck <W...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
In my experience, no, you can't do the things you mentioned (lock textures)
on another thread without the use of the D3DCREATE_MULTITHREADED flag.

You can, however, use your idea of locking the texture in one thread, and
memcpying data in a second thread. This is because the memcpy itself doesn't
involve the DirectX runtime.

I'm curious to know if you expect to receive a performance gain from
omitting the multithreaded flag and doing your own synchronization. I'm
skeptical. In my experience, using the device less is better. I get far
larger payoffs from constructing larger batches, reducing state changes, etc.

I would speculate that the locks themselves are fairly light, and that you
likely only incur a noticeable delay when there's actual contention for the
device. But that's speculation.

Accomplishing the synchronization on your own is certainly a bit of a pain.
You'll need facilities for the synchronization of allocating/recycling
resources like textures and initializing them. If you use a multithreaded
device, then you can just allocate the resource whenever you want to, lock it
and unlock it as needed during initialization.

Also using directx's locks should allow concurrency within the runtime.
Using your own locks you would force mutual exclusion, whereas the
implementation can take locks for shorter durations, allowing more overlap.
Again I speculate optimistically about the present and future implementation
of the DirectX runtime.

- Wyck

you can check the discussion on DirectxDev
to resume:
Create / Lock / Unlock on main thread and just read / Fill the data on
the loading thread works well.
and it doesn't uses temporary buffer
.



Relevant Pages

  • Re: Centrino Laptop (Acer 800Cli) and 5.1
    ... there some flag I can turn on to tell me what locks are being taken ... > Could be a thread stuck in a loop? ...
    (freebsd-current)
  • Re: [CRYPTO]: Only reschedule if !in_atomic()
    ... > this stuff with locks and some not? ... functions with a spin lock on the xfrm_state. ... The other thing we could do with a flag is to use it to set GFP ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)