Announcement

Collapse
No announcement yet.

AMD RadeonSI Gallium3D Begins Simple CL Demos

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic AMD RadeonSI Gallium3D Begins Simple CL Demos

    AMD RadeonSI Gallium3D Begins Simple CL Demos

    Phoronix: AMD RadeonSI Gallium3D Begins Simple CL Demos

    The open-source AMD RadeonSI Gallium3D driver is beginning to work when it comes to running simple OpenCL programs on the Radeon HD 7000 series graphics cards...

    http://www.phoronix.com/vr.php?view=MTM3ODM

  • Death Knight
    replied
    Originally posted by bridgman View Post
    Sorry, when I said "should work" I was saying "*do* work on other peoples systems and should work on yours too". Anything that is "starting to work" on SI was already working on Evergreen and NI (at least the non-Cayman NI's like yours).

    That said, AFAIK the only working programs right now are the tests that Tom and the other developers are using, along with bfgminer if built following the instructions in Tom's blog :

    http://www.stellard.net/tom/blog/

    Test programs are mentioned further down Tom`s blog, and can be found here :

    http://cgit.freedesktop.org/~tstellar/opencl-example/

    I haven`t heard anyone mention that the python OpenCL tests are working yet.
    http://cgit.freedesktop.org/~tstellar/opencl-example looks working. At least I have something to execute. Thanks!

    Leave a comment:


  • DestroyFX
    replied
    OpenCL for coin mining with opensource is useless until we :

    - can change the GPU clock the way we want, when we want
    - can change the memory clock the way we want, when we want
    - monitor the GPU temperature
    - monitor and change the fan speed

    We need the clocking for anything worth mining because bitcoin is not profitable for GPU mining anymore, Alt coin like litecoin, novacoin and other pump and dump crashcoin are, and for all of these, you need a GPU/MEM speed ratio of about 0.57. (like core 969Mhz, Mem 1700Mhz for my 7970's).

    Leave a comment:


  • bridgman
    replied
    Sorry, when I said "should work" I was saying "*do* work on other peoples systems and should work on yours too". Anything that is "starting to work" on SI was already working on Evergreen and NI (at least the non-Cayman NI's like yours).

    That said, AFAIK the only working programs right now are the tests that Tom and the other developers are using, along with bfgminer if built following the instructions in Tom's blog :

    http://www.stellard.net/tom/blog/

    Test programs are mentioned further down Tom`s blog, and can be found here :

    http://cgit.freedesktop.org/~tstellar/opencl-example/

    I haven`t heard anyone mention that the python OpenCL tests are working yet.

    Leave a comment:


  • Death Knight
    replied
    Originally posted by bridgman View Post
    Don't think that is correct. AFAIK the GCN (77xx and up) parts are catching up with the NI and earlier parts, ie the test programs that are starting to work on 7xxx should already be working on your 6850.
    Yes, they should but I think they are not. Any OpenCL program that I can find (GIMP, pyrit, bfgminer, python-opencl's .test() class) gives me error and couldn't complete anything but resulting GPU lockups and/or segmentation faults.
    It's hard to say that if it's in working state while python-opencl test fails even at "test_copy_1D " function.

    Code:
    death@triQuad:~> python
    Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import opencl
    >>> opencl.test()
    [<opencl.Device name='AMD BARTS' type=4L>]
    test_broadcast_0D (test.test_memobj.TestBuffer) ... ok
    test_broadcast_2D (test.test_memobj.TestBuffer) ... ok
    test_copy_1D (test.test_memobj.TestBuffer) ... FAIL
    test_copy_2D (test.test_memobj.TestBuffer) ... FAIL
    test_copy_2D_negative_stride (test.test_memobj.TestBuffer) ... expected failure
    test_copy_contig (test.test_memobj.TestBuffer) ... Segmentation fault
    death@triQuad:~>
    I wish it start to work soon.

    Leave a comment:


  • curaga
    replied
    Perhaps it will be useful if Michael states in several articles that Unigine needs fixing? Maybe his word has some more clout, making them notice.

    Leave a comment:


  • marek
    replied
    Originally posted by Michael View Post
    Most of the time when I try running Unigine on the open drivers usually results with incorrect rendering.
    The Unigine engine is probably the worst OpenGL engine you'll ever come across. It's not written for OpenGL, it's written for an OpenGL-like API that somehow happens to work with proprietary drivers. You need a series of out-of-spec workarounds to make it work with a strict OpenGL implementation like Mesa (Vadim already mentioned them in this thread). Yes, it's unbelievable how so beautiful Unigine benchmarks can be so bad, but it's true. There have been several attempts to contact Unigine for them to *finally* fix their engine.

    Note that the proprietary drivers pass about 70% of piglit, which can be interpreted such that they implement only 70% of OpenGL, which covers both strictness (disallowing invalid shader code and commands, which is very important) and correctness (if all shaders and commands are valid). The open source drivers usually pass about 95% of piglit. Obviously, some applications which work with proprietary drivers like the Unigine engine cannot work with Mesa due to its strictness. You can either say in your articles that Unigine is broken or you can pretend Unigine doesn't exist, but saying that it's a problem with Mesa is a lie.

    Leave a comment:


  • bridgman
    replied
    Originally posted by Death Knight View Post
    Now, 7000 series start to run OpenCL demos before 6000 series? Sad...
    Don't think that is correct. AFAIK the GCN (77xx and up) parts are catching up with the NI and earlier parts, ie the test programs that are starting to work on 7xxx should already be working on your 6850.

    Leave a comment:


  • Death Knight
    replied
    I really wonder when I could start to use any OpenCL program with my HD6850.
    Because it still doesn't work and have GPU lockup when I try to use any OpenCL program, it they doesn't give segmentation fault before!
    (Using llvm and mesa trunk...)

    Now, 7000 series start to run OpenCL demos before 6000 series? Sad...

    Leave a comment:


  • vljn
    replied
    Originally posted by curaga View Post
    Like Calinou said, Xonotic can already stress cards. It's not difficult at all to make any card slow, just keep adding effects
    A good benchmark is not always a slow benchmark, some very old game engine are likely to be slow if they are used to render scene too complex wrt the target they were designed for.
    Some custom map on UT99 were unplayable whereas still being less complex than UT2K4 one for instance.
    Recent gfx card improvements tend to reduce the number of draw call per frame : instancing does nothing fancy under the hood, it executes the same number of shader ; however the cpu only a couple of draw call instead of hundreds, that's why you can achieve 2 or 3x more fps, depending on the load. The same can be said for geometry shaders : they are slow, but they can be used to avoid multiple passes in some situations (cubemap textures) and represent an overall gain.

    Leave a comment:

Working...
X