Announcement

Collapse
No announcement yet.

ARM Freedreno Driver Begins Work On Gallium3D

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

  • ARM Freedreno Driver Begins Work On Gallium3D

    Phoronix: ARM Freedreno Driver Begins Work On Gallium3D

    Rob Clark has provided a status update on Freedreno, his reverse-engineered ARM open-source graphics driver for the Qualcomm Snapdragon / Adreno hardware...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Wait just a minute there... this looks like he has a working X driver with partial 2d and 3d acceleration....? So now he's about to take it and reshuffle it into g3d and drm, correct?
    Last edited by droidhacker; 25 October 2012, 04:05 PM.

    Comment


    • #3
      Originally posted by droidhacker View Post
      Wait just a minute there... this looks like he has a working X driver with partial 2d and 3d acceleration....? So now he's about to take it and reshuffle it into g3d and drm, correct?
      roughly, yes.. well, I've already "reshuffled" some stuff into libdrm_freedreno.. initially I started with code for dealing w/ GEM buffers and cmdstream submission sort of duplicated, but not quite the same (because there are some slight difference between 2d and 3d pipe cmd submission) in fdre and xf86-video-freedreno, so I had to do a bit of refactoring and update fdre to use GEM buffers (which it was not initially). And I also had to implement dri2, and solve some problems I'd been having with the 2d gpu previously.

      Now the big remaining piece is gallium driver.. I think most of the cmd-stream stuff that I'll need to know, I already do.. there might be a few little things I turn up as I go, but I don't expect anything major. But still, "reshuffle" might be an understatement.. you can consider fdre as a very simplistic driver. The point of which is to give me as simple as possible an environment to experiment with the command-stream and driving the 3d gpu to do different things, without all the overhead of full gl(es) compliance/api. So I'll probably keep fdre around for now, in parallel w/ gallium driver, because it is a useful tool for experimenting. But the biggest task for gallium driver will be the compiler. For fdre, I've just been writing the shaders in an assembly language syntax, because it is easier to try things out this way, and because mesa would anyways be providing the compiler front-end for the gallium driver.

      Comment


      • #4
        Originally posted by robclark View Post
        roughly, yes.. well, I've already "reshuffled" some stuff into libdrm_freedreno.. initially I started with code for dealing w/ GEM buffers and cmdstream submission sort of duplicated, but not quite the same (because there are some slight difference between 2d and 3d pipe cmd submission) in fdre and xf86-video-freedreno, so I had to do a bit of refactoring and update fdre to use GEM buffers (which it was not initially). And I also had to implement dri2, and solve some problems I'd been having with the 2d gpu previously.

        Now the big remaining piece is gallium driver.. I think most of the cmd-stream stuff that I'll need to know, I already do.. there might be a few little things I turn up as I go, but I don't expect anything major. But still, "reshuffle" might be an understatement.. you can consider fdre as a very simplistic driver. The point of which is to give me as simple as possible an environment to experiment with the command-stream and driving the 3d gpu to do different things, without all the overhead of full gl(es) compliance/api. So I'll probably keep fdre around for now, in parallel w/ gallium driver, because it is a useful tool for experimenting. But the biggest task for gallium driver will be the compiler. For fdre, I've just been writing the shaders in an assembly language syntax, because it is easier to try things out this way, and because mesa would anyways be providing the compiler front-end for the gallium driver.
        Wow. I had no idea that you've moved so far along with this. I'm sure that you hear this all the time, but I am extremely impressed and grateful for all the hard work you are putting into it.

        Comment

        Working...
        X