Texture and Multithread questions

[benoitj]

Hi!

I'm doing asynchrone loading for my texture.
I have a MainThread and a LoadingThread.
The main thread push back texture request to the loading thread and
use a default texture while it's ready
The loading thread do this:
- Create a texture
- Lock
- fill data from file
- Unlock
it's working fine but i'd like not to use D3DCREATE_MULTITHREADED for
performance reason

I think i'll do:

MainThread:
- create texture
- Lock
- push request to LoadingThread
LoadingThread:
- Fill data
- Unlock

However the directx documentation is not very precise about what you
can safely do on another thread
Which D3D call should be using the same thread?
Can i lock a texture on another thread ?
Can i lock a texture on another thread if the texture is not used yet?

thanks for your response

[Wyck]

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

[Richard [Microsoft Direct3D MVP]]

[Please do not mail me a copy of your followup]

Asked and answered on the directx-dev mailing list.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

[Richard [Microsoft Direct3D MVP]]

[Please do not mail me a copy of your followup]

=?Utf-8?B?V3ljaw==?= <Wy...@discussions.microsoft.com> spake the secret code
<290E19A6-6647-46DC...@microsoft.com> thusly:

>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 if you do your own thread synchronized use of the device
interface.

[benoitj]

On 29 juil, 18:17, Wyck <W...@discussions.microsoft.com> 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