Announcement

Collapse
No announcement yet.

The Current State Of The Intel "Crocus" Gallium3D Driver

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

  • moriel5
    replied
    Originally posted by oiaohm View Post

    Do note pre-Broadwell even under windows stops at opencl 1.2 under windows. The reality that hardware is not really able to-do more than 1.2. NEO design presumes expecting more modern hardware features.

    There is a question if Brignet driver needs to be fixed or if work should instead be focused into https://github.com/google/clspv/blob...CLCOnVulkan.md like stuff and on the driver side the Vulkan support improved. Intel hardware without vulkan support does not have compute processors in the GPU design.

    Yes anything with Vulkan 1.0 can get opencl 1.2 by that google work on clspv. Brignet driver of Intel also stops at only 1.2 opencl on the hardware that NEO does not work on and all that hardware has Vulkan 1.0 support.

    There does need to be a question asked does the Brignet driver need to remain. Yes if Brignet does not remain the future would be opencl on Vulkan and Neo.
    I am quite aware that OpenCL 1.2 is the limit for my hardware (1.1 in the case of my GPU, possibly 1.2 once the Vulkan driver is ready). Though for now it is enough for basic testing of the functionality, and should serve me well until I can use OpenCL 2.0 hardware.

    Leave a comment:


  • moriel5
    replied
    Originally posted by Veerappan View Post

    There is support for r600g chips in clover starting with the evergreen series (HD5400+), but it's not perfect. The biggest issue I'm aware of is that there is a compute memory pool in the mesa side of the driver that tries to improve performance by reusing a gpu buffer to suballocate smaller buffer malloc requests. Sadly, it has to defrag that buffer occasionally and that defrag operation is not thread-safe causing crashes.

    R600 , like the radeonsi driver, also doesn't currently support the CL image extensions, and is also still limited to CL 1.1 due to a lack of printf in kernels.

    That being said, if you forced single CL contexts to avoid the threaded defrag issue, Clover worked for me last time I tested it on my HD6850.. but it was a while ago (WFH due to Covid kinda killed most of my motivation for hobby programming at the same desk afterhours... Hopefully that's not a permanent thing).
    Interesting, I never managed to get it to work, whether it be on my late Sapphire HD5850 Xtreme, my fake "HD7570" (in reality an HD6770), or my current Sapphire HD6950.

    Could you please help me on that front? Perhaps in another thread?
    Last edited by moriel5; 08 April 2021, 08:37 AM.

    Leave a comment:


  • moriel5
    replied
    Originally posted by QwertyChouskie View Post

    I suspect that this being Gallium-based, it should be pretty easy to wire up some basic form of Clover support, though I suspect things may be hardware-limited here.
    That makes sense, the hardware only supports up to OpenCL 1.2.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by moriel5 View Post
    airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
    Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.
    Do note pre-Broadwell even under windows stops at opencl 1.2 under windows. The reality that hardware is not really able to-do more than 1.2. NEO design presumes expecting more modern hardware features.

    There is a question if Brignet driver needs to be fixed or if work should instead be focused into https://github.com/google/clspv/blob...CLCOnVulkan.md like stuff and on the driver side the Vulkan support improved. Intel hardware without vulkan support does not have compute processors in the GPU design.

    Yes anything with Vulkan 1.0 can get opencl 1.2 by that google work on clspv. Brignet driver of Intel also stops at only 1.2 opencl on the hardware that NEO does not work on and all that hardware has Vulkan 1.0 support.

    There does need to be a question asked does the Brignet driver need to remain. Yes if Brignet does not remain the future would be opencl on Vulkan and Neo.

    Leave a comment:


  • Veerappan
    replied
    Originally posted by QwertyChouskie View Post

    I suspect that this being Gallium-based, it should be pretty easy to wire up some basic form of Clover support, though I suspect things may be hardware-limited here.
    There is support for r600g chips in clover starting with the evergreen series (HD5400+), but it's not perfect. The biggest issue I'm aware of is that there is a compute memory pool in the mesa side of the driver that tries to improve performance by reusing a gpu buffer to suballocate smaller buffer malloc requests. Sadly, it has to defrag that buffer occasionally and that defrag operation is not thread-safe causing crashes.

    R600 , like the radeonsi driver, also doesn't currently support the CL image extensions, and is also still limited to CL 1.1 due to a lack of printf in kernels.

    That being said, if you forced single CL contexts to avoid the threaded defrag issue, Clover worked for me last time I tested it on my HD6850.. but it was a while ago (WFH due to Covid kinda killed most of my motivation for hobby programming at the same desk afterhours... Hopefully that's not a permanent thing).

    Leave a comment:


  • geearf
    replied
    Originally posted by airlied View Post

    The batchbuffer submission is just too different. The big line is gen8+/iris can rely on softpin, ppgtt and 48-bit address space, whereas prior hw can't. Most of the code is shared anyways via blorp, compiler, isl etc so the crocus code itseif isn't a major amount of code, but there is no way we want it in iris.
    Thank you for the explanation!

    Leave a comment:


  • Aryma
    replied
    Originally posted by QwertyChouskie View Post

    I suspect that this being Gallium-based, it should be pretty easy to wire up some basic form of Clover support, though I suspect things may be hardware-limited here.
    it work fine in windows tho so I don't think this is hardware limited problem

    Leave a comment:


  • Aryma
    replied
    Originally posted by moriel5 View Post
    airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
    Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.

    I personally can attest that I really need OpenCL in my workflow, however my hardware's support for it is broken (Radeon HD6950 on R600g, with OpenCL being developed, by not yet ready, i5-4570 with Beignet unable to to find it's own libraries), and I currently am not in a financial situation where I can upgrade (even what I have, is nearly all 2nd or 3rd hand, even via dumpster diving (the i5, for example, came from a dead Dell Inspiron miniPC that someone threw out)).
    they even leave intel-vaapi-driver broken state again and move with Intel Media Driver with Broadwell (2014) and newer only

    god I hate this company i will move to AMD next time i have money to upgrade

    even intel driver in windows get dropped after one year after they released the hardware and keep bump the version number and fix some security issues you can check Haswell and Ivy Bridge drivers still have windows 8.1 name in it

    Leave a comment:


  • QwertyChouskie
    replied
    Originally posted by moriel5 View Post
    airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
    Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.

    I personally can attest that I really need OpenCL in my workflow, however my hardware's support for it is broken (Radeon HD6950 on R600g, with OpenCL being developed, by not yet ready, i5-4570 with Beignet unable to to find it's own libraries), and I currently am not in a financial situation where I can upgrade (even what I have, is nearly all 2nd or 3rd hand, even via dumpster diving (the i5, for example, came from a dead Dell Inspiron miniPC that someone threw out)).
    I suspect that this being Gallium-based, it should be pretty easy to wire up some basic form of Clover support, though I suspect things may be hardware-limited here.

    Leave a comment:


  • moriel5
    replied
    airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
    Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.

    I personally can attest that I really need OpenCL in my workflow, however my hardware's support for it is broken (Radeon HD6950 on R600g, with OpenCL being developed, by not yet ready, i5-4570 with Beignet unable to to find it's own libraries), and I currently am not in a financial situation where I can upgrade (even what I have, is nearly all 2nd or 3rd hand, even via dumpster diving (the i5, for example, came from a dead Dell Inspiron miniPC that someone threw out)).

    Leave a comment:

Working...
X