On Wed, 27 Mar 2013 15:45:23 -0500
Alexander von Gluck IV kallis...@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 kallis...@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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
