Announcement

Collapse
No announcement yet.

The Current State Of The Intel "Crocus" Gallium3D Driver

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

  • airlied
    replied
    Originally posted by geearf View Post
    Why is this a forked driver and not part of Iris? Are the architecture too different to have them in one driver?
    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.

    Leave a comment:


  • lorn10
    replied
    Originally posted by mannerov View Post

    blitImage is implemented by gallium, so all gallium drivers should advertise support for it.
    ...
    Thanks mannerov for this information. So you effectively solved that point. The "blitImage feature" is part of gallium, so any gallium driver includes it, - also Crocus. And that's also the reason why the i965 classic driver will most likely never get support for it.

    However, until now i didn't test Crocus, I am still on i965 and r600. But i will for sure test Crocus when it is somewhat more "applicable" also for normal Linux users.

    Leave a comment:


  • Aryma
    replied
    as 7gen user i thankful for them and i don't hope or ask for more performance i only went fix for tearing and better dithering for Banding Removal just like windows driver

    and remove texture flickering in desktop and opengl program

    Leave a comment:


  • mannerov
    replied
    Originally posted by lorn10 View Post
    That may be now somewhat the wrong place to post that "feature request" but it would be really GREAT if these awesome Crocus devs could also implement (sometime in the feature) the blitImage function into the new driver. (So far this is not already the case.)
    blitImage is implemented by gallium, so all gallium drivers should advertise support for it.
    Maybe you Crocus wasn't loaded for your card for some reason (did you use the env var to overload driver selection ?)

    Leave a comment:


  • lorn10
    replied
    Also from my side a BIG THANKS to the devs for their superb work in this matter!

    That may be now somewhat the wrong place to post that "feature request" but it would be really GREAT if these awesome Crocus devs could also implement (sometime in the feature) the blitImage function into the new driver. (So far this is not already the case.)

    That function is missing in the classic i965 driver and it will be probably never added. As a consequence of this it is not possible to switch on multi-GPU systems to another GPU. More information about that long-standing issue can be found here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4368

    Leave a comment:


  • ermo
    replied
    This feels like amdgpu support w/GCN 1/2/3 all over again. Still super pleased that it's happening, as I have both Westmere, SB, IB and Haswell hardware still.

    Thank you to Mr. Airlie (et al.) and RH for deciding to develop/sponsor this.

    Leave a comment:


  • M@GOid
    replied
    I for one appreciate the effort on this driver.

    Today a good shape OpenGL driver isn't used only for games, but on desktop rendering too. I have 3 systems still running on Ivy Bridge hardware, and the price hikes of the last year will force me to stick with them for some years to come.

    Leave a comment:


  • reba
    replied
    Has anything being said about merging Crocus back to Iris?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Leopard View Post
    Which in result you actually got a very inferior experience on Linux with some of those gpu's compared to Windows. With Ironlake for example.

    Those gpu's supports D3D10 on Windows but stuck at GL 2.1 on Linux which GL 2.1 is not counter part of D3D10 feature wise.
    https://en.wikichip.org/wiki/intel/h...hics_(ironlake)
    Ironlake is Westmere Intel did rename Ironlake to Westmere officially. Under windows Ironlake/Westmere what ever you want to call it only had opengl 2.1 even under windows so your opengl experience with Windows is no better than Linux here.
    https://www.phoronix.com/scan.php?pa...tem&px=MTMxMDQ

    Does not cover how you would have to implement opengl 3.0. Problem here there is extra acceleration silicon in Sandy Bridge contains stuff particularly for opengl 3.0.

    Horrible part here is DX10.0 feature greater than GL 2.1 but feature less than GL 3.0. CPU emulating missing GPU features to get up to opengl 3.0 on the Ironlake/Westmere may not turn out that great. This is a case where if you had mesa had a functional DX10 instead of just a DX9 interface this would be helpful.

    Opengl 3.3 on Sandy Bridge that is 6th gen can do a reasonable fist of DX10.1. 7th gen is the start of Vulkan on Linux.

    Yes also if you look it up the Ironlake/Westmere is only Dx feature level 10.0 in hardware was using DX10 included software emulation to expose DX 10.1 to applicactions. This kind of explains why even under windows why there is a huge performance gap between Sandy Bridge and Ironlake/Westmere as Sandy Bridge is full DX 10.1 feature level in hardware.

    Please also note large section of Gen 4 Intel hardware is also feature level DX 10.0 without the Intel driver turning on software emulation to take that up to 10.1. Yes that hardware also only exposed only opengl 2.1 and 2.0.

    Gen 5 and Gen 5.5 Ironlake/Westmere really was not that much of a improvement over Gen4 major thing was about Gen5 is that is moved into the cpu instead of being in the chip-set. Gen 4 and Gen 5 owners of those should not be expecting much improvement because that hardware is not that great in silicon. Really don't have that much CPU performance to trade to fix the issues.

    Leave a comment:


  • Leopard
    replied
    Originally posted by ms178 View Post
    I hope Crocus will be as feature rich and at least as fast as the classic driver, that would extend the usefulness of my Sandy Bridge laptop quite a bit. But that would mean OpenGL 3.3 support. Hopefully they will test it well, I don't want to see stability suffering from this move either. But at least Sandy Bridge doesn't seem to be the focus for now, at least from Dave's blog post it reads that it is the least tested of all.
    Classic driver is on life support. And still regresses now and then, despite that and as it is in low importance area getting fixes for that is very unlikely compared to how fast you can get a fix on newer driver.

    Don't need to worry, upstream Mesa won't accept a driver that is in really bad shape and make it default to everyone until it is battle tested.

    Leave a comment:

Working...
X