aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel/intel_fbo.h
Commit message (Collapse)AuthorAgeFilesLines
* i965: Move the remaining intel code to the i965 directory.Eric Anholt2013-06-261-211/+0
| | | | | | | | | Now that i915's forked off, they don't need to live in a shared directory. Acked-by: Kenneth Graunke <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Adam Jackson <[email protected]> (and I hear second hand that idr is OK with it, too)
* intel: Drop little bits of dead code.Eric Anholt2013-06-261-1/+0
| | | | | | I noticed these while building the fork-i915 branch. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Rename intel_renderbuffer_tile_offsets.Eric Anholt2013-05-281-3/+3
| | | | | | | | This makes it more consistent with intel_miptree_get_tile_offsets(). Reviewed-and-tested-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* intel: Reduce intel_renderbuffer_tile_offsets to a thin wrapper.Eric Anholt2013-05-281-2/+7
| | | | | | Reviewed-and-tested-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* mesa: Track the TexImage being rendered to in the gl_renderbuffer.Eric Anholt2013-05-171-3/+0
| | | | | | | | | We keep having to pass the attachments around with our gl_renderbuffers because that's the only way to find what the gl_renderbuffer actually refers to. This is a step toward removing that (though drivers still need the Zoffset as well). Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Use brw_blorp_blit_miptrees() for CopyTexSubImage().Eric Anholt2013-05-061-4/+0
| | | | | | | Now that depth resolves are handled there, we don't need to make the temporary renderbuffer. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add field intel_mipmap_slice::has_hizChad Versace2013-04-101-0/+3
| | | | | | | | | | | | | | | | | On Haswell, HiZ will selectively be enabled on individual miptree slices to workaround a hardware bug. The new field 'has_hiz' indicates if HiZ is enabled for a given slice. Also add two new accessor functions for this field. intel_miptree_slice_has_hiz intel_renderbuffer_has_hiz The new field and accessor functions are not yet used. Also, this patch introduces no behavioral change because, in this patch, intel_miptree_alloc_hiz() sets has_hiz for all slices. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Avoid unnecessary copy when depthstencil workaround invoked by clear.Paul Berry2013-03-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Since apps typically begin rendering with a call to glClear(), it is likely that when brw_workaround_depthstencil_alignment() moves a miplevel to a temporary buffer, it can avoid doing a blit, since the contents of the miplevel are about to be erased. This patch adds the necessary plumbing to determine when brw_workaround_depthstencil_alignment() is being called as a consequence of glClear(), and avoids the unnecessary blit when it is safe to do so. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> v2: Eliminate unnecessary call to _mesa_is_depthstencil_format(). Fix handling of depth buffer in depth/stencil format. v3: Use correct bitfields for clear_mask. Fix handling of depth buffer in depth/stencil format when hardware uses separate stencil. When invalidating, make sure we still reassociate the image to the new miptree. Reviewed-by: Eric Anholt <[email protected]>
* Consolidate some redundant definitions of ARRAY_SIZE() macro.Paul Berry2013-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | Previous to this patch, there were 13 identical definitions of this macro in Mesa source. That's ridiculous. This patch consolidates 6 of them to a single definition in src/mesa/main/macros.h. Unfortunately, I wasn't able to eliminate the remaining definitions, since they occur in places that don't include src/mesa/main/macros.h: - include/pci_ids/pci_id_driver_map.h - src/egl/drivers/dri2/egl_dri2.h - src/egl/main/egldefines.h - src/gbm/main/backend.c - src/gbm/main/gbm.c - src/glx/glxclient.h - src/mapi/mapi/stub.c I'm open to suggestions as to how to deal with the remaining redundancy. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Implement CopyTexSubImage2D via BLORP (and use it by default).Kenneth Graunke2013-02-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BLT engine has many limitations. Currently, it can only blit X-tiled buffers (since we don't have a kernel API to whack the BLT tiling mode register), which means all depth/stencil operations get punted to meta code, which can be very CPU-intensive. Even if we used the BLT engine, it can't blit between buffers with different tiling modes, such as an X-tiled non-MSAA ARGB8888 texture and a Y-tiled CMS ARGB8888 renderbuffer. This is a fundamental limitation, and the only way around that is to use BLORP. Previously, BLORP only handled BlitFramebuffer. This patch adds an additional frontend for doing CopyTexSubImage. It also makes it the default. This is partly to increase testing and avoid hiding bugs, and partly because the BLORP path can already handle more cases. With trivial extensions, it should be able to handle everything the BLT can. This helps PlaneShift massively, which tries to CopyTexSubImage2D between depth buffers whenever a player casts a spell. Since these are Y-tiled, we hit meta and software ReadPixels paths, eating 99% CPU while delivering ~1 FPS. This is particularly bad in an MMO setting because people cast spells all the time. It also helps Xonotic in 4X MSAA mode. At default power management settings, I measured a 6.35138% +/- 0.672548% performance boost (n=5). (This data is from v1 of the patch.) No Piglit regressions on Ivybridge (v3) or Sandybridge (v2). v2: Create a fake intel_renderbuffer to wrap the destination texture image and then reuse do_blorp_blit rather than reimplementing most of it. Remove unnecessary clipping code and conditional rendering check. v3: Reuse formats_match() to centralize checks; delete temporary renderbuffers. Reorganize the code. v4: Actually copy stencil when dealing with separate stencil buffers but packed depth/stencil formats. Tested by a new Piglit test. NOTE: This is a candidate for the 9.1 branch. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]> [v4] Reviewed-by: Ian Romanick <[email protected]> [v3] Reviewed-and-tested-by: Carl Worth <[email protected]> [v2] Tested-by: Martin Steigerwald <[email protected]> [v3]
* intel: Remove dead function prototype.Eric Anholt2012-11-191-5/+0
| | | | Reviewed-by: Chad Versace <[email protected]>
* i965: Make a helper function for the renderbuffer temporary mt workaround.Eric Anholt2012-10-161-0/+3
| | | | | | | We now have a case of wanting to do that on gen6+ as well, so make this logic usable elsewhere. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Mark some file-local code as static.Eric Anholt2012-09-271-6/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Mark needed downsamples for msaa winsys buffersChad Versace2012-08-071-0/+3
| | | | | | | | | | | | | Add function intel_renderbuffer_set_needs_downsample. It is a no-op except on multisample winsys buffers shared with DRI2. Mark the needed downsamples with the new function at two locations: - Immediately after drawing is complete. - After blitting. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Set num samples for winsys renderbuffersChad Versace2012-08-071-2/+2
| | | | | | | | | | | | | | Add a new param, num_samples, to intel_create_renderbuffer and intel_create_private_renderbuffer. No multisample GL config is yet advertised, so the value of num_samples is currently 0. For server-owned winsys buffers, gl_renderbuffer::NumSamples is not yet used. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]> (v1) Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor quantize_num_samplesChad Versace2012-08-071-0/+3
| | | | | | | | | | | Rename quantize_num_samples to intel_quantize_num_samples and change the first param from struct intel_context* to struct intel_screen*. The function will later be used by intelCreateBuffer, which is not bound to any context but is bound to a screen. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> (v1) Signed-off-by: Chad Versace <[email protected]>
* intel: Remove dead intel_framebuffer_has_hiz().Eric Anholt2012-07-171-4/+0
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add a function for creating a private window system buffer.Eric Anholt2012-07-171-0/+3
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add extern "C" declarations to headersPaul Berry2012-05-101-0/+8
| | | | | | | | These declarations are necessary to allow C++ code to call C code without causing unresolved symbols (which would make the driver fail to load). Reviewed-by: Chad Versace <[email protected]>
* i965: Fix mipmap offsets for HiZ and separate stencil buffers.Paul Berry2012-05-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rendering to a miplevel other than 0 within a color, depth, stencil, or HiZ buffer, we need to tell the GPU to render to an offset within the buffer, so that the data is written into the correct miplevel. We do this using a coarse offset (in pages), and a fine adjustment (the so-called "tile_x" and "tile_y" values, which are measured in pixels). We have always computed the coarse offset and fine adjustment using intel_renderbuffer_tile_offsets() function. This worked fine for color and combined depth/stencil buffers, but failed to work properly when HiZ and separate stencil were in use. It failed to work because there is only one set of fine adjustment controls shared by the HiZ, depth, and stencil buffers, so we need to choose tile_x and tile_y values that are compatible with the tiling of all three buffers, and then compute separate coarse offsets for each buffer. This patch fixes the HiZ and separate stencil case by replacing the call to intel_renderbuffer_tile_offsets() with calls to two functions: intel_region_get_tile_masks(), which determines how much of the adjustment can be performed using offsets and how much can be performed using tile_x and tile_y, and intel_region_get_aligned_offset(), which computes the coarse offset. intel_region_get_tile_offsets() is still used for color renderbuffers, so to avoid code duplication, I've re-worked it to use intel_region_get_tile_masks() and intel_region_get_aligned_offset(). On i965 Gen6, fixes piglit tests "texturing/depthstencil-render-miplevels 1024 X" where X is one of (depth, depth_and_stencil, depth_stencil_single_binding, depth_x, depth_x_and_stencil, stencil, stencil_and_depth, stencil_and_depth_x). On i965 Gen7, the variants of "texturing/depthstencil-render-miplevels" that contain a stencil buffer still fail, due to another problem: Gen7 seems to ignore the 3 LSB's of the tile_y adjustment (and possibly also tile_x). v2: Removed spurious comments. Added assertions to check preconditions of intel_region_get_aligned_offset(). Reviewed-by: Chad Versace <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* intel: Fix rendering from textures after RenderTexture().Eric Anholt2012-02-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a serious trap for drivers: RenderTexture() does not indicate that the texture is currently bound to the draw buffer, despite FinishRenderTexture() signaling that the texture is just now being unbound from the draw buffer. We were acting as if RenderTexture() *was* the start of rendering and that we could make texturing incoherent with the current contents of the renderbuffer. This caused intel oglconform sRGB Mipmap.1D_textures to fail, because we got a call to TexImage() and thus RenderTexture() on a texture bound to a framebuffer that wasn't the draw buffer, so we skipped validating the new image into the texture object used for rendering. We can't (easily) make RenderTexture() indicate the start of drawing, because both our driver and gallium are using it as the moment to set up the renderbuffer wrapper used for things like MapRenderbuffer(). Instead, postpone the setup of the workaround render target miptree until update_renderbuffer time, so that we no longer need to skip validation of miptrees used as render targets. As a bonus, this should make GL_NV_texture_barrier possible. (This also fixes a regression in the gen4 small-mipmap rendering since 3b38b33c1648b07e75dc4d8340758171e109c598, which switched set_draw_offset from image->mt to irb->mt but didn't move the irb->mt replacement up before set_draw_offset). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961 NOTE: This is a candidate for the 8.0 branch.
* intel: derive intel_renderbuffer from swrast_renderbufferBrian Paul2012-01-241-3/+3
| | | | Drivers that rely on swrast need to do this, as with swrast_texture_image.
* intel: use intel_rb_format() to get renderbuffer formatBrian Paul2012-01-241-0/+8
| | | | This will make future changes cleaner and less invasive.
* intel: Stop creating the wrapped depth irb.Eric Anholt2011-12-191-26/+1
| | | | | | | All the operations were just trying to get at irb->wrapped_depth->mt, which is the same as irb->mt now. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Stop creating the wrapped stencil irb.Eric Anholt2011-12-191-6/+0
| | | | | | | | | | | There were only two places it was really used at this point, which was in the batchbuffer emit of the separate stencil packets for gen6/7. Just write in the ->stencil_mt reference in those two places and ditch all this flailing around with allocation and refcounts. v2: Fix separate stencil on gen7. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Rely on miptree mapping for all renderbuffer maps.Eric Anholt2011-12-071-4/+0
| | | | | | | Now that all RBs have miptrees, and miptree mapping covered these last two code paths, consistently use them. Reviewed-by: Chad Versace <[email protected]>
* intel: Add resolve functions for renderbuffersChad Versace2011-11-221-0/+31
| | | | | | | | | Add the following functions: intel_renderbuffer_resolve_hiz intel_renderbuffer_resolve_depth Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Remove unneeded params from intel_renderbuffer_set_draw_offset()Chad Versace2011-11-221-3/+1
| | | | | | | | | | | | | | Since the renderbuffer tracks the miptree level and layer that it wraps, the 'tex_image' and 'zoffset' params are no longer needed to calculate the draw offsets. Not only are they no longer needed, but their presence would prevent calculating the renderbuffer draw offsets in situations where there were no texture image. Such situations will occur during the HiZ meta-op and during scatter/gather of separate stencil textures. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Track the miptree layer wrapped by a renderbuffer [v2]Chad Versace2011-11-221-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | TODO: Make v2 for kwg. Add two fields to intel_renderbuffer: mt_level mt_layer Multiple renderbuffers may simultaneously wrap a single texture and each provide a different view into that texture. [Consider glFramebufferTextureLayer()]. The new fields indicate which slice of the miptree is wrapped by the renderbuffer. The buffer resolve operations, to be introduced in the future, require these fields in order to resolve the correct slice in the miptree. To add the fields, it was necessary to replace the type of some function parameters from gl_texture_image to gl_renderbuffer_attachment. v2: [kwg] Replace confusing condition `CubeMapFace > 0` with the more sensible `Target == GL_TEXTURE_CUBE_MAP`. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Replace intel_renderbuffer::region with a miptree [v3]Chad Versace2011-11-211-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Essentially, this patch just globally substitutes `irb->region` with `irb->mt->region` and then does some minor cleanups to avoid segfaults and other problems. This is in preparation for 1. Fixing scatter/gather for mipmapped separate stencil textures. 2. Supporting HiZ for mipmapped depth textures. As a nice benefit, this lays down some preliminary groundwork for easily texturing from any renderbuffer, even those of the window system. A future commit will replace intel_mipmap_tree::hiz_region with a miptree. v2: - Return early in intel_process_dri2_buffer_*() if region allocation fails. - Fix double semicolon. - Fix miptree reference leaks in the following functions: intel_process_dri2_buffer_with_separate_stencil() intel_image_target_renderbuffer_storage() v3: - [anholt] Fix check for hiz allocation failure. Replace ``if (!irb->mt)` with ``if(!irb->mt->hiz_region)``. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Move inline functions from intel_fbo.h to .cChad Versace2011-11-211-17/+4
| | | | | | | | | | | | | | | Move the following inline functions: intel_get_rb_region intel_framebuffer_has_hiz A future commit will replace the renderbuffer's region with a miptree. This small refactor will eliminate the need for intel_fbo.h to include intel_mipmap_tree.h on that commit. I'd like to avoid the situation where each header transitively includes every other header. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Kill intel_framebuffer_get_hiz_region()Chad Versace2011-11-211-17/+3
| | | | | | | | | | The only user of intel_framebuffer_get_hiz_region() was intel_framebuffer_has_hiz(). So I folded the body of the former into the latter. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: fix comment typo in intel_renderbufferBrian Paul2011-11-071-1/+1
|
* i965/gen6: Improve glReadPixels() performance by blitting to a linear temp.Eric Anholt2011-11-031-1/+1
| | | | | | | The readpixels microbenchmark in mesa-demos goes from 47Mpix/sec at 1000x1000 to 450Mpix/sec. The 10x10 sizes stay about the same. Reviewed-by: Brian Paul <[email protected]>
* intel: Add an implementation of MapRenderbuffer.Eric Anholt2011-11-011-0/+3
| | | | | | | | | v2: Add separate stencil S8 W-tile swizzling/deswizzling. Tested for the swizzling case with env INTEL_SEPARATE_STENCIL=1 INTEL_HIZ=1 ./bin/hiz-depth-stencil-test-fbo-d24-s8 v3: Apply Chad's fix for S8 window system buffers. Reviewed-by: Chad Versace <[email protected]>
* intel: Silence "intel/intel_fbo.h:105:4: warning: comparison of unsigned ↵Ian Romanick2011-09-091-3/+3
| | | | | | | | | | | expression < 0 is always false" The test was of an enum, attIndex, which should be unsigned. The explicit check for < 0 was replaced with a cast to unsigned in an assertion that attIndex is less than the size of the array it will be used to index. Reviewed-by: Eric Anholt <[email protected]>
* i965: Remove the now unused intel_renderbuffer::draw_offset field.Kenneth Graunke2011-07-281-1/+0
| | | | | | | The previous commit removed the last use of this field. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* intel: Remove now trivial intel_renderbuffer_set_{hiz_,}region().Eric Anholt2011-07-071-12/+0
| | | | | | | | | As a result of this cleanup, a bug in intel_process_dri2_buffer_no_separate_stencil() became quite apparent. We were associating the NULL pointer after an unreference with the STENCIL attachment -- clarify the logic and attach the right region. Reviewed-by: Chad Versace <[email protected]>
* intel: Declare some functions in intel_fbo.c as non-staticChad Versace2011-06-241-0/+12
| | | | | | | | | | ... because they will be needed by intel_tex_image_s8z24_create_renderbuffers. Redeclared functions are: intel_alloc_renderbuffer_storage intel_renderbuffer_set_draw_offsets Signed-off-by: Chad Versace <[email protected]>
* intel: Change signature of intel_create_wrapped_renderbufferChad Versace2011-06-241-0/+4
| | | | | | | | | | Redeclare as non-static because intel_tex_image_s8z24_create_renderbuffers will use it. Remove the 'wrapper' parameter, because there is no wrapper for intel_texture_image.depth_rb and stencil_rb. Signed-off-by: Chad Versace <[email protected]>
* intel: Add fields to intel_renderbuffer for unwrapping packed depth/stencil ↵Chad Versace2011-06-211-5/+49
| | | | | | | | | | | | | | | | | | | | | | | | | buffers Add the following fields: intel_renderbuffer.wrapped_depth; intel_renderbuffer.wrapped_stencil If the intel_context is using separate stencil and the renderbuffer has a packed depth/stencil format, then wrapped_depth and wrapped_stencil are the real renderbuffers. Alter the following functions to accomodate the wrapped buffers: intel_delete_renderbuffer intel_draw_buffer intel_get_renderbuffer intel_renderbuffer_map intel_renderbuffer_unmap Subsequent commits allocate renderbuffer storage for wrapped_depth and wrapped_stencil. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Move the draw_x/draw_y to the renderbuffer where it belongs.Eric Anholt2011-06-131-1/+7
| | | | | | | | | | | | | | | | It was originally located in the region because the tracking of depth/color buffers was on the regions, and getting back to the irb would have been tricky. Now, we're keying off of the renderbuffer in more places, which means we can move these fields where they belong. This could fix potential rendering failure with a single texture having multiple images attached to different renderbuffers across shareCtx (as far as I can tell, this was the only failure we could cause, since anything else should trigger intel_render_texture in between, for example a BindFramebuffer). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Add function intel_renderbuffer_set_hiz_region()Chad Versace2011-06-081-0/+5
| | | | | | | | | | | It's the analog of intel_renderbuffer_set_region(), but for the hiz region of course. CC: Ian Romanick <[email protected]> CC: Kristian Høgsberg <[email protected]> Acked-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Add hiz_region to intel_renderbufferChad Versace2011-05-251-0/+27
| | | | | | | | | | | | | | | | | | | | | | A hiz surface must be supplied to the hardware when rendering to a depth buffer with hiz. There are three potential places to store that surface: 1. Allocate a larger intel_region for the depthbuffer, and let the region's tail be the hiz surface. 2. Allocate a separate intel_region for hiz, and store it as brw_context state. 3. Allocate a separate intel_region for hiz, and store it in intel_renderbuffer. We choose method 3. Method 1 has not been chosen due to future complications it might cause when requesting a DRI drawable's depth buffer attachment from X. Method 2 has not been chosen because storing the hiz region apart from the depth region makes lazy hiz/depth resolves difficult to implement. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: When an RB gets a new region, clear the old from the state cache.Eric Anholt2010-05-041-1/+2
| | | | | | | | This prevents memory usage explosion in blender due to the state cache hanging on to old fake frontbuffer regions. Sigh at blender still using frontbuffer rendering. Bug #24119.
* intel: Remove non-kernel-exec-fencing support.Eric Anholt2010-03-041-3/+0
| | | | | | | Shaves 60k off the driver from removing the broken spans code. This means we now require 2.6.29, which seems fair given that it's a year old and we've removed support for non-KMS already in the last release of 2D.
* intel: Remove struct intel_framebufferKristian Høgsberg2010-01-041-12/+1
| | | | | | With the vsync fields no longer relevant and by refactoring the code to no longer use color_rb[0-1] we can just use struct gl_framebuffer directly.
* intel: Remove client-side vblank codeKristian Høgsberg2010-01-041-12/+0
|
* intel: Axe intel_renderbuffer::texformatIan Romanick2009-12-101-2/+0
| | | | | Since the texformat branch merge, the value of intel_renderbuffer::texformat is just a copy of gl_renderbuffer::Format.
* intel: update intel_create_renderbuffer(format), add XRGB supportBrian Paul2009-10-291-1/+1
| | | | | | | | Pass a gl_format to intel_create_renderbuffer() instead of GLenum. Add cases for MESA_FORMAT_XRGB8888 textures and renderbuffers. However, we don't yet create any renderbuffers or textures with that format. It seems the default alpha value is zero instead of one. Need to investigate that first.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 10:12:55 +0000