Skip to main content
GameDev.net gamedev.net
🔒 Locked

Direct3D Software rasterization for the VMR 9 DirectShow filter

Started by Clay Dooley Nov 7, 2005 at 6:02 PM 7 replies 2.1k views
Original Post
Clay Dooley
Clay Dooley
I am a programmer for a Houston-based medical software firm. While I am not a game programmer per se, the technologies I use in my work are the same ones used for games and multimedia, Direct3D and DirectShow. The application I work on manipulates, displays, and measures with medical images (echo scans, cath scans, and so forth). Recently, we have been using DirectShow's Video Mixing Renderer 9 (VMR9) filter to perform a number of functions such as brightness/contrast control, overlay of drawings on moving images, and shrinking/stretching of moving images. This filter uses video hardware acceleration via Direct3D 9, and it requires certain hardware acceleration features to be present, particularly non-power-of-2 textures, either available or conditionally available. The filter simply won't load otherwise. While we have some leeway in asking our specialized-application customers to use up-to-date video hardware, we have run into a problem with a system we want to use. For some of our users who wish to see images in real time from remote locations, the solution we wish to use is Citrix, a kind of virtual-machine emulator which runs on a Win2k/2003 Server. A user can log into such a server and run our programs, viewing images and reports, with complete security. This system emulates a virtual computer for each user who logs in (obviously, it requires a screaming processor). The problem is that Citrix does not provide access to video hardware acceleration, and so the VMR9 is not available. A reference rasterizer is visible if you run DX9CapsViewer, but this reference rasterizer does not support the features necessary for the VMR9. Direct3D has had "pluggable software devices" available as a feature for some time now. I have looked for some package that would emulate the features I need in software; while the speed would not be as good, that is less of a concern for this specific case. Most forums I have looked at have said that developers have ignored this potential addition to Direct3D. There was an open-source product called "swShader" that could emulate video acceleration hardware, but it has recently been acquired by a company who has made it proprietary (as SwiftShader); I tried downloading the trial version of it and it did not help with the VMR9; the web site also did not give a price or describe how to license it. I need to know how to get an up-to-date emulator for Direct3D video hardware acceleration, similar to the original promise of pluggable software devices, or to the original swShader. Ideally, I would like such a solution to enable me to use the VMR9 in situations where video hardware does not otherwise support it. Thank you for your time. This is a great forum! Clay Dooley Digisonics, Inc.
circlesoft
circlesoft
Interesting problem you have, but unfortunately, your options are limited. I'm not quite sure why you couldn't at least get the REF device to work, considering that it enables all D3D features. However, it would probably be a moot point, because it would be so slow that it would be unusable.

Also, creating a software plugin is going to extremely time consuming and difficult, and completely undocumented. Like you said, there are very, very few people out there that have attempted it, and far fewer that have been successful at it.

So, that leaves changing something else with your application. It sounds like your reason for the virtual machine thing surrounds security. Instead of trying to get around it, perhaps you should address it head on. I don't know what your security demands are, but there should be some kind of answer to them.

Instead of using this virtual machine for remote access, could you just make a networked application? You have the server set up at your firm, and you distribute the client to your customers (and require these machines to have capable hardware - which isn't that much to ask - non-pow2 textures and the like have been around for a long time). Note that you could have all of the security that you wanted (well, as secure as secure can get [wink]) with your networking protocol.

Alternatively, you could try a different video processor. However, make sure it is a pure software processor, otherwise you will run into the exact same problems.
Clay Dooley
Clay Dooley
Thanks for your reply. Unfortunately, I don't really have a choice as to whether or not to use the Citrix server system, as this was both a customer request and a company decision. As for the default Microsoft REF device, it does not support non-pow2 textures, and the VMR9 will not run under it. (At least, when I use DXCapsViewer and look at available REF devices, this feature has never shown up as available. These features almost always show up as available in the HAL for modern-day video cards, though I have seen a few older cards that didn't; the VMR9 would not run on the cards that didn't.)

I guess my question, whatever happened to the original open-source swShader? I wonder about the ethics of selling software that was originally developed under the understanding of open-source development, to proprietary companies who potentially reap the benefit of work that may have been unpaid. What's to prevent them from doing something like that with an enormously popular and potentially lucrative open-source project? Linux, anyone? But that's way off topic...

Anyway, I just need to find some kind of software rasterizer that I can use in place of Microsoft's REF, not because of its speed, but because I need to have non-pow2 textures, without which the VMR9 won't work, and which Microsoft's REF does not seem to provide. I say "seem to", because I've seen in some postings (including yours) that the REF is supposed to support ALL Direct3D features, which I find puzzling in this case because of the apparent lack of non-pow2 textures. Is there possibly a way to enable support for certain otherwise-unsupported features in Microsoft's REF? Or, my biggest question, has anyone developed an alternative to swShader, that is comprehensive enough to have included non-pow2 textures? I have seen a lot of personally-developed 3D engines out there; I'm hoping someone may have attempted something like what I have described, and that maybe someone has seen something.

Thanks again,
Clay Dooley
circlesoft
circlesoft
Weird. The Caps viewer just totally leaves out the pow2 bit. When I tested it in an application, it did in fact return negative, indicating that pow2 textures are not required:

D3DCAPS9 caps;d3dDevice->GetDeviceCaps( ∩︀ );	if( caps.TextureCaps & D3DPTEXTURECAPS_POW2 ){   // This is false for REF device, so it does support non-pow2 textures}if( caps.TextureCaps & D3DPTEXTURECAPS_NONPOW2CONDITIONAL ){   // This is also false, indicating the REF device provides    // unconditional support for non-pow2 textures}


Basically, this means that REF can use non-pow2 textures no matter what, since both the pow2 and nonpow2conditional bits aren't set.

So, I'm not quite sure what's going on. I will investigate further and see what I can find out.
Clay Dooley
Clay Dooley
Cool. Let me know what you find out.

FYI, two things. You said that DXCapsViewer does not even display the bit. There is an item on DXCapsViewer's View menu that toggles the display of all DX features, including those not supported. Without this menu item selected, non-supported features will not be displayed.

Also, I think that the "pow2" and "pow2 conditional" bits reflect whether non-power of 2 textures are _supported_. The reason I say this is that, on video hardware that supports non-pow2 textures, one or both of these bits will be set (they will display as "Yes" in DXCapsViewer when the above menu item is turned on). For the REF device, these bits consistently display as "No" when the show-all-capatilities-even-if-not-supported flag is turned on. The two falses you mentioned as being returned by GetDeviceCaps thus may mean that non-pow2 textures are _not_ supported, rather than the other way around.

Thanks a lot! Let me know what you find!

Clay Dooley
don
don
The section in the docs regarding NONPOW2CONDITIONAL and POW2 has been updated in the Oct 2005 release of the D3D9 SDK. It's basically what Dustin said below - if both flags are not set, then the driver can support non-power-of-two texture sizes unconditionally. If both flags are set, the driver can support non-power-of-two textures under some circumstances. If POW2 is set, but NONPOW2CONDITIONAL isn't, then the driver requires power-of-two textures. There are exceptions to this (cube/volume maps) so it's best to read the latest SDK docs for all of the details.

Dustin, I don't have any problem viewing these caps using the DX Caps Viewer as long as View/All Caps has been enabled.

Muhammad Haggag
Muhammad Haggag
Yep, it is as Dustin and Don say. Non-power-of-2 textures are supported unconditionally here (June 2005 SDK). But will REF really work for you? It's unbearably slow.

As for software renderers, have you looked up RAD tools pixomatic? It's a powerful software renderer. They don't say whether they support non-power-of-2 textures or not, though, but they'd sure provide that info if you contact them [smile]

outRider
outRider
I really doubt you'll be able to use the reference device or a software rasterizer with VMR9. Check if the overlay and/or VMR7 show up on the VM, I think they can both fall back to GDI so they should be available everywhere, but VMR9 is designed to run exclusively off D3D9 hardware support.
circlesoft
circlesoft
Quote:
Original post by don
Dustin, I don't have any problem viewing these caps using the DX Caps Viewer as long as View/All Caps has been enabled.

Ahhaaa...that solves that problem [wink]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.