Re: [PATCH xserver] glamor: Disable logic ops when doing compositing

Hi, AFAIK we disable logic ops after each usage, so this seems a bit redundant to me. Did we miss one usages? As logic ops aren't very common, this sounds good to me. Am 2016-05-13 13:29, schrieb Keith Packard: If the logic op gets left enabled, it overrides the blending operation, causing i

Re: [PULL] glamor-next

Am 2015-03-26 03:33, schrieb Eric Anholt: The only reason _nf is useful is if you need to implement faster software fallbacks -- otherwise, you should wrap above glamor, since _nf would have been equivalent to calling down. For faster fallbacks, we could delay the uploading part at the end of

[PATCH] xwayland: Set glamor filter to nearest

glEGLImageTargetTexture2DOES only set the first level. Mesa handles this new texture as incomplete and renders a black screen. We also want to prevent linear filtering. https://bugs.freedesktop.org/show_bug.cgi?id=81800 Signed-off-by: Markus Wick --- hw/xwayland/xwayland-glamor.c | 3 +++ 1

[PATCH] xwayland: Set glamor filter to nearest

://bugs.freedesktop.org/show_bug.cgi?id=81800 Signed-off-by: Markus Wick --- hw/xwayland/xwayland-glamor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index 09b454f..dd85518 100644 --- a/hw/xwayland/xwayland-glamor.c +++ b/hw

Re: 1.17 status and schedule

Yeah, I did wrote it. But meanwhile, I'd remove the MAX_LEVEL parameter as this isn't allowed in gl es. @Jasper: Texture storage isn't possible here as this texture is allocated by egl. ___ xorg-devel@lists.x.org: X.Org development Archives: http://l

Re: [PATCH] glamor: Use GL_STREAM_READ also for read/write access to a PBO

STREAM (used once) READ (accessed by the CPU), so Reviewed-by: Markus Wick ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Revert "glamor: Fix coordinates handling for composite source/mask pictures"

Hi, kwin still works fine. If you'll remove the "ErrorF" lines, this patch is: Reviewed-by: Markus Wick Am 2014-07-17 01:13, schrieb Keith Packard: I think I understand the code and now believe that both the original fixed versions are incorrect. However, I cannot repro

Re: [PATCH] glamor: Fix stack corruption, glGet on GL_MAX_VIEWPORT_DIMS returns two values

Oh, how did I miss this ... Reviewed-by: Markus Wick Am 2014-06-28 21:27, schrieb Tomasz Borowik: From 0a6d1c900b6d5559c50c703480a479a59689b8be Mon Sep 17 00:00:00 2001 From: timon37 Date: Sat, 28 Jun 2014 21:26:27 +0200 Subject: [PATCH] glamor: Fix stack corruption in glamor_init, glGet on

Re: [PATCH 04/13] glamor: Use glamor_program and GL_LINES for 0-width lines

Hi Keith, here a small summary of my monolog on #org-devel: Am 2014-05-13 18:02, schrieb Keith Packard: So in the end, I fear we have to add an offset based on the direction of the line. But this shouldn't be as hard with instancing :) No, we just need to move the lines so that they line up w

[PATCH 1/3] glamor: Fix memory leak in put_image

Signed-off-by: Markus Wick --- glamor/glamor_image.c | 1 + 1 file changed, 1 insertion(+) diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c index 4791d08..c087a13 100644 --- a/glamor/glamor_image.c +++ b/glamor/glamor_image.c @@ -92,6 +92,7 @@ glamor_put_image_bail(DrawablePtr

[PATCH 3/3] glamor: Choose max fbo size by texture + viewport size

The max size of renderbuffers and texture often match by accident, but as we always use textures, we should check for the right flag. Also check for viewport size as this may be lower and we want to render to almost every pixmap. Signed-off-by: Markus Wick --- glamor/glamor.c | 5 - 1

[PATCH 2/3] glamor: Fix no-mipmap allocations

vram wasting warnings. Signed-off-by: Markus Wick --- glamor/glamor_fbo.c| 1 + glamor/glamor_font.c | 1 + glamor/glamor_pixmap.c | 1 + 3 files changed, 3 insertions(+) diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c index 5521683..090dfd8 100644 --- a/glamor/glamor_fbo.c +++ b/g

Re: [PATCH 02/13] glamor: Add glamor_program based copy acceleration

Am 2014-05-13 17:34, schrieb Keith Packard: Sure, if glsl had a 'round' function I'd use it in a second :-) It was added in glsl130. As you use uvec which was also added in glsl130, it's fine. I'm a bit worried about this loop order. We don't change the programm at all, so glamor_use_progra

Re: [PATCH 05/13] glamor: Add glamor_program based 0-width dashed lines

Am 2014-05-06 00:02, schrieb Keith Packard: +static const char on_off_fs_exec[] = +" float pattern = texture2D(dash, vec2(dash_offset, 0.5)).w;\n" +" if (pattern == 0.0)\n" +" discard;\n"; Did you care about the sampler configuration? eg with linear filte

Re: [PATCH 04/13] glamor: Use glamor_program and GL_LINES for 0-width lines

Am 2014-05-06 00:02, schrieb Keith Packard: +static const glamor_facet glamor_facet_poly_lines = { +.name = "poly_lines", +.vs_vars = "attribute vec2 primitive;\n", +.vs_exec = (" vec2 pos = vec2(0.0,0.0);\n" +GLAMOR_POS(gl_Position, primitive.xy)), +}; iirc th

Re: [PATCH 02/13] glamor: Add glamor_program based copy acceleration

src, ... +glTextureBarrierNV(); I think a comment is required here why we have to call glTextureBarrierNV at all. eg what happens when we get two copy calls in a row, both doesn't overlap, but they overlap each other. So the second call might want to r

Re: [PATCH 13/20] glamor: Add glamor_program based copy acceleration

Am 2014-03-19 06:09, schrieb Keith Packard: +glamor_pixmap_loop(src_priv, src_box_x, src_box_y) { +glamor_pixmap_loop(dst_priv, dst_box_x, dst_box_y) { +for (b = 0; b < nbox; b++) { Are you sure that this loop order is safe? Eg what happens, when we copy the

Re: [PATCH 14/20] glamor: stub out lines

Am 2014-03-24 20:47, schrieb Keith Packard: Even still, uxa is significantly faster than glamor on this one; uxa has a simple test for a request that contains only vertical and horizontal lines and fills those as rectangles. We could easily do the same thing in glamor, which should yield better

Re: [PATCH 14/20] glamor: stub out lines

Am 2014-03-24 06:28, schrieb Keith Packard: 1: intel-glamor.perf 2: intel-glamor-line.perf 1 2 Operation - - 471000.023100.0 ( 490.446) 1-pixel line 297000.020900.0

Re: [PATCH 10/20] glamor: Add glamor_program based fill/set/get spans

Am 2014-03-20 22:55, schrieb Keith Packard: tbh, without an PBO, this is wrose than the fb fallback as it's one stall per span. Yes, it's completely miserable. However, it will never be called as the only paths to get here are short-circuited above this in the driver. The only way to even tes

Re: [PATCH 10/10] glamor: Add glamor_program based poly_text and image_text

Am 2014-03-21 00:43, schrieb Keith Packard: more important to only get one mipmap level: max_level = 0 I copied this code from elsewhere; do you have a substitute suggestion? glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0); The other parameters are sampler parameters, max_level is a te

Re: [PATCH 00/10] First Glamor core acceleration attempt

Am 2014-03-21 00:46, schrieb Keith Packard: Patches 7-9 are really nice, but there should be a glsl130+instancing fallback with another vertex format + shaders. I'd like to know which hardware is going to need this particular fallback? eg ironlake. But I more think about new GPU where the driv

Re: [PATCH 14/20] glamor: stub out lines

Am 2014-03-20 23:22, schrieb Keith Packard: I think this functions are worth to reimplement. eg horizontal lines are used a lot and very slow on mi. Having sped up the underlying functions, they're not terrible at this point: 200 reps @ 0.0035 msec (288000.0/sec): 500-pixel horizont

Re: [PATCH 07/10] glamor: Add glamor_program PolyPoint implementation

Am 2014-03-20 23:35, schrieb Keith Packard: We are used to also disable the gl program here unnecessaryly. I want to strip them all, so I'm fine without it, but it isn't fair for a performance comparison. I stripped them out in an earlier patch; we could measure performance at that point?

Re: [PATCH 13/20] glamor: Add glamor_program based copy acceleration

Am 2014-03-20 23:07, schrieb Keith Packard: +glCopyPixels (dx1 + dx - src_box->x1, + dy1 + dy - src_box->y1, + dx2 - dx1, dy2 - dy1, GL_COLOR); This functions are deprecated fortunately. Please don't use them

Re: [PATCH 00/20] New glamor core rendering code (v2)

This patch series is a very nice cleanup. I like the new way how this functions should be implemented, but the shader generator. Plain GLSL + predefined header are less confusing and more flexible imo. We also have to figure out on which gl extension we want to rely on. eg I don't think we sho

Re: [PATCH 14/20] glamor: stub out lines

I think this functions are worth to reimplement. eg horizontal lines are used a lot and very slow on mi. How are the interpolation requirement for a line? Is it possible to achive them with an opengl quad? Am 2014-03-19 06:09, schrieb Keith Packard: Use mi line code for now Signed-off-by: Kei

Re: [PATCH 13/20] glamor: Add glamor_program based copy acceleration

Am 2014-03-19 06:09, schrieb Keith Packard: Uses glCopyPixels for self-copies, otherwise paints with textures. Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy plane when both objects are in memory Includes copy_window acceleration too. Signed-off-by: Keith Packard --- gla

Re: [PATCH 10/20] glamor: Add glamor_program based fill/set/get spans

Am 2014-03-19 06:09, schrieb Keith Packard: This accelerates spans operations using GPU-based geometry computation Signed-off-by: Keith Packard --- glamor/Makefile.am| 1 + glamor/glamor.c | 2 +- glamor/glamor_core.c | 4 +- glamor/glamor_priv.h | 18 +++ glamor/glamor_span

Re: [PATCH 09/20] glamor: Add glamor_program PolyPoint implementation

Am 2014-03-19 06:09, schrieb Keith Packard: This accelerates poly point when possible by off-loading all geometry computation to the GPU. Signed-off-by: Keith Packard --- glamor/glamor_polyops.c | 92 ++--- glamor/glamor_priv.h| 3 ++ 2 files

Re: [PATCH 07/20] glamor: Add simple upload/download functions in glamor_transfer

Am 2014-03-19 06:09, schrieb Keith Packard: These use glTexSubimage2D for upload and glReadPixels for download. There are a variety of interfaces to the basic function as needed by the callers. Signed-off-by: Keith Packard --- glamor/Makefile.am | 2 + glamor/glamor_transfer.c | 260 +

Re: [PATCH 06/20] glamor: Add infrastructure for generating shaders on the fly

Am 2014-03-19 06:09, schrieb Keith Packard: This just adds a bunch of support code to construct shaders from 'facets', which bundle attributes needed for each layer of the rendering system. At this point, that includes only the primtive and the fill stuff. Signed-off-by: Keith Packard --- glam

[PATCH 01/10] kdrive: Remove duplicated definitions of some XV-related structs.

From: Eric Anholt v2: Fix crash because of removed strdup. (by Markus Wick) --- hw/kdrive/src/kxv.c | 27 ++- hw/kdrive/src/kxv.h | 36 ++-- 2 files changed, 4 insertions(+), 59 deletions(-) diff --git a/hw/kdrive/src/kxv.c b/hw/kdrive

[PATCH 04/10] glamor: Use epoxy_gl_version() instead of rolling our own.

--- glamor/glamor.c | 6 +++--- glamor/glamor_core.c | 23 --- glamor/glamor_priv.h | 5 - 3 files changed, 3 insertions(+), 31 deletions(-) diff --git a/glamor/glamor.c b/glamor/glamor.c index 9d171b7..ef969e2 100644 --- a/glamor/glamor.c +++ b/glamor/glamor.c @@ -

[PATCH 06/10] glamor: Select VBO path by ARB_mbr extension.

The mbr path was hard coded enabled for desktop gl and disabled for gles. But there are both, desktop without mbr and mobiles with mbr. --- glamor/glamor.c | 2 ++ glamor/glamor_priv.h | 1 + glamor/glamor_vbo.c | 4 ++-- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/glamor/

[PATCH 03/10] glamor: Use epoxy_has_gl_extension() instead of rolling our own.

--- glamor/glamor.c | 10 +- glamor/glamor_core.c | 22 -- glamor/glamor_priv.h | 1 - 3 files changed, 5 insertions(+), 28 deletions(-) diff --git a/glamor/glamor.c b/glamor/glamor.c index 0f7d68b..9d171b7 100644 --- a/glamor/glamor.c +++ b/glamor/glamor.c @@ -3

[PATCH 07/10] glamor: Don't reset GL_ELEMENT_ARRAY_BUFFER as it's always bound to the same buffer.

--- glamor/glamor_fill.c | 3 --- glamor/glamor_gradient.c | 4 glamor/glamor_render.c| 6 +- glamor/glamor_trapezoid.c | 6 -- 4 files changed, 1 insertion(+), 18 deletions(-) diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c index 7461b62..2fa726e 100644 --- a/glam

[PATCH 08/10] glamor: Remove unneeded unbindings.

They are already cleared in glamor_put_vbo_space. --- glamor/glamor_gradient.c | 8 1 file changed, 8 deletions(-) diff --git a/glamor/glamor_gradient.c b/glamor/glamor_gradient.c index ce24d73..c24f342 100644 --- a/glamor/glamor_gradient.c +++ b/glamor/glamor_gradient.c @@ -1120,8 +1120

[PATCH 09/10] glamor: Drop feature dependent optimization on startup.

We don't care that much about startup time to write different code paths... --- glamor/glamor_render.c | 23 +++ 1 file changed, 3 insertions(+), 20 deletions(-) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index 62236b9..cdf8eff 100644 --- a/glamor/glamor_rend

[PATCH 00/10] glamor cleanup series

But I still don't know if the last patch is worth as this code will likely be removed soon by Keith. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 02/10] glamor: Use glsl "fract/mod" instead of "while" in gradient shaders.

This fixes gtkperf. It seemed to hang forever. --- glamor/glamor_gradient.c | 48 1 file changed, 4 insertions(+), 44 deletions(-) diff --git a/glamor/glamor_gradient.c b/glamor/glamor_gradient.c index f77d6a8..38dac68 100644 --- a/glamor/glamor_gr

[PATCH 05/10] glamor: Update GL requirements to 2.1.

We will never ever run on OpenGL 1.2 as we use shaders everywhere. 2.0 may be enough, but we also often use PBOs and our big shaders won't fit into the first GLSL limits. --- glamor/glamor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/glamor/glamor.c b/glamor/glamor.c i

[PATCH 10/10] glamor: Use vbo for solid boxes.

--- glamor/glamor_fill.c | 40 1 file changed, 12 insertions(+), 28 deletions(-) diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c index 2fa726e..3286aa1 100644 --- a/glamor/glamor_fill.c +++ b/glamor/glamor_fill.c @@ -190,9 +190,6 @@ _glamor_solid_

Re: [PATCH 00/10] First Glamor core acceleration attempt

Patch 1 seems to fix my issue on nvidia, so: Tested-by: Markus Wick Patches 2-5 are: Reviewed-by: Markus Wick Patches 7-9 are really nice, but there should be a glsl130+instancing fallback with another vertex format + shaders. Patch 10 also have to check for gl extensions. We could fall

Re: [PATCH 06/10] glamor: Add infrastructure for generating shaders on the fly

First, I like to have some common functions to compile our shaders, bind common uniforms, defining common headers, ... But tbh I don't see why it's easier to split up the glsl source completely. Most shaders aren't more than 5 loc, so they are easier to read entirely. In dolphin, we've a common

Re: [PATCH 10/10] glamor: Add glamor_program based poly_text and image_text

Am 2014-03-14 07:30, schrieb Keith Packard: diff --git a/glamor/glamor_font.c b/glamor/glamor_font.c new file mode 100644 index 000..4f303b9 --- /dev/null +++ b/glamor/glamor_font.c @@ -0,0 +1,181 @@ +/* + * Copyright © 2014 Keith Packard + * + * Permission to use, copy, modify, distribute, a

Re: [PATCH 08/10] glamor: Add glamor_program based fill_spans

Am 2014-03-14 07:30, schrieb Keith Packard: diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c index 96723c0..8c10c92 100644 --- a/glamor/glamor_core.c +++ b/glamor/glamor_core.c @@ -410,7 +410,7 @@ glamor_stipple(PixmapPtr pixmap, PixmapPtr stipple, } GCOps glamor_gc_ops = { -.FillS

Re: [PATCH 09/10] glamor: Add glamor_program based poly_fill_rect

This one looks so similiar with your last one, isn't there a way to merge them? There would be an unneeded multiplication in the shader and the padding with one, everything else could be as it is. So there are also the same issues as in the last patch. __

Re: [PATCH 07/10] glamor: Add glamor_program PolyPoint implementation

Am 2014-03-14 07:30, schrieb Keith Packard: diff --git a/glamor/glamor_polyops.c b/glamor/glamor_polyops.c index 1484d80..eac1688 100644 --- a/glamor/glamor_polyops.c +++ b/glamor/glamor_polyops.c @@ -27,17 +27,93 @@ */ #include "glamor_priv.h" +#include "glamor_transform.h" + +static const g

Re: [PATCH 03/10] glamor: Unbind GL_ARRAY_BUFFER in glamor_put_vbo_space

Am 2014-03-14 07:29, schrieb Keith Packard: diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c index 5e98bfe..31e0730 100644 --- a/glamor/glamor_vbo.c +++ b/glamor/glamor_vbo.c @@ -153,6 +153,7 @@ glamor_put_vbo_space(ScreenPtr screen) glBufferData(GL_ARRAY_BUFFER, glamor_priv->vbo_o

Re: [PATCH 02/10] kdrive: Xv code expects attribute names to be allocated each generation

Yeah, this fixes a crash in "kdrive: Remove duplicated definitions of some XV-related structs.". But as this patch was skipped in the megaseries, there is no need in only applying this fix. Maybe squashing both patches together as the origin was a nice cleanup? Am 2014-03-14 07:29, schrieb Kei

Re: glamor-server subset patch bomb

wow, big patch series ... Patches 3-5, 7-22, 24-27 are: Reviewed-by: Markus Wick But as 21-22 are very big one, I'd like to see another review from someone familiar with the X11 renderings. But the gl code is fine :D Patches 1, 2, 6, 23 also looks fine for me, but I don't kno

Re: [PATCH 23/27] glamor: Improve the performance of line fallbacks.

Is there a generic mi fallback for all poly_lines? If not, I'd suggest to move this logic into mi itself. Am 2014-03-11 22:30, schrieb Eric Anholt: If the lines aren't solid-filled vert/horiz solid-filled rectangles, we fall back. libreoffice has some diagonal lines, and the performance of the

Re: [PATCH 22/27] glamor: Improve the performance of PolyGlyphBlt.

Are we able to add cached textures to CharInfoPtr? If not, then this would be the ideal use case for texture_arrays ;) Again, using GL_POINTS and check for every bit on CPU isn't the way to go. Am 2014-03-11 22:30, schrieb Eric Anholt: Using the same idea as the previous PushPixels code, just

Re: [PATCH 21/27] glamor: Improve the performance of PushPixels by, well, pushing pixels.

I didn't find any issues in this patch, but I don't see the point: Do we really want to convert a pixmap with 1 bit per pixel into a list of enabled pixels on cpu? Isn't it as easy to upload this pixmap as texture and do everything else in the pixel shader? In this way, we won't have to care ab

Re: [PATCH 18/27] glamor: Allow nested mapping of pixmaps.

Am 2014-03-11 22:30, schrieb Eric Anholt: The common pattern is to do nested if statements making calls to prepare_access() and then pop those mappings back off in each set of braces. Some cases checked for src == dst to avoid leaking mappings, but others didn't. Others didn't even do the neste

Re: [PATCH 16/27] glamor: Replace some goofy enum-likes with a real enum.

Am 2014-03-11 22:30, schrieb Eric Anholt: This unpacks the bitfield into an int size, but my experience has been that packing bitfields doesn't matter for performance. Signed-off-by: Eric Anholt --- glamor/glamor_fbo.c | 2 +- glamor/glamor_priv.h | 25 - 2 files chan

Re: [PATCH 05/27] glamor: Do glyph private init at screeninit time, and other stuff at CSR.

Am 2014-03-11 22:30, schrieb Eric Anholt: diff --git a/glamor/glamor.h b/glamor/glamor.h index e25dc73..9cda46d 100644 --- a/glamor/glamor.h +++ b/glamor/glamor.h @@ -131,14 +131,6 @@ extern _X_EXPORT void glamor_set_screen_pixmap(PixmapPtr screen_pixmap, extern _X_EXPORT uint32_t glamor_get_pi

Re: [PATCH 9/9] glamor: Use buffer_storage

Am 2014-03-10 21:09, schrieb Eric Anholt: On release builds, glGetError won't be called and so this won't clear the gl error log. So we'll fall back to the mbr code because of any gl error somewhere in glamor. Yeah, I think that's fine -- you shouldn't have any errors, anyway. But then, we sh

Re: glamor VBO series

There are some trival issues in patch 7 and 9. After fixing them, patches 2-9 will be: Reviewed-by: Markus Wick Am 2014-03-09 05:07, schrieb Eric Anholt: Here's a series for the reusable VBO support code in glamor. The Render code using it still pretty scary, but it seems to work, and

Re: [PATCH 7/9] glamor: Extract the streamed vertex data code used by Render.

Am 2014-03-09 05:07, schrieb Eric Anholt: diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c new file mode 100644 index 000..be2c2af --- /dev/null +++ b/glamor/glamor_vbo.c @@ -0,0 +1,138 @@ +/* + * Copyright © 2014 Intel Corporation + * + * Permission is hereby granted, free of charge, t

Re: [PATCH 9/9] glamor: Use buffer_storage

Am 2014-03-09 05:07, schrieb Eric Anholt: v2: - Make the default buffer size a #define. (by Markus Wick) - Fix the return offset for mapping with buffer_storage. (oops!) v3: - Avoid GL error at first rendering from unmapping no buffer. - Rebase on the glBindBuffer(GL_ARRAY_BUFFER, 0

Re: [PATCH 8/9] glamor: Fix requested composite VBO size.

Am 2014-03-09 05:07, schrieb Eric Anholt: The argument to setup_composte_vbo is the number of verts. Signed-off-by: Eric Anholt --- glamor/glamor_render.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index 7829977..63b

Re: [PATCH 5/9] glamor: Track the next vertex offset as we go for non-AA traps.

Am 2014-03-09 05:07, schrieb Eric Anholt: +vb += i * glamor_priv->vb_stride / 4; This should be "/ sizeof(float)" instead. +vb += 3 * glamor_priv->vb_stride / 4; Here also. ___ xorg-devel@lists.x.org: X.Org development A

Re: little glamor cleanups (and a dix cleanup)

Patches 1-5 are: Reviewed-by: Markus Wick Am 2014-03-06 18:00, schrieb Eric Anholt: Here are some trivial patches from the glamor-server branch for review. I'm planning to send out the VBO changes next, which get us closer to making glamor not actually suck for performance. These are o

Re: [PATCH 4/6] dix: Remove incorrect comment about privates.

Am 2014-03-06 18:00, schrieb Eric Anholt: PRIVATE_ALL was apparently dropped before There wasn't any PRIVATE_ALL key neither in xserver nor in glamor. I guess it's just a wrong reference to privates.h, so it's the same as the enum DevPrivateKey itself. _

Re: [PATCH 3/6] glamor: Add a note about the state of GL_ARB_map_buffer_range.

Am 2014-03-06 18:00, schrieb Eric Anholt: +/* We'd like to require GL_ARB_map_buffer_range or OpenGL ES 3 or + * GL_OES_map_buffer_range, since it offers more information to + * the driver than plain old glMapBuffer() or glBufferSubData(). + * It's been supported on Mesa on the