Tech Off Thread

17 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Direct2D performance for very complex graphics

Back to Forum: Tech Off
  • User profile image
    damiandixon

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-769T

    We are finding that the documentation for Direct2D is not sufficiently enough to develop complex graphics intensive applications. The above video is a good start but we need significantly more to enable us to be quickly productive as developers with Direct2D. 

    The application we are attempting to develop is for GIS - so we are basically pushing very large amounts of complex holed polygons (potentially thousands of points with thousands of polygons, typically 8000 to 10000 polygons), polylines (8000 to 10000 lines with 10's to 1000's of points, variable widths with multiple paterns), text (potentially 1000's of) and symbols (potentially 1000's of, ideally at least 5000). The drawing is frequently scaled as the map is zoomed in and out which potentially nullifies the bitmap caching idea. We do cache the Direct2D geometry objects as a first step in optimising.

    Given this scenario we are finding the performance of polygon rendering and the outlines to be insufficient with Windows 7. In fact GDI appears to be a lot quicker... which is surprising.

    We suspect that the use case scenarios for Direct2D do not  consider this type of complex application (at least on Windows 7 and given the performance scenario in the video).

    I hope that by knowing what we are attempting to achieve then you will consider this in performance testing/improvements. 

    We would like to know if we are just pushing the performance envelope too hard and should consider a different drawing api (DirectX)?

    Note: we do need to do drawing on a Server in multiple threads so DirectX may not be sensible in this case. So suggests for this would be welcome.

    Thanks Damian

  • User profile image
    androidi

    I know it's not related to your D2D question but there's some hilarious GDI benchmarks here:

    http://www.tomshardware.com/reviews/2d-windows-gdi,2547-9.html (gdi polygon bench)

    There's a link to the benchmark app somewhere and lots of results posted in the comments.

    The summary of it is (given AMD's response) that since no one (in Toms or Anandtech and maybe few other sites) has bothered to benchmark 2D perf in past 10+ years, the companies haven't improved it, infact they've gone backwards, 2D is slower than 10+ years ago.

    The benchmark figures aren't even the whole truth : Tom's have prettied them up by not including hw-accelerated GDI cards in XPDM results. So when you see Vista/7 being "only" 5 times slower than Win98/XP on some obsolete hardware from 10 years ago, it is really more like 10+ times slower since now everything 2D related is done in software and there's many more layers of abstraction now.

    It may even get "better" in Windows 8. One of the build sessions suggested big perf drops in some old apps as DWM cannot be disabled anymore.

     

  • User profile image
    evildictait​or

    ...since now everything 2D related is done in software and there's many more layers of abstraction now.

    Actually quite the reverse. Almost all 2D operations (apart from font rendering) are now performed on the graphics card if the graphics card supports it - if you fill a big white rectangle on the screen this is usually done by pumping a parameterised shader to the graphics card to do the coloring whilst DWM gets on with the busy work of double and triple buffering everything to give you funky swishy graphics.

    One of the big reasons why there's a perception of slowdown with 2D graphics is that most 3D apps turn off DWM when they become fullscreen, and thus get exclusive access to the graphics card and a massive boost to their thread priority whilst the game is playing (in order to improve performance at the expense of background apps).

    Most 2D games however tend to run windowed, and thus have to compete with the rest of the system for resources, including fighting the blur-shaders that DWM is using for desktop compositon (which is how aero glass works).

    The basic way that DWM works hasn't changed in Windows8, so don't expect a big change in the next release.

  • User profile image
    androidi

    I don't want to make an argument with this point since it may be very driver dependent and possibly even depend on whether Vista or 7 is in use (I read a suggestion in Vista you could easily revert to XPDM on some WDDM drivers by disabling the driver in control panel, gaining gdi perf for some apps).

    On 7 SP1 with Nvidia driver (I tried few different versions) the result I got from each of:

    net stop uxsms
    net stop "Themes"

    & even trying to disable the driver as suggested somewhere, was that the GDI benchmark perf dropped.

    My initial assumption was that the GDI perf would go up by trying these measures since the candy was turned off.

  • User profile image
    androidi

    @evildictaitor:

    I have to take issue with that "perception of slowdown" comment even if this is a bit pointless discussing about legacy stuff - it does however suggest there's room to improve on this area (atleast by cpu+gpu chips from intel/amd).

    I already posted links to benchmark tool and results which fly against your comment and my own tests in past (when I had AGP card with a dedicated chip for GDI acceleration). Those dedicated 2d chips aren't shipping with Nvidia since I think it was 7xxx or 6xxx series. I don't have a reference to this right now but years ago I read reviews which made a point of this. The results in the benchmark, along with my own experiences of windowed stuff slowing down noticeably when moving to 8800 support this.

    So when it comes to pushing 2D stuff to screen in windowed mode as fast as possible, XP, in best case can be 10 times faster (on legacy gdi apps) than Windows 8 in best case (since it no longer has support for XPDM based on the Build compat-session I saw here). In windows Vista/7 there may be way to install XPDM driver, but I can say that so far I haven't been able to install Nvidia XP-64 driver on 64 bit Windows 7. Maybe the 32 bit one would work (for win 7 32).

  • User profile image
    figuerres

    , damiandixon wrote

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-769T

    We are finding that the documentation for Direct2D is not sufficiently enough to develop complex graphics intensive applications. The above video is a good start but we need significantly more to enable us to be quickly productive as developers with Direct2D. 

    The application we are attempting to develop is for GIS - so we are basically pushing very large amounts of complex holed polygons (potentially thousands of points with thousands of polygons, typically 8000 to 10000 polygons), polylines (8000 to 10000 lines with 10's to 1000's of points, variable widths with multiple paterns), text (potentially 1000's of) and symbols (potentially 1000's of, ideally at least 5000). The drawing is frequently scaled as the map is zoomed in and out which potentially nullifies the bitmap caching idea. We do cache the Direct2D geometry objects as a first step in optimising.

    Given this scenario we are finding the performance of polygon rendering and the outlines to be insufficient with Windows 7. In fact GDI appears to be a lot quicker... which is surprising.

    We suspect that the use case scenarios for Direct2D do not  consider this type of complex application (at least on Windows 7 and given the performance scenario in the video).

    I hope that by knowing what we are attempting to achieve then you will consider this in performance testing/improvements. 

    We would like to know if we are just pushing the performance envelope too hard and should consider a different drawing api (DirectX)?

    Note: we do need to do drawing on a Server in multiple threads so DirectX may not be sensible in this case. So suggests for this would be welcome.

    Thanks Damian

     

    computing on a server ?    possibly you should look at direct compute ?

    use multiple GPU cards to render that data but skip DX as the display is not there ??

  • User profile image
    damiandixon

    @figuerres

    An interesting idea however for throughput reasons we may be doing the drawing in 30 threads on a Server. I also need to support Desktops primarily and would prefer to avoid supporting too many drawing technologies.

  • User profile image
    damiandixon

    We have two experimental drawing engines; a Direct2D and an OpenGL version.

    The OpenGL version in the worst case is slightly faster than the GDI version. The worst case fps for the OpenGL version is ~20fps. The worst case for the GDI version is way less than 0.1fps.

    The GDI version is faster than the Direct2D version.

     

    What I would expect to see is that the Direct2D version should be nearly as fast as our OpenGL version.

     

    As a side note: Our X11 drawing engine is significantly faster than the GDI version and is a good option for Server side rendering.

  • User profile image
    Frank Hileman

    Damien, are you used testing aliased graphics using Direct2D? It is suprising if Direct2D is slower for aliased graphics, compared to GDI. That indicates a fundamental inefficiency in the design. The problem with the Direct2D tips in the video, is they almost all rely on some kind of caching. That is fine for a few primitives but usually doesn't scale well, unless you can reuse resources across primitives (not your case, I think).

  • User profile image
    evildictait​or

    My main piece of advice is that you should get yourself a proper performance testing suite and perf-test your application to find out where it's slowing down. Premature optimisation is the root of all evil and leads to security bugs and nightmarish code, so don't do it if you don't have to, but in most apps 95% of the CPU is taken up on 5% of the code - some small tweaks in the hotpaths of your application could massively improve its performance.

    If you're really stuck for ideas of how to speed it up, I'd consider migrating to Direct3D or XNA so that things like caching and fast access to the hardware are abstracted further away from you - Direct2D is really great for some things like ClearType font rendering and smooth scaling of splines, images and lines - if you don't need these things then move post-haste to Direct3D where these things are not in the way slowing down your application.

    You might also want to consider checking if you're creating new objects and memory allocations every frame which could be cached across different frames - often these small improvements can make your application much faster.

  • User profile image
    AndyC

    @damiandixon:At the risk of channeling Raymond Chen for a moment, the single best way of improving the performance of your code is to do less stuff. You mention things like having 1000s of bits of text on screen, but unless you're running at some extremely high resolution the chances are a lot of that can't be readable, so there isn't any point spending time on it. Intelligently decide what to render can have enormous performance benefits to any application.

  • User profile image
    damiandixon

    We've not got as far as doing the text rendering. We've only done the polygon and lines. We've tried turning off anti-aliasing of lines.

  • User profile image
    evildictait​or

    I think what AndyC is trying to say is that if your framerate is dropping, you should ask yourself what things you could avoid asking DirectX to do and what computations you can do either once at compile time, once during scene startup or once during the object load to avoid doing it every time during the hot-path of the frame renderer.

    For example, are any of these polygons entirely occluded by other polygons? In which case you could avoid drawing them.

    Are any of your polygons entirely outside of the window's view? If so, don't draw them.

    Are some of these polygons excessively high resolution for the amount of visual space on the screen? If so, how about reducing their polygon count / texture resolution?

    If your polygons are static but procedurally generated, can you precompute them (trade disk space for FPS).

    If one object doesn't move with respect to another, can you cache properties that avoid you having to compute them every frame - like light/shadow maps and occlusion maps?

    If you have some objects which don't move at all, can you merge them all into a single massive object so that DirectX has to service less calls?

    Bear in mind that things like modern games are so pretty precisely because every polygon they send to the GPU is a polygon they need - the hills in the background and the grass underfoot is super-low resolution with tricks and magic precisely so they can render your flaming sword and mutant enemies with as many polygons as they can muster - and since those are the ones you're looking at, you think the game has awesome graphics without forcing your customers to go and buy new hardware.

  • User profile image
    spivonious

    @evildictaitor: But doesn't D3D already do those clipping and occlusion calculations?

  • User profile image
    AndyC

    @spivonious: AFAIK DirectX will just process everything you send to it, leaving the decisions up to you. It's deliberately intended to be as slim an abstraction from the hardware as is possible to give the best performance possible.

    In any case there are lots of "high level" decisions about the levels of detail and relevance of data at a given size that DirectX can never understand. As evildictator points out making these decisions in your code allows you to focus performance on the things that matter and ultimately do the minimum necessary work to produce the best output for a given scenario.

  • User profile image
    spivonious

    I guess some pre-optimization couldn't hurt, but it's my understanding that once you apply the projection matrix, DX automatically throws out any vertices that aren't visible.

  • User profile image
    evildictait​or

    , spivonious wrote

    @evildictaitor: But doesn't D3D already do those clipping and occlusion calculations?

    No it explicitly doesn't for the simple reason that occlusion and clipping are expensive and graphics needs to be fast and it really doesn't want to do unnecessary checks in the hot path of the frame renderer.

    The DirectX API takes the view that understanding the context of what you're doing is done best by the programmer, and that implementing its own checks on top would

    a) Potentially be duplicated effort, if the programmer already does them him/herself.

    b) Potentially be more expensive than other, cheaper or better techniques which the programmer might have invented.

    c) Might be unnecessary because of some context-specific reason which DirectX doesn't know about (for example why should DirectX check that polygons aren't behind the camera if the programmer knows s/he didn't put any there.

    d) Might be ineffective. Culling occluded polygons is only a good idea if there is an opaque texture over the occluding polygon, which is expensive to check. Surely the programmer either knows that he doesn't use semi-transparent textures so he can always cull, or is in wireframe mode and can never cull better than DirectX?

    DirectX is supposed to be fast. The programmer is supposed to be clever - not the other way around.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.