Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 103 of 173 FirstFirst ... 35393101102103104105113153 ... LastLast
Results 1,021 to 1,030 of 1724

Thread: OpenGL 3 Updates

  1. #1021
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: OpenGL 3 Updates

    We'll be using scatter mostly for DOF and motion-blur initially, both being algos where you can cache the few nearby lines or tiles of the frame-buffer and upload on cache contention. Plus, the problem with 100 shaders scattering to the same pixel can be solved initially via a round-robin cache-update using 1 ALU (can do both addition and alpha-blending), and in the future - by having tiles of cached additives, later added together in a pyramid fashion (can do only addition). SLI will be problematic with scatter, but possible at the price of some performance - or well, with improved performance when each card keeps in GDDR the scatter values for the other card's scanlines (can do only addition).

  2. #1022
    Junior Member Regular Contributor
    Join Date
    Aug 2007
    Location
    USA
    Posts
    243

    Re: OpenGL 3 Updates

    I think it'd be pretty cool if we were able to manage shared memory explicitly with this "compute shader" in order to get much higher performing convolutions.

  3. #1023
    Intern Newbie Carl Jokl's Avatar
    Join Date
    Jan 2007
    Location
    Redditch, Worcestershire, United Kingdon
    Posts
    47

    Re: OpenGL 3 Updates

    *Feels out of his depth and vaugely nausious*

    ....one day I will be strong with the ways of OpenGL....but I am not a Jedi yet....
    Check out my dimensions, length, width and for a limited time only..depth!

  4. #1024
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by HexCat
    I think it'd be pretty cool if we were able to manage shared memory explicitly with this "compute shader" in order to get much higher performing convolutions.
    The problem with compute shaders as I see it (and a whole black mark against the 3D via CUDA/CTM idea) is that what works well on NV doesn't work well on AMD and vice versa.

    For example using the newest hardware from both; AMD prefer a 4:1 ALU:tex ratio where as NV favor 3:1 based on how the samplers are tied to SPs.

    Then there are hardware differences at the Stream Processor (SP) level; NV's SPs are all single floating point, where as AMD are vec5 units with each unit able to process 5 instructions at once. Also, each GT200 is made up of 8 normal SP and 2 'fat' SP which can do "special functions" (sin, cos etc); AMD on the other hand as equiped each SP with one of these 'fat' procssors. Couple that with the fact each 'block' for AMD has 16 of these 5 wide SPs and NV only has 8 general and 2 special function there is an intresting mismatch in processing power.

    This impacts design of algorithm, as does the local on chip memory (both have 16KB local store, AMD have an additional 16KB global data block) and the number of threads in flight.

    While I'm intrested to see what these compute shaders can do the fact the underlaying hardware remains so different and requires different tweaking to get it performing just right that I don't see a CUDA/CTM based system as sane. Right now you only have to worry about supplying the data down the 'fast' path and throwing high level shaders at the driver and it will do it's best. With a CUDA/CTM method you suddenly have to write a backend which cares about what hardware it is running on.. you know.. the stuff the IHVs already do.

    DX11 compute shaders seem intresting, but that's about it. Given that two generation in the GS still isn't viable for really heavy use (the GT200 based cards not doing much better than last generation AMD card) I don't see this doing much better because of the hardware differences and work required to get it going.

    (In other news, based on how well a £180 HD4870 performs vs a £240 GT260 and a £350 GT280 (as in faster for the former, and generally around 10fps slower in the later) and the fact that NVs drivers have bluescreened Vista for me 3 times now for my GT8800 vs AMD's X1900 series drivers never taking down the system once, I think I'll be jumpping ship again... be intresting to see what AMD's R700 can do when it appears as currently it doesn't have a 'high end' model out).

  5. #1025
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    469

    Re: OpenGL 3 Updates

    Since CUDA shaders go through the same driver optimizer as the GL/D3D shader optimizer, where is the difference?

  6. #1026
    Advanced Member Frequent Contributor Mars_999's Avatar
    Join Date
    Mar 2001
    Location
    Sioux Falls, SD, USA
    Posts
    519

    Re: OpenGL 3 Updates

    Hey Bobvodka, look at the new 4870 card, it actually performs on some tests as well as a GF 260 card, and with in 5fps of a GF 280!! This was in Crysis. At 1900x1200 4870 was 30fps, GT260 28.5, GT 280 34fps!! If AMD got their crap together with OpenGL I would consider one of these cards, but I want texture arrays, and Geometry shaders... Does ATI have PBO's, VTF support yet?

  7. #1027
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by ScottManDeath
    Since CUDA shaders go through the same driver optimizer as the GL/D3D shader optimizer, where is the difference?
    Look at what I replied to... this isn't just 'about shaders' but the whole backend, how they are designed and what maps in what way to the hardware.

    Right now for GPGPU stuff there is no unified front end, which is the first stumbling block, and if there was you lose 'power' right away because you've had to abstract certain details and work on the lowest common denominator. A situation which only gets worse as GPUs change over time.

  8. #1028
    Intern Contributor
    Join Date
    May 2007
    Location
    Germany
    Posts
    50

    Re: OpenGL 3 Updates

    The main argument for a common GPGPU shader API Element is the common part. As long as GPGPU Applications are bound to hardware from one manufacture I donít see them ready for mass market. The Direct3D 11 compute shader model may make it harder to get to the raw metal and get any cycle out of the GPU. But such shaders will run on every Direct3D 11 hardware and I have a good felling that the performance would not be that bad.

    Personally I am more interested in using them for graphics processing. There are still some areas that canít implemented very well with the three shader stages we have today.

  9. #1029
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    As long as GPGPU Applications are bound to hardware from one manufacture I donít see them ready for mass market.
    GPGPU applications are not for the mass market. People who actually need GPGPU are High-Performance computing people. Scientists and so forth. They can afford to buy whatever hardware they want and build software specifically for that hardware. But the common person, even gamers, just don't need a GPGPU.

  10. #1030
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3 Updates

    Exactly! And that is why it would be a stupid idea to base OpenGL on something like Cuda. It would mean to base a mainstream API needed everywhere on an API highly specialized for a task that is only needed by a very limited amount of people. Doing it that way round is bound to get you into trouble.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •