aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel
Commit message (Collapse)AuthorAgeFilesLines
...
* i965: Bump maximum supported ES2 context version to 3.0Chad Versace2013-01-251-1/+1
| | | | | | | | | | Since patch "i965: Validate requested GLES context version in brwCreateContext", we have been able to create ES 3.0 contexts due to the max version check. So...bump the max version. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965/Gen6+: Enable ARB_ES3_compatibility extensionPaul Berry2013-01-251-0/+1
| | | | Reviewed-by: Ian Romanick <[email protected]>
* intel: Fix glCopyTexSubImage on buffers whose width >= 32kbytesPaul Berry2013-01-241-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When possible, glCopyTexSubImage calls are performed using the hardware blitter. However, according to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics Data Size Limitations): The BLT engine is capable of transferring very large quantities of graphics data. Any graphics data read from and written to the destination is permitted to represent a number of pixels that occupies up to 65,536 scan lines and up to 32,768 bytes per scan line at the destination. The maximum number of pixels that may be represented per scan line’s worth of graphics data depends on the color depth. With an RGBA32F color buffer (which has 16 bytes per pixel) this imposes a maximum width of 2048 pixels. Other pixel formats have accordingly larger limits. To make matters worse, if the pitch of the buffer is 32k or greater, intel_copy_texsubimage's call to intelEmitCopyBlit will overflow intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are 16-bit signed integers). We can conveniently avoid both problems by avoiding use of the blitter when the miptree's pitch is >= 32k. Fixes gles3conform "framebuffer_blit_functionality_magnifying_blit" tests when the buffer width is equal to 8192. Note: this is very similar to the recent patch "intel: Fix ReadPixels on buffers whose width >= 32kbytes" except that it applies to glCopyTexSubImage instead of glReadPixels. In a future patch it would be nice to refactor the code so that (a) overflow is avoided, and (b) intelEmitCopyBlit is responsible for checking whether the blitter can handle the width, so that all callers of intelEmitCopyBlit work properly, rather than just these two. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix ReadPixels on buffers whose width >= 32kbytesPaul Berry2013-01-241-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When possible, glReadPixels calls are performed using the hardware blitter. However, according to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics Data Size Limitations): The BLT engine is capable of transferring very large quantities of graphics data. Any graphics data read from and written to the destination is permitted to represent a number of pixels that occupies up to 65,536 scan lines and up to 32,768 bytes per scan line at the destination. The maximum number of pixels that may be represented per scan line’s worth of graphics data depends on the color depth. With an RGBA32F color buffer (which has 16 bytes per pixel) this imposes a maximum width of 2048 pixels. To make matters worse, if the pitch of the buffer is 32k or greater, intel_miptree_map_blit's call to intelEmitCopyBlit will overflow intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are 16-bit signed integers). We can conveniently avoid both problems by avoiding the readpixels blit path when the miptree's pitch is >= 32k. Fixes gles3conform "half_float" tests when the buffer width is greater than 2048. Reviewed-by: Eric Anholt <[email protected]> Tested-by: Ian Romanick <[email protected]>
* intel: callocing a 32 byte temp is silly, so don'tIan Romanick2013-01-241-3/+3
| | | | | | | | | I believe that the size used to vary, so the dynamic allocation is necessary. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: Enable S3TC extensions alwaysIan Romanick2013-01-231-6/+4
| | | | | | | | | | | | | | | | | | | | | Always enable the use of pre-compressed texture data. The ability to perform on-line compression still requires the presence of libtxc_dxtn or an explicit driconf over-ride. Applications that just want to submit precompessed data when an on-line compressor is not available can look for the GL_EXT_texture_compression_dxt1 and GL_ANGLE_texture_compression_dxt[35] extensions. v2: Only enable the extensions that do not require on-line compression by default. The previous statement "This should not impact many (if any) real applications." proved to be false for at least Sauerbraten. This application mostly submits pre-compressed data, but it also can submit uncompressed data that it asks the driver to compress. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]> [v1] Reviewed-by: Kenneth Graunke <[email protected]> [v1] Acked-by: Eric Anholt <[email protected]> [v1] Acked-by: Lee Salzman <[email protected]>
* mesa: Use a single flag for the S3TC extensions that don't require on-line ↵Ian Romanick2013-01-231-1/+0
| | | | | | | | compression Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Lee Salzman <[email protected]>
* i965: Implement the GL_ARB_base_instance extension.Kenneth Graunke2013-01-221-0/+2
| | | | | | | | | | | | | Thanks to Fredrik Höglund, all the hard work was already done. Tested using a modified oglconform (that actually runs these tests on our driver); it looks like there may be some bugs when using client arrays. All applicable non-compatibility tests passed. For now, only enable it in core profiles. Reviewed-by: Eric Anholt <[email protected]> Tested-by: Ian Romanick <[email protected]>
* intel: Don't expose XRGB8888 visuals any moreIan Romanick2013-01-211-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | There really isn't any point. There is no resource savings, and we have to do gymnastics in the driver to make it work. There are also bad interactions with multisampling and OpenGL ES 3.0. In ES3, a multisample-to-singlesample blit must have identical source and destination format. This means a multisample RGBA8 to singlesample RGB8 (window) blit will generate an error. Also in ES3, RGB8 is not a renderable format. This means that the application CANNOT make an RGB8 multisample renderbuffer. As a result, if an application gets an RGB8 window and wants to do multisample FBO rendering, it will probably break. "Fixes" gles3conform framebuffer_blit_functionality_multisampled_to_singlesampled_blit test on RGB8 visuals. v2: Fix 'formats' array size. Suggested by Ken. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Eric Anholt <[email protected]>
* i965: Enable floating-point textures alwaysIan Romanick2013-01-212-20/+5
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Eric Anholt <[email protected]>
* intel: Enable GL_OES_depth_texture_cube_mapIan Romanick2013-01-201-0/+1
| | | | | | | | | | For now I'm just enabling this on the same subset of hardware that has OpenGL 3.0 enabled. This same functionality is part of OpenGL 3.0, and there is no matching desktop extension. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add support for GL_ARB_texture_buffer_object_rgb32.Eric Anholt2013-01-181-0/+1
| | | | | | Tested with piglit ARB_texture_buffer_object/formats. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Make intel_region's pitch be bytes instead of pixels.Eric Anholt2013-01-1812-50/+46
| | | | | | | | | | | | We almost never want a stride in pixels -- if you're doing anything with a stride, you're specifying an offset or incrementing a pointer, and in both cases you had to multiply by cpp to get the bytes value you wanted. But worse, on the way to creating a region from a new tiled BO, we divided by cpp to get pitch in pixels, and for an RGB32 buffer (an upcoming change) the pitch wouldn't divide exactly, and we'd end up with a wrong stride in our region. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Make intel_blit.c take pitches in bytes.Eric Anholt2013-01-188-19/+15
| | | | | | As we gain support for NPOT cpp, a pitch may not divide by cpp cleanly. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Enable GL_ARB_internalformat_queryIan Romanick2013-01-151-0/+1
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* intel: Support blitting to multiple color draw buffersAnuj Phogat2013-01-151-32/+60
| | | | | | | | | | | | | | | This patch enables blitting to multiple color attachments of a framebuffer. It also fixes a case when blitting to a framebuffer with renderbuffer/texture attached to non-zero attachment point i.e. GL_COLOR_ATTACHMENT{1, 2, ...}. Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default. V2: Use intel_copy_texsubimage() for blitting only if all the color attachments can blit using it. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Expose support for DRI_API_GLES3Chad Versace2013-01-151-0/+2
| | | | | | | | | If the hardware/driver combo supports GLES3, then set the GLES3 bit in intel_screen's bitmask of supported DRI API's. Neither the EGL nor GLX layer uses the bit yet. Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Move validation of context version into intelInitContextChad Versace2013-01-153-30/+70
| | | | | | | | | | | | | | | | | | | | | Each driver (i830, i915, i965) used independent but similar code to validate the requested context version. With the rececnt arrival of GLES3, that logic has needed an update. Rather than apply identical updates to each drivers validation code, let's just move the validation into the shared routine intelInitContext. This refactor required some incidental changes to functions i830CreateContext and intelInitContext. For each function, this patch: - Adds context version parameters to the signature. - Adds a DRI_CTX_ERROR out param to the signature. - Sets the DRI_CTX_ERROR at each early return. Tested against gen6 with piglit egl-create-context-verify-gl-flavor. Verified that this patch does not change the set of exposed EGL context flavors. Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Set screen's api mask according to hw capabilities (v3)Chad Versace2013-01-152-11/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, intelInitScreen2 set DRIScreen::api_mask with the hacky heuristic below: if (gen >= 3) api_mask = GL | GLES1 | GLES2; else api_mask = 0; This hack was likely broken on gen2 (i830), but I don't care enough to properly investigate. It appears that every EGLConfig on i830 has EGL_RENDERABLE_TYPE=0, and thus eglCreateContext will never succeed. Anyway, moving on to living drivers... With the arrival of EGL_OPENGL_ES3_BIT_KHR, this heuristic is now insufficient. We must enable the GLES3 bit if and only if the driver is capable of creating a GLES3 context. This requires us to determine the maximum supported context version supported by the hardware/driver for each api *during initialization of intel_screen*. Therefore, this patch adds four new fields to intel_screen which indicate the maximum supported context version for each api: max_gl_core_version max_gl_compat_version max_gl_es1_version max_gl_es2_version The api mask is now correctly set as: api_mask = GL; if (max_gl_es1_version > 0) api_mask |= GLES1; if (max_gl_es2_version > 0) api_mask |= GLES2; Tested against gen6 with piglit egl-create-context-verify-gl-flavor. Verified that this patch does not change the set of exposed EGL context flavors. v2: - Replace the if-tree on gen with a switch, for Ian. - Unconditionally enable the DRI_API_OPENGL bit, for Ian. v3: - Drop max gl version to 1.4 on gen3 if !has_occlusion_query, because occlusion queries entered core in 1.5. For Ian. v4: - Drop ES2 version back to 2.0 due to rebase (Ian). Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <ian.d.romanick.intel.com>
* i965: Move program_id to intel_screen instead of brw_context.Kenneth Graunke2013-01-122-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to bug #54524, I regressed oglconform's multicontext test when I reenabled the fragment shader precompile. However, these test cases only passed by miraculous coincedence. We assign each fragment program a unique ID (brw_fragment_program::id which becomes brw_wm_prog_key::program_string_id) which we obtain by storing a per-context counter. The test case uses GLX context sharing to access the same fragment program from two different contexts. This means that we share a program cache. Before the precompile, if both contexts happened to use the same shaders in the same order, we'd obtain the same program_string_ids (by virtue of doing the same computation twice). However, the more likely scenario is that they completely disagree on program_string_id. This meant that we'd have two completely different fragment shaders in the cache with the same ID, tricking us to think they were the same (aside from NOS), so we'd render using the wrong program. This patch implements a simple fix suggested by Eric: it moves the global counter out of brw_context and into intel_screen, which is shared across all contexts. A mutex protects it from concurrent access. This is also the first direct usage of pthreads in the i965 driver. Fixes 10 subcases of oglconform's multicontext test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54524 Reviewed-by: Eric Anholt <[email protected]>
* i965: Add an INTEL_DEBUG=no16 option.Kenneth Graunke2013-01-122-0/+2
| | | | | | | | | | | Often when debugging, I don't want to see SIMD16 shaders. It makes INTEL_DEBUG=vs/fs output much easier to read, especially when a program dumps many shaders. Plus, I also want to verify that SIMD8 works before even considering SIMD16. v2: Fix the likeliness check (caught by Chris and Eric). Reviewed-by: Eric Anholt <[email protected]>
* driconf: Add a new option: disable_glsl_line_continuationsCarl Worth2013-01-111-1/+2
| | | | | | | | | This is to enable a quirk for Savage2 which includes a shader with a stray '\' at the end of a comment line. Interpreting that backslash as a line continuation will break the compilation of the shader, so we need a way to disable this. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Clean up confusion between logical and physical surface dimensions.Paul Berry2013-01-096-125/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In most cases, the width, height, and depth of the physical surface used by the driver to implement a texture or renderbuffer is equal to the logical width, height, and depth exposed to the client through functions such as glTexImage3D(). However, there are two exceptions: cube maps (which have a physical depth of 6 but a logical depth of 1) and multisampled renderbuffers (which have larger physical dimensions than logical dimensions to allow multiple samples per pixel). Previous to this patch, we accounted for the difference between physical and logical surface dimensions at inconsistent places in the call graph (multisampling was accounted for in intel_miptree_create_for_renderbuffer(), and cubemaps were accounted for in intel_miptree_create_internal()). As a result, it wasn't always clear, when calling a miptree creation function, whether physical or logical dimensions were needed. Also, we weren't consistent about storing logical dimensions in the intel_mipmap_tree structure (we only did so in the intel_miptree_create_for_renderbuffer() code path, and we did not store depth). This patch refactors things so that intel_miptree_create_internal() is responsible for converting logical to physical dimensions and for storing both the physical and logical dimensions in the intel_mipmap_tree structure. As a result, all miptree creation functions interpret their arguments as logical dimensions, and both physical and logical dimensions are always available to functions that work with intel_mipmap_trees. In addition, it renames the fields in intel_mipmap_tree used to store the dimensions, so that it is clear from the name whether physical or logical dimensions are being referred to. This should fix the following bugs: - When creating a separate stencil surface for a depthstencil cubemap, we would erroneously try to convert the depth from 1 to 6 twice, resulting in an assertion failure. - When creating an MCS buffer for compressed multisampling, we used physical dimensions instead of logical dimensions, resulting in wasted memory. In addition, this should considerably simplify the implementation of ARB_texture_multisample, because it moves the code to compute the physical size of multisampled surfaces out of renderbuffer-only code. Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Add a force_y_tiling parameter to intel_miptree_create().Paul Berry2013-01-095-26/+34
| | | | | | | | | | | This allows intel_miptree_alloc_mcs() to force Y tiling for the MCS buffer. Previously we accomplished this by the hack of passing INTEL_MSAA_LAYOUT_CMS as the msaa_layout parameter, but that parameter is going to be going away soon. Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Move compute_msaa_layout earlier in file.Paul Berry2013-01-091-38/+41
| | | | | | | | | | No functional change. This patch moves the compute_msaa_layout() function earlier in intel_mipmap_tree.c so that it can be used by other functions in that file. Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* mesa: Add ALIGN() macro to main/macros.h.Paul Berry2013-01-081-13/+0
| | | | | | | | | Previously this macro existed in 3 separate places, some inside the intel driver and some outside of it. It makes more sense to have it in main/macros.h Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix copy-and-paste bug setting gl_constants::MaxSamplesIan Romanick2013-01-041-1/+1
| | | | | | | | | | gl_constants::MaxSamples is an integer, so setting it to 1.0 is just silly. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix glCompressedTexSubImage2D offsets for ETC textures.Paul Berry2013-01-041-0/+3
| | | | | | | | | | | This patch fixes intel_miptree_unmap_etc() (which decompresses ETC textures to linear) to pay attention to map->x and map->y when writing to the destination image. Previously these values were ignored, causing the xoffset and yoffset parameters passed to glCompressedTexSubImage2D() to be ignored. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Fail to blit rather than assert on invalid pitch requirements.Kenneth Graunke2012-12-291-2/+2
| | | | | | | | | | | | | | | | | | | Dungeon Defenders hits TexImage()'s try_pbo_upload() path where image->Width == 2, which doesn't meet intelEmitCopyBlit's requirement that the pitch needs to be a multiple of 4. Since intelEmitCopyBlit can already fail for a myriad of other reasons, and it's not clear that other callers are immune to this failure mode, simply make it return false rather than assert. Fixes Dungeon Defenders on i965/Ivybridge. Now playable (aside from having to work around the EXT_bindable_uniform issue). NOTE: This is probably a candidate for the 9.0 branch. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: Skip texture validation logic when nothing has changed.Eric Anholt2012-12-285-2/+30
| | | | | | Improves GLBenchmark 2.1 offscreen performance by 3.2% +/- 1.5% (n=52). Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Turn a test in miptree_match_image into an assert.Eric Anholt2012-12-281-2/+5
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Use the parent miptree's format for setting up HiZ miptrees.Eric Anholt2012-12-261-1/+1
| | | | | | | This worked out before because the parent was always 4 bytes so it didn't affect the layout, but now we want to support Z16 too. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Remove a couple of dead function prototypes.Eric Anholt2012-12-221-5/+0
| | | | Reviewed-by: Jordan Justen <[email protected]>
* i965: Assert that relayout laid out something that won't need it again.Eric Anholt2012-12-221-0/+6
| | | | | | | | The ETC1 changes failed at this, so let's make sure it will be caught in testing next time. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Also fix validation of Z32F_S8 textures.Eric Anholt2012-12-221-0/+2
| | | | | | | | | This was caught by the assertion in the next commit. It fixes the remaining piglit depthstencil-render-miplevels cases, probably by avoiding broken stencil copies in the validation path. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix validation of ETC miptrees.Eric Anholt2012-12-221-5/+7
| | | | | | | | | | | When comparing to the teximage's format, we have to look at the format-the-mt-was-created-for not the format-actually-stored-in-the-mt. Improves glbenchmark 2.1 offscreen test performance 159% +/- 17% (n=3). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54582 Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* qi965: Add perf debug for texture relayout.Eric Anholt2012-12-221-0/+5
| | | | | | | | Relayout is expensive, so it's something developers (both us and others) should know about when it happens. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: expose ARB_texture_cube_map_arrayChris Forbes2012-12-141-0/+1
| | | | | | | | | V3: Put enable in an existing block rather than making a new one for no good reason. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: don't advertise ARB_texture_buffer_object in legacy contextsMarek Olšák2012-12-121-4/+1
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: disallow creation of GL 3.1 compatibility contextsMarek Olšák2012-12-121-5/+1
| | | | | | Death to driver-specific hacks! Reviewed-by: Ian Romanick <[email protected]>
* intel: Enable ETC2 support on intel hardwareAnuj Phogat2012-12-072-50/+83
| | | | | | | | | | | | | | | | | | | | This patch enables support for ETC2 compressed textures on all intel hardware. At present, ETC2 texture decoding is not available on intel hardware. So, compressed ETC2 texture data is decoded in software and stored in a suitable uncompressed MESA_FORMAT at the time of glCompressedTexImage2D. Currently, ETC2 formats are only exposed in OpenGL ES 3.0. V2: Use single etc_wraps variable for both etc1 and etc2. V3: Remove redundant code and use just one intel_miptree_map_etc() and intel_miptree_unmap_etc() function. Choose MESA_FORMAT_SIGNED_{R16, GR1616} for ETC2 signed-{r11, rg11} formats Signed-off-by: Anuj Phogat <[email protected]> Tested-by: Matt Turner <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add a debug flag for counting cycles spent in each compiled shader.Eric Anholt2012-12-052-0/+7
| | | | | | | | | | | | | | | | | | | | | | This can be used for two purposes: Using hand-coded shaders to determine per-instruction timings, or figuring out which shader to optimize in a whole application. Note that this doesn't cover the instructions that set up the message to the URB/FB write -- we'd need to convert the MRF usage in these instructions to GRFs so that our offsets/times don't overwrite our shader outputs. Reviewed-by: Kenneth Graunke <[email protected]> (v1) v2: Check the timestamp reset flag in the VS, which is apparently getting set fairly regularly in the range we watch, resulting in negative numbers getting added to our 32-bit counter, and thus large values added to our uint64_t. v3: Rebase on reladdr changes, removing a new safety check that proved impossible to satisfy. Add a comment to the AOP defs from Ken's review, and put them in a slightly more sensible spot. v4: Check timestamp reset in the FS as well.
* intel: Always enable GL_ARB_framebuffer_objectIan Romanick2012-12-031-2/+1
| | | | | | | | | | | | | | | Now that _mesa_BindFramebuffer does the right thing in ES contexts when the gl_extensions::ARB_framebuffer_object bit is set, the Intel driver doesn't need this hack. No piglit or GLES2 conformance regressions observed on IVB, and this patch (and the previous) fix es3conform's framebuffer_srgb_draw and transform_feedback_misc tests. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Allow INTEL_DEBUG=fs as a synonym for INTEL_DEBUG=wm.Kenneth Graunke2012-12-031-0/+1
| | | | | | | | | | | I keep accidentally trying to use it. "fs" is a sensible name for fragment shader debugging, and "wm" is...not. It's also more symmetric with "vs". Leave INTEL_DEBUG=wm because old habits die hard. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glx/dri2: add and use new driver hook flush_with_flagsMarek Olšák2012-12-021-1/+1
|
* mesa: pass context parameter to gl_renderbuffer::Delete()Brian Paul2012-11-301-2/+2
| | | | | | | | | | We sometimes need a rendering context when deleting renderbuffers. Pass it explicitly instead of trying to grab a current context (which might be NULL). The next patch will make use of this. Note: this is a candidate for the stable branches. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: Rename API_OPENGL to API_OPENGL_COMPAT.Paul Berry2012-11-291-1/+1
| | | | | | | | | | This should help avoid confusion now that we're using the gl_api enum to distinguishing between core and compatibility API's. The corresponding enum value for core API's is API_OPENGL_CORE. Acked-by: Eric Anholt <[email protected]> Acked-by: Matt Turner <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Enable ARB_vertex_type_2_10_10_10_rev on Gen4+.Chris Forbes2012-11-261-0/+1
| | | | | | | | v2 (Kayden): Move the enable into an existing intel->gen >= 4 block (as suggested by Ian). Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Use designated initializers for DRI extension structsChad Versace2012-11-191-16/+20
| | | | | | | | | | | | | | | All Intel code is compiled with -std=c99. There is no excuse to not use designated initializers. As a nice benefit, the code is now more friendly to grep. Without designated initializers, psychic prowess is required to find the initialization of DRI extension function pointers with grep. I have observed several people, when they first encounter the DRI code, fail at statically chasing the DRI function pointers due to this problem. Reviewed-by: Matt Turner <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Push face/level -> slice handling to the caller of get_image_offset().Eric Anholt2012-11-198-42/+24
| | | | | | | We were always passing 0 for one of the two fields, and the code just used whichever one wasn't 0. Reviewed-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 09:50:32 +0000