Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

No textures with D3DPOOL_MANAGED under Vista?

177 views
Skip to first unread message

Robert Fiegender

unread,
Aug 29, 2008, 7:24:46 PM8/29/08
to
Hello,

does anybody know if there are general problems creating textures with
D3DPOOL_MANAGED attribute under Vista?
With XP, all runs as expected.
The same code and very similar graphics hardware/driver (ATI HD38xx series,
512MB Video RAM) under Vista cause an error, meanwhile D3DPOOL_DEFAULT
works.

HRESULT hRet = D3DXCreateTexture(m_pD3DDevice/*valid D3D9 oder D3D9Ex
Device*/, 1024, 1024, 0/*all MipLevels*/, D3DUSAGE_AUTGENMIPMAP,
D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, &pTexture);

Same result without mipmap:
HRESULT hRet = D3DXCreateTexture(m_pD3DDevice/*valid D3D9 oder D3D9Ex
Device*/, 1024, 1024, 1/*only top level*/, 0/*usage*/, D3DFMT_A8R8G8B8,
D3DPOOL_MANAGED, &pTexture);

D3DERR_INVALIDCALL is returned only when running under vista

All hints are very much appreciated. Thanks!

Robert


Chuck Walbourn [MSFT]

unread,
Aug 29, 2008, 11:02:44 PM8/29/08
to
Try the D3D9 samples on that system. Might be a driver or configuration
issue.

The only 'issue' with POOL_MANAGED on Windows Vista is related to Virtual
Address Space prior to Service Pack 1. See the Gamefest 2007 presentation
"Why Your Windows Game Won't Run In 2,147,352,576 Bytes"

http://download.microsoft.com/download/e/3/c/e3c25fea-2b53-4174-8729-29a4ec16583b/Why%20Your%20Windows%20Game%20Won't%20Run%20In%202,147,352,576%20Bytes.zip


--
-Chuck Walbourn
SDE, XNA Developer Connection

This posting is provided "AS IS" with no warrenties, and confers no rights.

Robert Fiegender

unread,
Sep 1, 2008, 4:14:01 PM9/1/08
to
Thank you for the link to your ppt.
Meanwhile it was very interesting for me concerning some other "mysteries",
I still cannot create a texture using D3DPOOL_MANAGED.
Vista Enterprise SP1 and latest ATI driver (2008-08-01) is running.

The reason for my efforts:
So far I mainly used D3DPOOL_DEFAULT for allocation of texture memory. As
textures have to be loaded dynamically, I backed them with a plain surface
in D3DPOOL_SYSTEMMEM. When preparation of the texture in this surface was
completed, the transfer to the texture was done by UpdateSurface().
This runs with good performance under XP, but using Vista the memory access
to the plain surface is rather slow. A memcpy of 12 megabytes from
application allocated RAM to the surface takes about 20ms. For this reason,
I wanted to give Managed Textures a try.
What else could be done in order to quickly change the texture's content?

Thank you in advance!

P.S. I just found out that if I create a Direct3D9 object (instead of
Direct3D9Ex as I do now when Vista is recognized), managed textures work
fine. But they don't seem to solve the problem that an update of the texture
is significantly more time consuming than using good old XP.


Richard [Microsoft Direct3D MVP]

unread,
Sep 2, 2008, 3:13:40 PM9/2/08
to
[Please do not mail me a copy of your followup]

I believe the situation is this:

Direct3D9 on Vista:
Managed pool resources can be created and work as they do on XP.

Direct3D9Ex on Vista:
Managed pool resources are not necessary because the Ex device
is always able to restore the data to device memory with the
enhanced driver model on vista.

Therefore, managed pool resources can't be created and instead you
just use the default pool and let Vista restore them as needed.

As for your performance issue, I don't know what to tell you other than
"it is what it is".
--
"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/>

Chuck Walbourn [MSFT]

unread,
Sep 3, 2008, 6:29:12 PM9/3/08
to
D3DPOOL_MANAGED is not a valid pool option when using Direct3D9Ex so you are
always going to get an error (which I assume was D3DERR_INVALIDCALL).
There's no lost device scenario when using Direct3D9Ex, as well as some
other behavorial changes (VRAM is 'unlimited', etc.)

If your application is a Direct3D9 application and you support both Windows
XP and Windows Vista, there's not much point in writing a different code
path for Direct3D9Ex.

If your application supports just Windows Vista, then Direct3D9Ex is
something to consider. Keep in mind that you cannot create a Direct3D9Ex
object when the system is using a legacy XP driver instead of a Windows
Vista WDDM driver. Direct3D9Ex also assumes the application is already
mluticore aware, so there are fewer 'automatic' dual core optimizations than
when using Direct3D9.

For game applications, we recommend writing a Direct3D 9 path to cover
Windows XP, Windows Vista with D3D9 hardware, and even potentially Windows
Vista with an XPDM driver. If you are going to write another rendering
codepath, it's better to write a Direct3D 10 path for Windows Vista with
D3D10 hardware.

--

Chuck Walbourn
SDE, XNA Developer Connection

This posting is provided "AS IS" with no warranties, and confers no rights.


Robert Fiegender

unread,
Sep 6, 2008, 7:02:59 AM9/6/08
to
Thank you both very much for your hints clarifying the D3DPOOL_MANAGED
issue.
I use Direct3D9Ex only if vista is recognized, as I found out that
performance is slightly better than with Direct3D9.
Maybe the framerate is more stable due to my call the SetGPUThreadPriority()
function that does not exist on Direct3D9. But maybe it is just the WDDM
Driver model...

Anyhow, I will try to live with the "slow" access to the Offscrren Plain
Surface under Vista.

Best regards
Robert


0 new messages