On Mon, 28 Apr 2014 10:30:02 +0300
Pekka Paalanen
wrote:
> Oh, that's the DRM set-master related thing. Once we move on to render
> nodes, you don't even need a VT to simply work on the GPU, let alone a
> display server. IOW, render nodes will just fix that, and you can use
> the GPU for computat
On Mon, 28 Apr 2014 01:42:43 +0200
Wolfgang Draxinger wrote:
> On Sun, 27 Apr 2014 18:25:45 +0300
> Pekka Paalanen
> wrote:
>
> > I guess I just don't understand what "switching X11 servers" means
> > here.
>
> It means, that if you have multiple X11 servers running on the same
> machine, each
On Sun, 27 Apr 2014 18:25:45 +0300
Pekka Paalanen
wrote:
> Sorry?
> ...
> Huh?
See below for an example and link to a demonstrator
> For FBO, you can create the storage with e.g. glTexImage2D, or some
> of the renderbuffer functions.
Storage is one thing. Being able to actually use it the oth
On Sun, 27 Apr 2014 18:13:04 +0300
Pekka Paalanen
wrote:
> Do they, really? Or does it happen on-demand, slowly RAM<->VRAM,
> causing hickups, a bit like traditional swapping RAM to disk?
The OpenGL specification doesn't define it. Drivers can implement it as
they want to.
> Especially when re-
On Sun, 27 Apr 2014 11:35:37 +0200
Wolfgang Draxinger wrote:
> On Sun, 27 Apr 2014 11:30:18 +0300
> Pekka Paalanen
> wrote:
>
>
> > > I'm still trying to get an GBM configuration working that
> > > targets an off-screen buffer so that OpenGL operations are
> > > carried out toward it on the GP
On Sun, 27 Apr 2014 14:45:44 +0200
Wolfgang Draxinger wrote:
> On Sun, 27 Apr 2014 13:57:45 +0200
> John Kåre Alsaker
> wrote:
>
> > We still are limited by both graphics memory and bandwidth.
> > A fullscreen 64bpp 4K client will use about 128 MB for the
> > framebuffer.
>
> Indeed. OTOH clie
On Sun, 27 Apr 2014 13:57:45 +0200
John Kåre Alsaker
wrote:
> Since VGA is a ting of the past, I'm more interested in what the
> display do.
Display devices always were nonlinear in their signal response. That's
why gamma LUTs got introduced in the first place, to deal with the
saturation effect
On Sun, Apr 27, 2014 at 12:30 PM, Wolfgang Draxinger
wrote:
> On Sun, 27 Apr 2014 12:11:39 +0200
> John Kåre Alsaker
> wrote:
>
>> I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
>> My patch has bit-rotted a bit now, but it gives you an idea about
>> what to do:
>> https://git
On Sun, 27 Apr 2014 12:11:39 +0200
John Kåre Alsaker
wrote:
> I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
> My patch has bit-rotted a bit now, but it gives you an idea about
> what to do:
> https://github.com/Zoxc/mesa/commit/73f39f1366287bab02c993cb3537980e89b3cdca
>
> M
I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
My patch has bit-rotted a bit now, but it gives you an idea about what to do:
https://github.com/Zoxc/mesa/commit/73f39f1366287bab02c993cb3537980e89b3cdca
My motivation for this was to have clients render with linear gamma.
One t
On Sun, 27 Apr 2014 11:35:37 +0200
Wolfgang Draxinger
wrote:
> > Btw. weren't FBConfigs a GLX thing?
>
> No, XRender actually; GLX just piggybacks on that.
Okay, that needs some explanation. While all functions that have
"FBConfig" in their name are part of GLX you actually have so use some
XRe
On Sun, 27 Apr 2014 11:30:18 +0300
Pekka Paalanen
wrote:
> > I'm still trying to get an GBM configuration working that targets
> > an off-screen buffer so that OpenGL operations are carried out
> > toward it on the GPU but without attaching it to a CRTC.
>
> I think you should do that with an F
On Sun, 27 Apr 2014 00:03:19 +0200
Wolfgang Draxinger wrote:
> On Sat, 26 Apr 2014 17:10:38 -0400
> "Jasper St. Pierre" wrote:
>
> > Outside of an X11 environment, the only standard is EGL, with a
> > Wayland backend for Wayland apps, or a GBM backend for native
> > modesetting.
>
> Well, GBM
On Sat, 26 Apr 2014 17:10:38 -0400
"Jasper St. Pierre" wrote:
> Outside of an X11 environment, the only standard is EGL, with a
> Wayland backend for Wayland apps, or a GBM backend for native
> modesetting.
Well, GBM is just another backend for EGL. In my GBM experiments I
copy'n'pasted this cod
used for rendering or compositing. Those
> > are where the limitations are, not Wayland. In the end, Wayland
> > only deals with handles to buffers, not pixels as such.
>
> I suspected as much. Do you happen to know how far the support for deep
> color is in Mesa and DRM? I kno
he end, Wayland
> only deals with handles to buffers, not pixels as such.
I suspected as much. Do you happen to know how far the support for deep
color is in Mesa and DRM? I know that OS-Mesa has some deep color
support; However OS-Mesa is a softpipe implementation that renders into
a user supplied m
On Sat, 26 Apr 2014 21:15:33 +0200
Wolfgang Draxinger wrote:
> Hi,
>
> could someone please fill me in, if and if yes, how deep color
> modes (more than 8 bits per color channel) are (going to be)
> supported and handled by the Wayland protocol, compositors and
> clients?
>
> I'm currently toyi
Hi,
could someone please fill me in, if and if yes, how deep color modes
(more than 8 bits per color channel) are (going to be) supported and
handled by the Wayland protocol, compositors and clients?
I'm currently toying around (for self educational purposes) with direct
access to the GPU (using
18 matches
Mail list logo
