[Mesa-dev] Haiku using the Wayland state_tracker?

[Pekka Paalanen]

On Wed, 27 Mar 2013 15:45:23 -0500
Alexander von Gluck IV <kallisti5 at unixzen.com> wrote:

> On 03/27/2013 2:37 am, Pekka Paalanen wrote:
> > On Tue, 26 Mar 2013 16:47:15 -0500
> > Alexander von Gluck IV <kallisti5 at unixzen.com> wrote:
> > 
> >> I've been hitting several brick walls working on the Haiku GL stuff.
> >> (mostly due to things being too complex for the time I have 
> >> available)
> >> 
> >> Given all the recent publicity for Wayland, I decided to look into 
> >> the
> >> wl_shm stuff.  From my point of view wl_shm looks *extremely* simple.
> >> 
> >> Does anyone see any reason *not* to use the wayland state_tracker for
> >> Haiku's GL rendering? The only possible down side I see is using EGL 
> >> vs
> >> OpenGL. (I admit I don't fully understand the pros and cons of EGL)
> > 
> > I'm not familiar with the "wayland state_tracker", so I can only
> > comment from the Wayland protocol perspective. I'm not sure what you
> > intend to do with wl_shm, either. Are you implementing Wayland
> > platform support?
> 
> To be honest, we're not related to Wayland in any way.  I'm looking for
> a simple interface between os and GL rendering. The Xorg interface to
> Mesa and Gallium always seemed like overkill for our needs,

Ah, well, I think this is not exactly the interface you are looking for.

The Wayland protocol interfaces, wl_shm and wl_drm, are only to
facilitate buffer passing between processes using the minimum amount of
information needed to be sent over the Wayland wire. Or rather to not
push pixels through the wire but handles and metadata.

To make that actually work, especially wl_drm, they rely on the OS
magic to let it happen. In our case, it is the kernel DRM, DRI2, and
probably some other acronyms I'm not completely familiar with. So what
you see in the Wayland protocol is just the skin of buffer passing, all
the crucial details are hidden below in the OS graphics stack, like how
to turn a GEM flink name into a buffer you can actually do something
with (or whatever).

I'm guessing that there is no magic way to make things work, other than
actually inventing your own magic to begin with, if it doesn't exist
yet.


Thanks,
pq

> > If you are only ever going to have software rendered GL, then I guess
> > you might use wl_shm. If you have any reason to believe you might ever
> > want hardware accelerated GL, then wl_shm won't work. (Actually, you
> > probably want to choose between wl_shm and something else according to
> > your renderer. Maybe.)
> 
> I noticed that the native Wayland code chooses dri or shm based on the
> rendering needs. Thats fine for us (although we don't have any of the
> dri stuff ported or wrapped yet)
> 
> > wl_shm basically deals with mmappable files, i.e. directly
> > CPU-accessible memory. Buffers suitable for hardware rendering or
> > texturing are often not CPU-accessible, or extremely slow for that.
> > Conversely, CPU-accessible memory is often not usable for GPU, or is
> > slow. And you really don't want to have extra copies between CPU and
> > GPU memory, especially just for buffer passing.
> > 
> > Mesa contains another Wayland protocol interface used for hardware
> > accelerated graphics buffers: wl_drm.
> > 
> > Also, EGL vs. OpenGL is like comparing a bucket to paint. EGL is just
> > one form of a bucket, that can give you OpenGL as the paint. There are
> > other buckets, and other paints, and you cannot use a bucket as paint,
> > nor paint as a bucket. Probably I just didn't understand what you are
> > actually comparing here. (and sorry for a bad analogue :-p)
> 
> This is actually a good example.  Our (Haiku's) GL Rendering with Mesa 
> swrast
> works fine at the moment. We also have an in-development Gallium driver
> (using llvmpipe or swpipe) *almost* working minus some on-screen stride 
> issues.
> The problem i'm trying to tackle is that by calling private Mesa and 
> Gallium
> functions externally.. the size of the paint can lid keeps changing and 
> keeping
> up between Mesa versions is consuming a lot of resources. (small 
> project trying
> to keep up with a large project, we have the same issue with Webkit)
> 
> > I have a blog post about Wayland, that is maybe not directly related 
> > to
> > your question, but might give some insight, I hope:
> > http://ppaalanen.blogspot.fi/2012/11/on-supporting-wayland-gl-clients-and.html
> 
> I'll take a look.  Thanks!
> 
>   -- Alex