Sunday, August 5, 2012

textured cube (fullscreen!)

managed to bang out some basic texture support.. and also multi-tile rendering so I'm not limited to render targets that can fit in GMEM (512KiB on the a220 that I have in my touchpad), and of course this is using the freedreno shader assembler (no need for the binary blob):


maybe some day I'll figure out how to make better quality videos :-P

9 comments:

  1. Would the driver also work on the freescale imx53 boards? It uses an imageon z460 (should be more or less the same as the adreno 200). The freescale boards also suffer from closed source drivers.

    ReplyDelete
  2. I believe it might, although I'm not entirely sure how much different it is. I don't have any imx device, and the two devices I have are both a220. It would be interesting if someone who has an imx5x could try and let me know. (And if it doesn't work, grab some cmdstream dumps w/ the binary blob for comparision).

    Anyone have one of those genesi netbooks collecting dust, to donate/lend to the cause?

    ReplyDelete
    Replies
    1. I will try to get a freescale board for you. If that does not work out, I can only offer binary cmd dumps..

      I would love to see support for things like wayland on these devices.

      Furthermore there is an openvg accelerator (z160) with a very high pixel rate - not sure if quallcom also built that into their SOCs. At least for UI task that accelerator acchieves a high frame rate.

      Delete
    2. cool, thx.. the z160 is possibly the same as the 2d core in the snapdragon SoC's. I have an xorg driver (xf86-video-freedreno) which is using the 2d core. Although it still needs some love to get batching working properly to achieve decent performance. Wayland (or at least weston compositor) currently doesn't have any way to utilize 2d accel, unfortunately. Although that would be a useful thing because a lot of these SoC devices have some form of 2d accel, which is at least more power efficient (if not faster) than using the 3d core for simple 2d blit operations.

      Delete
    3. Does there exist an V4L2 or similar 2D accelerator API that would provide Wayland (or whatever) with the proper levers and buttons? Last time I checked the 2D accelerator was an open field of nothingness.

      Delete
    4. in reply to 'Unknown':

      well, for x11, that 2d API is EXA. The problem is this is inside x11 and not really something that could be useful for wayland.

      v4l2 isn't a terribly useful API for 2d accel. That makes about as much sense as using alsa as a 2d accel API :-P

      You need a userspace level API and something that can deal w/ sending a batch of commands for N # of blits to the gpu at one shot, to keep things nicely pipelined and performing well. You don't want a synchronous API, your performance would be worse than just using the CPU. And you don't really want a syscall per blit or to build your cmdstream in the kernel.

      I'm not sure what would make the most sense for wayland, perhaps a gl/egl extension. Or perhaps just some support to load a driver specific 2d backend. It does somehow how to work together w/ the gl stack to synchronize rendering/compositing for transformed surfaces (using 3d, which is also async/pipelined) and 2d.

      Delete
  3. Well in the case of these chips an OpenVG implementation with the EGL Image extensions, and a wayland compositor that prefers OpenVG over OpenGL|ES would do the trick.

    Actually I wanted to look into writing a compositor and OpenVG would be preferred. That would also reduce the load on the OpenGL|ES gpu that is probably used by most applications / games.

    The most annoying hurdle with the imx boards is that there is no way to share the render images between processes. There is a special extensions to allocate buffers, but that one works in the same process. No update on the im53 board, yet.

    I will poke more.

    ReplyDelete
    Replies
    1. fwiw, if you can use the same kgsl drivers from msm kernel, then I guess you should be able to use the msm drm driver, which gives you a way to pass buffer handles between processes..

      Delete