Announcement

Collapse
No announcement yet.

Freedreno Graphics Driver Reaches Version 1.0

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

  • robclark
    replied
    Originally posted by Ancurio View Post
    Thanks for the detailed explanation. I looked up the definition of "binning" as "reducing the effects of minor observation errors", but I'm not quite sure how this relates to graphics drivers in detail. Can you explain this to me?
    I guess "binning" can mean a few different things in different contexts, such as separating out better batches of chips in the manufacture process and selling them with higher clock speed rating ("speed bin"), etc..

    In the context of adreno, hw binning pass is a pass that separates vertices into "bins" (or tiles) so that you don't have to re-process each vertex for each tile. For example, on a320, at 1024x768, the scene is split up and rendered as (of the top of my head) 12 tiles. Meaning that if you have 32k vertices, you are running the vertex shader and the hw is processing the resulting gl_Position 12 times 32k. At lower resolutions or apps with low vertex count (like say a window manager) this is pretty insignificant. But at higher resolutions, and more complex vertex shaders.. well, let's say that with xonotic you can definitely notice that the frame rate drops as the vertex count goes up.

    With hw binning, the driver generates a simplified vertex shader which only generates gl_Position (which can be done with the expiremental compiler optimizer branch, as it can do dead code elimination). And then the driver does a special binning pass with color pipe disabled to generate the visibility information used in the following rendering pass.

    fyi, https://github.com/freedreno/freedre.../Adreno-tiling

    Leave a comment:


  • przemoli
    replied
    Originally posted by 89c51 View Post
    On a mobile device you reaaaaaaaallly need an optimized driver. Battery life is important.
    State of their 3D optimizations (and esp. kernel part) do not bode well for blob driver.

    So give a bit time for such optimizations to be made for FLOSS driver.

    Leave a comment:


  • shmerl
    replied
    So, they'll wait until Freedreno will get enough optimizations. They surely aren't using it right now, with their release.

    Leave a comment:


  • 89c51
    replied
    Originally posted by shmerl View Post
    Jolla's device should benefit from this (they are already using Wayland). Even though they are supposedly using Android driver now with libhybris, but the plan was to replace that with native drivers when possible.
    On a mobile device you reaaaaaaaallly need an optimized driver. Battery life is important.

    Leave a comment:


  • Ancurio
    replied
    Originally posted by robclark View Post
    small note.. the XA support isn't merged yet. Early on I had some slight corruption/mis-rendering issues with it so it stayed on a branch. But I think I've figured out the gallium issue (seems there is a workaround needed for hw bug in a320), so I should revisit XA when I have time.

    As far as performance, for desktop stuff it should be as good or better than blob driver. (Well, that is a slightly artificial statement, because blob driver doesn't support gl and blob driver doesn't support linux, so essentially freedreno is infinite times faster.) I implement some scissor related optimizations that the blob driver does not, which really help for gnome-shell/compiz type workloads. For things like xbmc which are not vertex heavy, and simple shaders, it should be comparable (although, without non android drivers there is really no way to compare). For stuff with high vertex loads and complex shaders, the blob driver is almost certainly better at this stage (if it existed for linux)... for this I need two things: (a) compiler optimizing pass(es) and (b) hw binning support. I have an experimental branch with the former, which gives >10% boost in fps in xonotic, and gives me what I need to generate vertex shaders for hw binning pass (which is the next step). I can't quite say what the fps boost for hw binning support will be, but from some rough expirements I'm guestimating >20% at 1024x768 and more at higher resolutions.

    That all said, the focus so far has not been performance. It has been getting something that works at all. (See again comment about no linux blob driver.) Certainly there are known optimizations that will come with time, but you have to walk before you can run. But the nice thing is we don't have those pesky reclocking issues, so it shouldn't be >10x differences from blob driver.
    Thanks for the detailed explanation. I looked up the definition of "binning" as "reducing the effects of minor observation errors", but I'm not quite sure how this relates to graphics drivers in detail. Can you explain this to me?

    Leave a comment:


  • shmerl
    replied
    Jolla's device should benefit from this (they are already using Wayland). Even though they are supposedly using Android driver now with libhybris, but the plan was to replace that with native drivers when possible.

    Leave a comment:


  • przemoli
    replied
    Originally posted by Awesomeness View Post
    A) Android is Linux and B) Mesa in general works with Android, although the port is AFAIK mainly maintained by Intel for Android on Intel's own hardware.
    No android mods devs on phoronix?

    Michael more Android tests!!!

    Anyway, anyone announced that 1.0 on lets say: Cyanogenmod forums/mailing lists? There may be someone willing enough to make neccessary code changes (esspecially since it will reuse some of Intel work!)

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by bemerk View Post
    Where did they mention Android support? I only read so far about running linux on those devices.
    A) Android is Linux and B) Mesa in general works with Android, although the port is AFAIK mainly maintained by Intel for Android on Intel's own hardware.

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by 89c51 View Post
    The question is how it compares to the closed driver in performance and most importantly in features that save battery.
    No idea about battery but this independent comparison of a pre-1.0 version already declared it ?Good? while the blob is ?Horrible? regarding standards support.
    https://de.dolphin-emu.org/blog/2013...meshame/?cr=de

    Leave a comment:


  • robclark
    replied
    Originally posted by bemerk View Post
    As far as i see, all that was mentioned is linux support, the driver developer never lost a word about linux , so why are you having such high hopes?
    Just fwiw, while my personal interest is "traditional" linux (xorg, wayland), there is nothing about the libdrm or gallium parts of freedreno that are window system specific. If someone wants to figure out how to build and use freedreno on android (or webos or mir or whatever), that should be completely possible. Obviously you won't need xf86-video-freedreno on android or others which directly use GL(ES) for compositor. And it is possible that different environements trigger some bug that I haven't seen yet (although at least according to piglit freedreno is getting much more solid). I'll certainly help try to help debug and fix issues in other environments as best I can (it helps for rendering bugs if you can get an apitrace or a test program the reproduces the issue on an environement that I have, ie. wayland/xorg).

    Of course freedreno won't help with other aspects of getting new android running on old device (ie. porting newer kernel to older device, or somehow making other subsystems like camera work on older kernel). It would be nice if this was a less painful process, but I've yet to see a vendor android kernel that isn't a mess.

    But graphics has traditionally been the biggest stumbling block, and at least now that is not so much of an issue.

    Leave a comment:

Working...
X