04-18-07, 05:32 PM
I haven't had the chance to try this myself, but it surely looks interesting:
04-22-07, 07:30 AM
Yea, I knew this was too much hassle for anyone to try, including me:D
Rather optimistic of them isn't it? :p
I'm curiuos if MS will sit idly by.....
04-22-07, 08:22 AM
I guess MS will shut down the project if they seem succeed....
04-28-07, 11:17 AM
This is faaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrr away from working. Most samples doesn’t even start and if they start the have visual errors.
04-28-07, 12:21 PM
i cant wait for MS to bitch about this, but thats great someone is willing to stick it to the man and port DX10 backwards :D. For gaming, this is my savior
04-28-07, 02:59 PM
Rather optimistic of them isn't it? :p
I'm curiuos if MS will sit idly by.....
MS is probably laughing at them, saying what bunch of idiots
04-28-07, 04:21 PM
The Direct3D 9Ex interface provides access to a slight extension of the standard Direct3D 9 API that exposes the virtualized resource allocation, new lost device semantics, and some other new features available while running on Windows Vista. By creating this extended object, the Direct3D 9 API uses the new semantics and therefore requires the application to use different logic (and therefore different code paths) for resource creation, management, and error handling for new kinds of conditions. This API is only available on Windows Vista, and it requires WDDM drivers. Because Direct3D 9Ex uses a separate API and driver code path than Direct3D 9, supporting this API requires additional test cases for your application.
The primary reason for creating the new Direct3D 9Ex API was to allow full access to the new capabilities of WDDM while maintaining compatibility for existing Direct3D applications. The new 3D desktop and many Windows Vista-specific applications make use of this version of Direct3D 9, but they are not functional when running on older XPDM drivers. Because the Direct3D 9Ex API will never appear on older versions of Windows due to a lack of support for the WDDM, the standard Direct3D 9 interfaces cover a much broader set of systems. For high-performance applications that can take advantage of the next generation of video hardware, the entirely new version 10 of Direct3D provides many new capabilities not exposed by Direct3D 9Ex. As a result, for games and most other applications, Direct3D 9 or Direct3D 10 is the recommended API.
Note The DirectX SDK does not provide samples, headers, or libraries for the Direct3D 9Ex interface. The MSDN Library and Windows SDK (formerly known as the Platform SDK) contain the available documentation, headers, and libraries.
For more information about Direct3D 9Ex, see DirectX for Windows Vista on MDSN.
To fully realize the potential of the new Windows Vista driver model and next-generation hardware, an entirely new version of the Direct3D API has been created. While WDDM eliminates some of the limitations on performance in the existing graphics system, Direct3D 10 goes further by removing design bottlenecks in the existing Direct3D API and greatly simplifies the task of programming the GPU.
The new API completely eliminates all but a few fixed-function aspects, replacing them with programmable constructs and greatly streamlining the internal implementation. The hundreds of capability bits in previous versions of Direct3D have been completely eliminated and replaced with a well-defined, inclusive set of functionality that has only a few optional usage scenarios for specific resource formats. CPU-intensive resource creation and validation now have explicit semantics in the new API, allowing for much more predictable performance behavior and greatly reduced per-draw overhead. Resources can be reconfigured into multiple forms to allow efficient use at various stages, and the feature set imposes far fewer restrictions on usage scenarios for formats. There area also new block-compressed normal-map texture formats.
In the new API, shader constants and device state are explicit resources, allowing for far more efficient caching on the hardware and greatly simplified driver validation. The programmable shader model has been unified across both vertex and pixel shaders, and made more expressive with a well-defined computational model and operator set. Also, a new geometry shader stage has been added to operate on primitives after the vertex shader stage. The results of the GPU’s work in the vertex and geometry shader stages of the pipeline can be streamed out to video RAM for reuse, allowing for the possibility of extremely complex multi-pass GPU operations with minimal CPU interaction.
All of these enhancements enable next-generation graphics technology and expand the ability of applications to off-load work to the GPU. Offloading allows more complex GPU-based character skinning, accelerated morphing techniques, shadow volume generation and extrusion, particle and physics systems that are entirely GPU-based, more complex materials combined into efficient large-draw batches, procedural detailing, real-time ray-traced displacement mapping, single-pass cube-map generation, and many more techniques — all while freeing up CPU resources for more complex applications.
To provide this level of innovation in Direct3D 10, older hardware cannot be expressed as a partial implementation of a new interface. A video card is either capable of supporting all of the new features, or it’s not a Direct3D 10–capable card. Therefore, while Direct3D 9 could drive DirectX7-era hardware with many missing capability bits and usage limitations, Direct3D 10 only works on a new generation of video cards. For an application to support older video hardware, it must also support the Direct3D 9 interfaces. Future versions of Direct3D will build on version 10, extending it to new versions of the API while ensuring a strict superset of Direct3D 10 functionality.
For more information about Direct3D 10, see the DirectX SDK documentation for DirectX 10.
Allow me to pull out the inordinately-large-hammer-of-truth on that one and bang out some pretty clear messages:
- Absolutely not.
- Definitely not.
- No f'n way.
Now, I'm aware of the fact that some people aren't interested in letting “the facts” get in the way of a good rumor. If you're one of those people, you can stop right now and tell your buddies, "I saw this Microsoft guy say it's not going to happen, so the rumor must be true!" (because we all know that when people say the opposite of what you want to hear, they MUST be hiding something :-).
For those of you still reading, and interested in the facts, here they are:
- DirectX 9.0L was the early name designation for what is now called "DirectX 9.0Ex".
- DirectX 9.0Ex is a Windows Vista only feature. In a nutshell, it is DirectX 9.0c, with some modifications to work smoothly with the new driver characteristics of Windows Vista, which is significantly different at the graphics level than Windows XP. You can read more about DirectX 9.0Ex and how it fits into the Windows Vista picture here
- Windows XP cannot run DirectX 10 (technically, Direct3D 10) applications because of the significant changes in the graphics API and driver model
- And while I’m on it, the Xbox 360 cannot run Direct3D 10 because it lacks the Shader Model 4.0 hardware.
"During a DirectX 10-related event in London, UK, Richard Huddy, ATI Technologies’ software developers relations chief, said that Microsoft’s Vista will integrate DirectX 10 and DirectX 9 APIs for different types of hardware, but the current Windows XP will not get DirectX 10 support, as suggested some rumours earlier. For end users this means that to get the most advantages of the new-generation graphics processing units (GPUs), the new OS will be required."
Hope this clears things a bit, there wont be DX10 for XP, period.
DirectX 9 API
DirectX 10 API
Why DX10 wasn´t created on XP and why isn´t it on XP
Lets consider the software development lifecycle, the DX10 lifecycle, and the history of Vista,
The first step taken is to create a code branch for the new OS. XP RTM'ed in August 2001. I remember the ship party and still wear the t-shirt.
As changes go in to the new branch, it no longer resembles the thing that it was before.
DX10 itself wasnt fully baked when the initial branch was taken. DX9.L to support Aero and desktop composition took a bit of time. And the design if DX10 itself went thru a process with the IHV community where feature asks went back and forth, and features made the cut and missed the cut. Features miss the cut for a variety of reasons but that all takes time. Negotiations with the IHVs didnt conclude until late in 2003. This resulted in simplifications to the original MS Input Assembler design request. I worked at ATI in this timeframe as Director of Strategic Relationships and owned the ATI-MS relationship so I have 1st hand knowledge. I was in the meetings.
Given XP shipped in 2001 and it was late 2003 when the DX10 design solidified - it should be obvious that "what the OS was" was well beyond XP before serious DX10 work commenced. Heck, the Longhorn reset was in 2004 and DX10 wasnt done until later. The build that was demo'ed at WinHEC 2004 with the texture memory management was a very fresh build and wasnt feature complete - and that was April or May 2004. The 1st DX SDK supporting DX10 didnt appear until Dec 2005 here, http://www.microsoft.com/downloads/details.aspx?FamilyID=7d29004e-7a8d-4f0a-b199-6a740d8f27bb&DisplayLang=en. Further validating these points.
After the Longhorn reset, a new code branch based on W2K3 was started. Again that wasnt XP. And again kernel changes, which had to go in before the driver layer and the API could be brought up, made it even more not XP.
DX9 was in the original code branch, and was in W2K3 - so maintaining compat is of course an order of magnitude easier then new implementation.
Given the new features in the driver model and hardware ( with GPU task switching, GPU memory management and more ) all of which require kernel support - hoisting a driver layer like that on XP is rewriting it to be Vista. FWIW, the MS hw developer page has the graphics logo requirements and it explicitly mentions these GPU features as being required. They are essentially hidden features that API programmers and end-users never see.
At some point, the question "to serve existing customers" or "to get new customers" is a question every business has to ask itself. Given XP has had a 5+ year run it is hard to see how XP customers have a strong case they were not given good value for the money. Especially when the features in question are ones that are a rewrite of the kernel and the driver layer, and require such a hw leap. Really.
I hope the community can appreciate my points about how the branch and life-cycle work to make assumptions that Microsoft developed DX10 on XP not really true.
I also hope you can appreciate the level of the change, so the community understand the ask is a non-trivial investment of engineering resources.
We can politely disagree about whether or not MS should provide this functionality to XP users. And whether or not the investment makes sense.
I appreciate the strong feelings people have over this, but ad-hominems dont help advance the discussion. Could we keep them out of the discussion, please?
This thing, if it gets it, could, at much, get a software emulation, for hardware they need drivers ready for DX10 in XP, thing that never will happen...
04-28-07, 06:43 PM
Well Microsoft would not tell people how to get Direct3D 10 apps running on Windows XP. I am say “Direct3D 10 apps” and not Direct3D 10 because full Direct3D 10 support would require that you can use the Durect3D 10 drivers too. I agree that this would not happen. But there are two other options for hardware accelerated Direct3D 10 on Windows XP.
1. The GPU manufactures deliver their own versions like they had delivered an OpenGL for Windows 9x.
2. Converting Direct3D 10 calls to OpenGL class.
I am don’t expect that number one will happen. Maybe there are even some legal reasons that make this impossible at all but even if not the nvidia and AMD/ATI driver teams have already enough work.
This brings us to number 2. The way that the Alky project and Wine had taken. Thanks to the OpenGL extensions mechanism even Windows XP OpenGL driver can provide access to the Direct3D functions on a GPU. Therefore as long as a Direct3D 10 game only requires features that are accessible via OpenGL too writing a wrapper is possible.
But this would be a great amount of work and whoever is willing to do it must know that reaching 100% compatibility to the original Vista Direct3D 10 is impossible. But even running the SDK samples would be already a challenge.
A much as I love such things from the technical point of view I am not sure if it would be a clever decision from a commercial view. Therefore they question would be if the guys behind the Alky Project would have enough money to getting it rolling at all? Personally I would set my money on a project that doesn’t need to be commercial successful at all like Wine.
vBulletin® v3.7.1, Copyright ©2000-2015, Jelsoft Enterprises Ltd.