Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

  • Qaridarium
    replied
    Originally posted by BlackStar View Post
    OpenCL is not a graphics API. It can be used for graphics-related tasks, but it is slower than GL/D3D because it lacks certain fixed-function features (e.g. blending).

    Of course you can do raytracing in GL/D3D, what do you think people where using all those years before OpenCL was released?
    in my point of view all fixed function pipelines are just bad in visual Quality.

    this fake shader lights and shader effects are just bad in quality if you compare this to an real raytracing lighting.

    show me your D3D code man.

    they do raytracing in software on the cpu in the past-

    Leave a comment:


  • BlackStar
    replied
    Originally posted by Qaridarium View Post
    it makes sence thats because openCL is the only API who can beat directX9/10/11

    you can do better graphics in openCL than directX11 can do it.

    thats because you can do raytracing in openCL and directX11 can not handle raytracing.
    OpenCL is not a graphics API. It can be used for graphics-related tasks, but it is slower than GL/D3D because it lacks certain fixed-function features (e.g. blending).

    Of course you can do raytracing in GL/D3D, what do you think people where using all those years before OpenCL was released?

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by 89c51 View Post
    since it was mentioned using opencl for graphics related stuff (even thought i suspect airlied's post was a bit sarcastic )


    does this thing makes sense???

    i thought opencl was a framework for tasks that are computation intensive ie decoders, math heavy stuff etc ???
    it makes sence thats because openCL is the only API who can beat directX9/10/11

    you can do better graphics in openCL than directX11 can do it.

    thats because you can do raytracing in openCL and directX11 can not handle raytracing.

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by smitty3268 View Post
    Why, so we could all play a ray-traced game at 1 fps? I'll stick with something that will actually be playable, thanks.

    OpenCL still sucks in the binary drivers enough that no one is committing to it yet, let's wait for someone to at least start using the API before the OSS devs move their attention away from OpenGL.
    you don't unterstand what raytracing is thats because there are no FPS anymore you get unlimied fps on any kind of hardware with raytracing.

    on raytracing you have rays per seconds RPS

    less RPS means just more black or white pixels left per frame.

    Leave a comment:


  • Pfanne
    replied
    Originally posted by 89c51 View Post
    since it was mentioned using opencl for graphics related stuff (even thought i suspect airlied's post was a bit sarcastic )


    does this thing makes sense???

    i thought opencl was a framework for tasks that are computation intensive ie decoders, math heavy stuff etc ???
    opencl allows you to do massive parallelized computing.
    thats pretty much what you do, whenever you try to get something onto your screen
    most of the time you can split the rendering of your screen into many tiny jobs. (sounds ideal for opencl doesnt it)
    opencl is probably only viable for raytracing. other stuff should probably still be handled by opengl.

    Leave a comment:


  • 89c51
    replied
    since it was mentioned using opencl for graphics related stuff (even thought i suspect airlied's post was a bit sarcastic )


    does this thing makes sense???

    i thought opencl was a framework for tasks that are computation intensive ie decoders, math heavy stuff etc ???

    Leave a comment:


  • Veerappan
    replied
    Originally posted by HokTar View Post
    So this means you have started working on the vp8 decoder? Would be awesome!
    Yeah, I've started work on it. Nothing to show for it yet beyond a configure option and some stub code that gets inserted into the runtime cpu detection blocks. I've basically added in the infrastructure to let me do the OpenCL execution, but haven't really fleshed out the implementation yet.

    Before I can really go much further, I'll be doing some more profiling the standard C code and refactoring it a bit to make it more conducive to execution on GPUs, then the real OpenCL fun begins.

    As for the implementation, I'm currently doing it with AMD's Stream/OpenCL run-time in Ubuntu, but some of the testing will also happen on Nvidia + Mac/Win.

    Leave a comment:


  • HokTar
    replied
    Originally posted by Veerappan View Post
    Yeah, I noticed that Zack had started committing to the clover branch again a few days ago. This definitely makes me happy, as it means that I'll eventually actually benefit from the results of my own thesis project.
    So this means you have started working on the vp8 decoder? Would be awesome!

    Leave a comment:


  • Veerappan
    replied
    Originally posted by HokTar View Post
    I can understand Qaridarium in the sense that OpenCL would be nice, fortunately Zack restarted his work, so maybe the state tracker will be finished. After that support would be welcome in the drivers.

    Porting Wayland to OpenCL is by no means the job of radeon developers, so please stop that Qaridarium.
    Yeah, I noticed that Zack had started committing to the clover branch again a few days ago. This definitely makes me happy, as it means that I'll eventually actually benefit from the results of my own thesis project.

    Leave a comment:


  • bridgman
    replied
    If I remember the thread correctly the context was 100 devs targetted at performance improvement, not porting Wayland to OpenCL

    Leave a comment:

Working...
X