[Mesa-dev] Haiku using the Wayland state_tracker?

[Alexander von Gluck IV]

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,

> 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