summaryrefslogtreecommitdiff
path: root/glamor
AgeCommit message (Collapse)AuthorFilesLines
2014-10-26glamor: Free converted bits in _glamor_upload_bits_to_pixmap_texture fast pathKeith Packard1-37/+36
When uploading bits to a texture which need reformatting to match a supported GL format, a temporary buffer is allocated to hold the reformatted bits. This gets freed in the general path, but is not freed in the fast path because that includes an early return before the call to free. This patch removes the early return and places the general case under an 'else' block, so that both paths reach the call to free. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2014-10-26glamor: Don't free memory we are going to use.Andreas Hartmetz1-1/+1
glamor_color_convert_to_bits() returns its second argument on success, NULL on error, and need_free_bits already makes sure that "bits" aliasing converted_bits is freed in the success case. Looks like the memory leak that was supposed to be fixed in 6e50bfa706cd3ab884c933bf1f17c221a6208aa4 only occurred in the error case. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-10-09mi: Drop plane argument from miHandleExposuresAdam Jackson1-2/+1
This existed to be passed to the bs recovery routine; since we back all planes, we don't care. Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Adam Jackson <ajax@redhat.com>
2014-09-29glamor: Use GL_STREAM_READ also for read/write access to a PBOMichel Dänzer1-4/+1
Otherwise the CPU may end up reading from non-cacheable memory, which is very slow. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84178 Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Markus Wick <markus@selfnet.de> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-09-29glamor: Fix leak of converted_bits in _glamor_upload_bits_to_pixmap_textureMichel Dänzer1-0/+1
==9530== 808,575,600 bytes in 5,904 blocks are definitely lost in loss record 4,602 of 4,602 ==9530== at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==9530== by 0xAD29C98: _glamor_upload_bits_to_pixmap_texture (glamor_pixmap.c:771) ==9530== by 0xAD2AE95: glamor_upload_sub_pixmap_to_texture (glamor_pixmap.c:1031) ==9530== by 0xAD2BD55: glamor_upload_pixmap_to_texture (glamor_pixmap.c:1057) ==9530== by 0xAD1C2E6: glamor_composite_choose_shader (glamor_render.c:1025) ==9530== by 0xAD1C629: glamor_composite_with_shader (glamor_render.c:1174) ==9530== by 0xAD1DA77: glamor_composite_clipped_region (glamor_render.c:1542) ==9530== by 0xAD1E849: _glamor_composite (glamor_render.c:1689) ==9530== by 0xAD1ED90: glamor_composite (glamor_render.c:1758) ==9530== by 0x519FD6: damageComposite (damage.c:502) ==9530== by 0xAD27AA3: glamor_trapezoids (glamor_trapezoid.c:147) ==9530== by 0xAD27B51: glamor_trapezoids (glamor_trapezoid.c:101) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84176 Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-09-18glamor: Remove shader-based trapezoid implementation. Fixes Bug 76213.Keith Packard3-1684/+36
I can't find any performance benefit to using the GL path and the code renders this trapezoid incorrectly: top: FIXED 29.50 bottom: FIXED 30.00 left top: POINT 0.00, 29.50 left bottom: POINT 0.00, 30.50 right top: POINT -127.50, 29.50 right bottom: POINT 52.50, 30.00 This should render a solid line from 0,30 to 52,30 but draws nothing. The code also uses an area computation for trapezoid coverage which does not conform to the Render specification which requires a specific point sampling technique. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-09-18glamor: Check large pixmap users in glamor_largepixmap.cKeith Packard1-2/+0
This enables the assertion that all users of the large pixmap member are restricted to pixmaps which are actually large. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-09-18glamor: Handle compositing from large to small pixmapsKeith Packard1-4/+13
glamor_composite_largepixmap_region is given the job of dealing with compositing between a mixture of large and small pixmaps. However, it was assuming that the destination pixmap was large and fetching members of the large structure even for small pixmaps. This manifested with assertion failures when compositing from a large pixmap to a small pixmap. Fixed by using the pixmap size for the destination block size for small pixmaps. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-09-18glamor: Don't abuse large_pixmap members for regular pixmapsKeith Packard1-16/+21
glamor_compute_clipped_regions_ext wants to treat small and large pixmaps uniformly and did that by writing into the large pixmap union member in small pixmaps to construct something that looks like a one texture large pixmap. Instead of doing that, simply allocate the necessary elements locally on the stack and use them from there. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-09-18glamor: Add macro __glamor_large in glamor_largepixmap.cKeith Packard1-13/+21
For now, this simply fetches the large member of the pixmap private. It will be changed to assert that the pixmap is large once bugs related to that have been fixed. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-09-18glamor: Change SET_PIXMAP_FBO_CURRENT from macro to static inlineKeith Packard3-14/+15
This is the last function-like macro in glamor_priv.h; change to static inline like all of the other functions there. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-09-11glamor: Make glyph mask cache per-screenMichel Dänzer2-36/+37
It references a pixmap, which is a per-screen resource. Fixes broken text rendering in xfwm4-tweak-settings in Zaphod mode. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-09-11glamor: Track glyph caching information per screenMichel Dänzer1-10/+13
This is necessary because the glyph caches are per screen. Fixes broken menu text in gnome-terminal in Zaphod mode. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-09-11glamor: Move 'glyph caches realized' check to glamor_realize_glyph_cachesMichel Dänzer2-10/+7
And rename the boolean to reflect what it's about. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-09-11glamor: Call glamor_glyphs_init from glamor_create_screen_resourcesMichel Dänzer1-1/+5
The comment above glamor_glyphs_init was already saying so. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-08-17glamor: Don't call glamor_copy_fbo_cpu() for GLAMOR_DRM_ONLY pixmapsMichel Dänzer1-0/+1
It results in a crash. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-08-17glamor: Free Xv put image data immediately after useKeith Packard1-3/+10
The Xv StopVideo callback is not invoked on textured video ports, so the temporary pixmaps allocated for the video planes are never freed. Freeing the storage immediately after use is a simple solution to this problem which doesn't appear to have any visible performance impact. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-08-12glamor: Don't try to set up core fonts textures when we won't use them.Eric Anholt1-0/+7
This happens to avoid GL errors on hardware without EXT_texture_integer (which implies < GLSL 130, and thus glamor_text.c programs not compiling anyway). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-08-12glamor: Add glamor_copy_fbo_cpu() for CopyArea to non-GPU destinationMichel Dänzer1-0/+54
This provides a speedup e.g. when the destination is an SHM pixmap. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76285 Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-07-30Fix files including xorg-server.h by mistakeKeith Packard3-3/+0
A few files in the server are including xorg-server.h, which is only for use by Xorg server drivers. This fixes those errors and then adds a check to make sure it doesn't happen again. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-07-28glamor: Eliminate diagonal tearing in xvKeith Packard1-5/+8
This uses a single large triangle and a scissor to draw the video instead of two triangles. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2014-07-19glamor: sync_fence_set_triggered should use glFlush, not glFinishKeith Packard1-1/+1
I intended to use glFlush all along, but somehow managed to type glFinish instead. glFlush is sufficient (for a single-queue GPU) to ensure serialization between queued rendering in the X server and future rendering from the client. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2014-07-18glamor: Add support for SHM sync fencesKeith Packard4-0/+135
This hooks up SHM sync fences to complete the requirements for DRI3 running on Glamor. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-07-17Merge remote-tracking branch 'origin/master' into glamor-nextEric Anholt7-11/+19
I've done this merge manually to resolve the minor conflict in glamor.c. Signed-off-by: Eric Anholt <eric@anholt.net>
2014-07-17glamor: Drop the "are we doing a series of blits or draws" logic.Eric Anholt5-23/+0
It's unused since keithp's copy acceleration code completely replaced glamor_copyarea.c and removed the blit path. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Remove a dead prototype.Eric Anholt1-6/+0
The corresponding code was deleted in 2ff41008494e6c5909c058f1f80b4f66617dada1 (2012) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Drop dead glamor_restore_pixmap_to_texture().Eric Anholt2-17/+0
Unused since the glamor_prepare.c replacement of glamor_finish_access(). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Drop dead glamor_download_pixmap_to_cpu()Eric Anholt2-329/+0
Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Drop dead get/pub sub pixmap functions.Eric Anholt2-134/+0
These were replaced by the new glamor_prepare.c code. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Remove always-true yInverted flag.Eric Anholt9-254/+103
All users of glamor had the same value set, and it complicated things for no reason. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Drop constant arguments to glamor_solid().Eric Anholt4-11/+6
After keithp's change to drop the old glamor_fill() code, nothing ever changed these values. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Drop unnecessary glTexParameteri() in upload of texture data.Eric Anholt1-3/+0
We're not drawing, and we're not initially setting up the texture for later drawing. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Use MIN/MAX macros to clean up glamor_transfer.cEric Anholt1-35/+10
Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Drop unnecessary glTexParameteri() in SetSpans().Eric Anholt1-3/+0
If this path needed the filters set, so would all the other glDrawArrays() callers. But they don't. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-07-17glamor: Fix temp picture coordinates in glamor_composite_clipped_regionKeith Packard1-8/+8
To understand this patch, let's start at the protocol interface where the relationship between the coordinate spaces is documented: static Bool _glamor_composite(CARD8 op, PicturePtr source, PicturePtr mask, PicturePtr dest, INT16 x_source, INT16 y_source, INT16 x_mask, INT16 y_mask, INT16 x_dest, INT16 y_dest, CARD16 width, CARD16 height, Bool fallback) The coordinates are passed to this function directly off the wire and are all relative to their respective drawables. For Windows, this means that they are relative to the upper left corner of the window, in whatever pixmap that window is getting drawn to. _glamor_composite calls miComputeCompositeRegion to construct a clipped region to actually render to. In reality, miComputeCompositeRegion clips only to the destination these days; source clip region based clipping would have to respect the transform, which isn't really possible. The returned region is relative to the screen in which dest lives; offset by dest->drawable.x and dest->drawable.y. What is important to realize here is that, because of clipping, the composite region may not have the same position within the destination drawable as x_dest, y_dest. The protocol coordinates now exist solely to 'pin' the three objects together. extents->x1,y1 Screen origin of clipped operation width,height Extents of the clipped operation x_dest,y_dest Unclipped destination-relative operation coordinate x_source,y_source Unclipped source-relative operation coordinate x_mask,y_mask Unclipped mask-relative operation coordinate One thing we want to know is what the offset is from the original operation origin to the clipped origin Destination drawable relative coordinates of the clipped operation: x_dest_clipped = extents->x1 - dest->drawable.x y_dest_clipped = extents->y1 - dest->drawable.y Offset from the original operation origin: x_off_clipped = x_dest_clipped - x_dest y_off_clipped = y_dest_clipped - y_dest Source drawable relative coordinates of the clipped operation: x_source_clipped = x_source + x_off_clipped; y_source_clipped = y_source + y_off_clipped; Mask drawable relative coordinates of the clipped operation: x_mask_clipped = x_source + x_off_clipped; y_mask_clipped = y_source + y_off_clipped; This is where the original code fails -- it doesn't subtract the destination drawable location when computing the distance that the operation has been moved by clipping. Here's what it does when constructing a temporary source picture: temp_src = glamor_convert_gradient_picture(screen, source, extent->x1 + x_source - x_dest, extent->y1 + y_source - y_dest, width, height); ... x_temp_src = -extent->x1 + x_dest; y_temp_src = -extent->y1 + y_dest; glamor_convert_gradient_picture needs source drawable relative coordinates, but that is not what it's getting; it's getting screen-relative coordinates for the destination, adjusted by the distance between the provided source and destination operation coordinates. We want x_source_clipped and y_source_clipped: x_source_clipped = x_source + x_off_clipped = x_source + x_dest_clipped - x_dest = x_source + extents->x1 - dest->drawable.x - x_dest x_temp_src/y_temp_src are supposed to be the coordinates of the original operation translated to the temporary picture: x_temp_src = x_source - x_source_clipped; y_temp_src = y_source - y_source_clipped; Note that x_source_clipped/y_source_clipped will never be less than x_source/y_source because all we're doing is clipping. This means that x_temp_src/y_temp_src will always be non-positive; the original source coordinate can never be strictly *inside* the temporary image or we could have made the temporary image smaller. x_temp_src = x_source - x_source_clipped = x_source - (x_source + x_off_clipped) = -x_off_clipped = x_dest - x_dest_clipped = x_dest - (extents->x1 - dest->drawable.x) Again, this is off by the destination origin within the screen coordinate space. The code should look like: temp_src = glamor_convert_gradient_picture(screen, source, extent->x1 + x_source - x_dest - dest->pDrawable->x, extent->y1 + y_source - y_dest - dest->pDrawable->y, width, height); x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x; y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y; Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Markus Wick <markus@selfnet.de>
2014-07-03glamor: Fix stack corruption in glamor_initTomasz Borowik1-3/+4
glGet on GL_MAX_VIEWPORT_DIMS returns two values Reviewed-by: Markus Wick <markus@selfnet.de> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-06-24Revert "glamor: Fix coordinates handling for composite source/mask pictures"Michel Dänzer1-8/+8
This reverts commit 4e9aabb6fc15d8052934f20c6a07801c197ec36a. It broke kwin decorations with XRender compositing. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-06-23glamor: Fix GLES2 non-VBO temporary memory allocation.Eric Anholt1-1/+1
We'd get a request for like 16 bytes, claim to have allocated GLAMOR_VBO_SIZE, and then not reallocate when something a request bigger than 16 came along. The intent was to always allocate at least GLAMOR_VBO_SIZE. Fixes segfaults with Xephyr -glamor_gles2 and running gnome-terminal. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
2014-06-15glamor: Share code for put_image handling.Eric Anholt2-0/+116
The difference between the two is that XF86 has the clip helper that lets you upload less data when rendering video that's clipped. I don't think that's really worth the trouble, especially in a world of compositors, so I've dropped it to get to shared code. It turns out the clipping code was broken on xf86-video-intel anyway. To reproduce, run without a compositor, and use another window to clip the top half of your XV output on the glamor XV adaptor: the rendering got confused about which half of the window was being drawn to. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-06-15glamor: Split the XV code into XF86-dependent parts and generic.Eric Anholt3-271/+86
I want to expose this from Xephyr as well, both to be able to test XV changes rapidly, and beause the XV passthrough to the host's overlay really doesn't work out well when we glXSwapBuffers() over the colorkey. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-06-15glamor: Remove stubbed-out glamor_stipple functionKeith Packard2-16/+0
This function isn't used anymore. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Remove 'tiling' shader codeKeith Packard4-308/+0
The core rendering paths all use the glamor_program fill functions now Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Replace glamor_solid_boxes and glamor_solid with GC using codeKeith Packard6-390/+106
This provides glamor_solid_boxes and glamor_solid using regular GC operations instead of calling directly to underlying rendering functions. This will allow the old rendering code to be removed. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Add accelerated stipple supportKeith Packard4-18/+157
This copies the stipple to a 8bpp pixmap and uses that to paint the texture from. v2: Create deep stipple pixmap without GLAMOR_CREATE_FBO_NO_FBO v3: Fix stipple origin sign (matches tiles now). Track changes to original stipple with damage. This isn't required by the X spec, but java appears to depend on it, so we'll just do it. When Glamor switches to 8bpp bitmaps, we'll be able to render directly from them and not need this anymore. v4: Review comments from Eric: * Remove stray whitespace change * Avoid "large" pixmap for stipple by using GLAMOR_CREATE_NO_LARGE * Wrap to 80 columns v5: Don't crash when stipple damage tracker is destroyed The stipple damage tracker is automatically destroyed when the associated stipple pixmap is destroyed. When this happens, just clear the pointer from the GC rather than calling glamor_invalidate_stipple; that function would call DamageUnregister on the now invalid stipple damage pointer and crash. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Add glamor_program based 0-width dashed linesKeith Packard10-20/+496
This makes sure the pixelization for dashed lines matches non-dashed lines, while also speeding them up. v2: Switch to glamor_make_current v3: Create dash pattern pixmap without GLAMOR_CREATE_FBO_NO_FBO v4: Adopt suggestions from Eric's review: - Drops power-of-two alignment of our line vertex data, simplifying the code. - Stops reading from the VBO. While on keithp's and my machines the VBO is mapped cached, on many implementations it will be mapped WC, making those reads extremely expensive. - Style fixes (line wrapping, spaces around operators). v5: Adopt suggestions from Markus' review: - Use max when computing zero-width dashed line length. Don't open code max here. - Embed CoordModePrevious into VBO writing for dashed lines Instead of pre-computing the coord mode previous results, just embed this in the loop which fills the vertex buffer. Saves re-writing the request buffer, and shortens the code a bit v6: Export glamor_destroy_gc for UXA UXA needs to call glamor_destroy_gc from its GCFuncs, so export it. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Use glamor_program and GL_LINES for 0-width linesKeith Packard6-192/+361
GL lines are nearly X compliant; you just need to fill in the last pixel when the client hasn't requested CapNotLast. v2: switch to glamor_make_current v3: use miPolylines instead of custom glamor fallback path. Wrap code to 80 columns. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Use glamor_program for glamor_push_pixelsKeith Packard1-88/+66
This uses the same shaders as glamor_poly_glyph_blt. v2: Wrap some long lines (changes by anholt). Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Add glamor_program based copy accelerationKeith Packard13-789/+763
Paints with textures, using a temporary buffer for overlapping copies Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy plane when both objects are in the GPU. Includes copy_window acceleration too. v2: Use NV_texture_barrier for non-overlapping copies within the same drawable v3: Switch to glamor_make_current v4: Do overlap check on the bounding box of the region rather than on individual boxes v5: Use Eric Anholt's re-written comments which provide a more accurate description of the code v6: Use floating point uniform for copy plane bit multiplier. This avoids an int to float conversion in the copy plane fragment shader. Use round() instead of adding 0.5 in copy plane. round() and +0.5 end up generating equivalent code, and performance measurements confirm that they are the same speed. Round() is a bit clearer though, so we'll use it. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Markus Wick <markus@selfnet.de>
2014-06-15glamor: Directly reference the private key recordsKeith Packard2-15/+14
There's no reason to use a pointer here, it just wastes time. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-06-15glamor: Replace fallback preparation codeKeith Packard9-190/+346
These offer a simpler and more efficient means for temporarily transitioning to CPU-accessible memory for fallback implementations. v2: Do not attempt fallbacks with GLAMOR_DRM_ONLY pixmaps glamor cannot transfer pixels for GLAMOR_DRM_ONLY pixmaps using glReadPixels and glTexSubImage2D, and so there's no way to perform fallback operations with these pixmaps. v3: Clear ->pbo field when deleting the PBO. Otherwise, we'd reuse the old name next time we fall back on the pixmap, which would potentially conflict with some other pixmap that genned a new name, or just do a lazy allocation of the name (compat GL context, like we currently use) or error out (core GL context, like we hope to use some day). Also, style fixes. Changes by anholt, acked by keithp. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 15:17:52 +0000