Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

Thread: OpenCL 1.1 Specification Released

  1. #11
    Join Date
    Jun 2008
    Posts
    86

    Default

    Quote Originally Posted by bridgman View Post
    Agreed, but (a) I wasn't aware of any open source OpenCL-on-CPU implementations, and (b) at least this would allow chaos386 to stay with the open source graphics drivers (probably).
    Oh, I'm running fglrx (5850 owner); I don't have any philosophical opposition to closed source software. I was just curious if there was a pure OSS way of doing OpenCL, since I know there are people out there who prefer to do things that way.

    I did download the Stream SDK and will be looking through the OpenCL docs on the AMD website, though, so thanks!

  2. #12
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Well, you gotta love Gallium3D because once the state tracker is there; it is there for ever and for every card that has a driver out there.

  3. #13
    Join Date
    Jan 2009
    Posts
    274

    Default

    Quote Originally Posted by V!NCENT View Post
    Well, you gotta love Gallium3D because once the state tracker is there; it is there for ever and for every card that has a driver out there.
    think that is only partly true... since if for instance openCL requires features in the hardware driver that no other state tracker has needed yet that would still have to be implemented in the driver so drivers still have to be worked on independantly to some degree though probably not nearly as much as before.... thats just how it seems to me.

  4. #14
    Join Date
    Jun 2009
    Posts
    1,020

    Default

    Quote Originally Posted by cb88 View Post
    think that is only partly true... since if for instance openCL requires features in the hardware driver that no other state tracker has needed yet that would still have to be implemented in the driver so drivers still have to be worked on independantly to some degree though probably not nearly as much as before.... thats just how it seems to me.
    yeah you are rigth gallium won't provide 100% for the code for the 100% of the hardware outhere, the trackers contains the most common code that is pretty much hardware independant, ofc after the trackers is there you need the driver of that piece of hardware to be aware of that trackers.

    is pretty much like mesa(common code hardware independant) and dri/drm/kms(hardware dependant code )

  5. #15
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    837

    Default

    Quote Originally Posted by MisterIO View Post
    Well, it's kind of sad that the OS drivers don't have support for it, but does it really matter, at least at the moment? I mean, is there really anything that take advantage of OpenCL? With OS drivers still not supporting OpenGL 3(nor 4), without good acceleration for video playback(at least not for my r700) and with rather poor performaces for those still without a working Gallivm3D driver(in particular after the KMS switch), IMO the OpenCL support should be at the very last position on the OS drivers' TODO list.
    Re: video playback acceleration.

    If there were a fully working Gallium OpenCL state tracker, it would be feasible for someone to write an OpenCL version of the decoder for any video codec... and I'm about to start writing a thesis proposal to do just that (with VP8). I'm planning on targeting Nvidia+AMD's OpenCL run-times/libraries, but the moment there's a working Gallium OpenCL state tracker, it would work there too.

    Of course, I'll need to actually get the proposal written up, approved, and an advisor will need to be found, but it should work.... and hopefully it'll be simpler to code/maintain than a full OpenGL+GLSL implementation (which has been partially done for h.264). Hopefully the overhead won't kill the performance too much.

  6. #16
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by deanjo View Post
    Can't support something that physically isn't there.
    nvidia just failt to dev a shader based acceleration metod..

  7. #17
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,532

    Default

    Quote Originally Posted by Qaridarium View Post
    nvidia just failt to dev a shader based acceleration metod..
    They had no reason to build one. If you want to use GLSL acceleration that still can be done on a 8800 GTS. XBMC has had this option available for quite some time now.

  8. #18
    Join Date
    Jan 2010
    Posts
    333

    Default

    I'm not sure whether shader-based decode acceleration is very useful. VLD cannot be accelerated, but this is a very CPU-intensive task, especially when CABAC is used and at high bitrates - and that's where decode acceleration is most needed!
    As far as I know the shader-based acceleration implementations that exist already need quite a bit of shader horsepower. So, no acceleration on low-end GPUs or IGPs. Plus, much power consumption.

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    I haven't actually seen any shader-assisted H.264 decode implementations in public yet, have you ?

    It's very common to use shaders for render aka presentation (scaling, colour space conversion, post processing etc...) but I haven't seen anything that does MC, deblock and loop filtering on shaders and everything further upstream on CPU.

  10. #20
    Join Date
    May 2009
    Location
    Sweden
    Posts
    6

    Default Is there really so much advantage doing decoding on GPU?

    I was thinking about what is the big gain by doing video decoding on the GPU?

    It will let people with weak cpu:s watch hd video, thats true. But less and less people have cpu:s that cannot handle hd video. So that reason for doing video decode on gpu is decreasing as time passes.

    So by the time all this is implemented properly in OSS drivers. Maybe it is not all that useful for the big majority?

    Is it consuming less power when doing video decode on GPU versus CPU? Its still the same amount of decoding that has to be done. So which processor that does it shouldn't matter? Right?

    A lot of questions and maybe Im way out of line in my thinking...

Tags for this Thread

Posting Permissions

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