summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* xlib: remove obsolete GetRow/PutRow codeBrian Paul2012-01-241-1594/+3
|
* mesa: remove obsolete PutRow, etc assignmentsBrian Paul2012-01-241-17/+0
|
* swrast: remove Get/PutRow()-related codeBrian Paul2012-01-242-1224/+8
|
* st/mesa: remove gl_renderbuffer::GetPointer stuffBrian Paul2012-01-241-19/+0
|
* swrast: stop using Put/GetRow/Values() in swrast codeBrian Paul2012-01-245-55/+193
| | | | | All color buffer rendering is now done by accessing mapped renderbuffer memory. We're now able to get rid of all the GetRow/PutRow stuff.
* swrast: use gl_renderbuffer::StrideInBytes in depth/stencil codeBrian Paul2012-01-242-6/+6
|
* mesa: use gl_renderbuffer::Map for all depth/stencil accessesBrian Paul2012-01-244-47/+124
| | | | | Instead of using the obsolete gl_renderbuffer::Data field. Color buffer are still accessed through GetRow/PutRow().
* intel: make intel_renderbuffer_map/unmap() staticBrian Paul2012-01-242-6/+3
|
* mesa: add new gl_renderbuffer fieldsBrian Paul2012-01-241-1/+6
| | | | | | | | | These are temporary, actually, but they'll make follow-on work easier to implement in a step-by-step manner. Eventually the Map and RowStrideBytes fields will go into a new swrast_renderbuffer type, but adding that type now would involve touching a _lot_ of code that'll eventually be removed. The fields marked as obsolete will go away completely at some point.
* swrast: flush pending rendering before unmapping buffersBrian Paul2012-01-241-2/+3
|
* swrast: new assertions in _swrast_pixel_address()Brian Paul2012-01-241-0/+8
|
* swrast: use _swrast_pixel_address() in more placesBrian Paul2012-01-242-7/+15
|
* swrast: s/Data/Map/ in swrast_texture_imageBrian Paul2012-01-2415-55/+55
| | | | To indicate that it points to mapped texture memory.
* swrast: remove gl_renderbuffer::DataType check in DrawPixels()Brian Paul2012-01-241-5/+8
| | | | The field will be going away so update this code.
* swrast: remove gl_renderbuffer::DataType assertionsBrian Paul2012-01-243-3/+0
| | | | This field will go away, so remove some uses of it.
* st/mesa: remove gl_renderbuffer:DataType assignmentsBrian Paul2012-01-244-107/+0
| | | | | | | | That field is only used by swrast code so there's no reason to mess with it in the gallium state tracker. This also lets us remove the unused st_format_data() type function and related code.
* swrast: make _swrast_get_values(), _swrast_get_row() staticBrian Paul2012-01-242-23/+12
| | | | They were only called from in s_span.c
* swrast: remove dstType param from _swrast_read_rgba_span()Brian Paul2012-01-243-7/+7
| | | | It was always GL_FLOAT.
* swrast: remove unused _swrast_put_row()Brian Paul2012-01-242-40/+0
|
* mesa: Don't resurrect deleted ARB VAOs in glPopClientAttribIan Romanick2012-01-241-11/+42
| | | | | | | | | | | | | | When ARB VAOs are used, glPopClientAttrib does not resurrect a deleted VAO or VBO. This difference between the two spec is, unfortunately, not very well spelled out in the specs. Fixes oglc vao(advanced.pushPop.deleteVAO) and vao(advanced.pushPop.deleteVBO) tests. NOTE: This is a candidate for release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Rename gl_array_object::VBOonly to ::ARBsemanticsIan Romanick2012-01-244-8/+29
| | | | | | | | | | | | | | There are more differences between Apple and ARB than just requiring that all arrays be stored in VBOs. Additional uses will be added in following commits. Also, set the flag at Bind time instead of Gen time. The ARB_vao spec specifies that behavior. NOTE: This is a candidate for release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* swrast: Use fixed-function processing instead _TexEnvProgram for DrawPixelsIan Romanick2012-01-241-2/+21
| | | | | | | | | | | | | | | | | | | | | | | This is a hack to work around drivers such as i965 that: - Set _MaintainTexEnvProgram to generate GLSL IR for fixed-function fragment processing. - Don't call _mesa_ir_link_shader to generate Mesa IR from the GLSL IR. - May use swrast to handle glDrawPixels. Since _mesa_ir_link_shader is never called, there is no Mesa IR to execute. Instead do regular fixed-function processing. Even on platforms that don't need this, the software fixed-function code is much faster than the software shader code. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44749
* mesa: Make sure _TexEnvProgram points at the current ff fragment programIan Romanick2012-01-241-0/+9
| | | | | | | | | | | | | At least one place, the _mesa_need_secondary_color function in state.h, uses this to make decisions. The next patch in this series will add another dependency. Ideally, this field would go away and be replace by a flag or something. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Don't use newlocale on HaikuAlexander von Gluck2012-01-241-1/+1
| | | | | | NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Brian Paul <[email protected]>
* Revert "Always build shared glapi"Matt Turner2012-01-241-0/+2
| | | | | | | | | | | This reverts commit adefee50d954151f76150af80207081ae3c247d9. Shared glapi was never tested with --enable-xlib-glx and turns out to cause a lot of problems. Conflicts: configure.ac
* swrast: Fix unsigned promotion in pointer arithmeticChad Versace2012-01-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | When rowstride was negatie, unsigned promotion caused a segfault here: 299│ if (rb->Format == MESA_FORMAT_S8) { 300│ const GLuint rowStride = rb->RowStride; 301│ for (i = 0; i < count; i++) { 302│ if (x[i] >= 0 && y[i] >= 0 && x[i] < w && y[i] < h) { 303├> stencil[i] = *(map + y[i] * rowStride + x[i]); 304│ } 305│ } 306│ } Fixes segfault in oglconform separatestencil-neu(NonPolygon.BothFacesBitmapCoreAPI), though test still fails. Note: This is a candidate for the stable branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327 Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* meta: Fallback for glBlitFramebuffer from a multisample surfaceIan Romanick2012-01-231-1/+6
| | | | | | | | NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44818
* i965/vs: Fix bogus assertion in emit_block_move()Paul Berry2012-01-231-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i965 processes assignments of whole structures using vec4_visitor::emit_block_move, a recursive function which visits each element of a structure or array (to arbitrary nesting depth) and copies it from the source to the destination. Then it increments the source and destination register numbers so that further recursive invocations will copy the rest of the structure. In addition, it sets the swizzle field for the source register to an appropriate value of swizzle_for_size(...) for the size of each element being copied, so that later optimization passes won't be fooled into thinking that unused vector elements are live. This all works fine. However, emit_block_move also contains an assertion to verify, before setting the swizzle field for the source register, that the source register doesn't already contain a nontrivial swizzle. The intention is to make sure that the caller of emit_block_move hasn't already done some swizzling of the data before the call, which emit_block_move would then counteract when it overwrites the swizzle field. But the assertion is at the lowest level of nesting of emit_block_move, which means that after the first element is copied, instead of checking the swizzle field set by the caller, it checks the swizzle field used when moving the previous element. That means that if the structure contains elements of different vector sizes (which therefore require different swizzles), the assertion will erroneously fire. This patch moves the assertion from emit_block_move to the calling function, vec4_visitor::visit(ir_assignment *). Since the caller is non-recursive, the assertion will only happen once, and won't be fooled by emit_block_move's modification of the swizzle field. This patch also reverts commit fe006a7 (i965/vs: Fix swizzle related assertion), which attempted to fix the bug by making the assertion more lenient, but only worked properly for structures, arrays, and matrices in which each constituent vector is the same size. This fixes the problem described in comment 9 of https://bugs.freedesktop.org/show_bug.cgi?id=40865. Unfortunately, it doesn't fix the whole bug, since the test in question is also failing due to lack of register spilling support in the VS. Fixes piglit test vs-assign-varied-struct. No piglit regressions on Sandy Bridge. This is a candidate for the 8.0 release branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40865#c9 Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Enable workaround-free math on gen7.Eric Anholt2012-01-231-2/+6
| | | | | | | | | This is similar to a commit that did the same for the FS. Shaves several more instructions off of the VS in Lightsmark, but no statistically significant performance difference (n=5). Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Use the embedded-comparison SEL on gen6+, like the FS does.Eric Anholt2012-01-231-6/+16
| | | | | | | Shaves a few instructions off of the VS in Lightsmark, but no statistically significant performance difference on gen7 (n=5). Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix border color on Sandybridge and Ivybridge.Kenneth Graunke2012-01-231-1/+7
| | | | | | | | | | | | | | | | | | | | While reading through the simulator, I found some interesting code that looks like it checks the sampler default color pointer against the bound set in STATE_BASE_ADDRESS. On failure, it appears to program it to the base address itself. So I decided to try programming a legitimate bound, and lo and behold, border color worked. +92 piglits on Sandybridge. Also fixes Lightsmark on Ivybridge. NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28924 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38868 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Yuanhan Liu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* Fix underlinking in libOSMesa since commit adefee5 "Always build shared glapi"Jon TURNEY2012-01-231-0/+2
| | | | | | | | | | | | Since we now always build shared glapi, this exposes the fact that libOSMesa was underlinked when glapi was built shared. Fix this by doing the same thing as drivers/X11/Makefile already does, ensuring that the library is linked with the shared glapi library. (I'm not clear why we link with both glapi.a and glapi.so, so this may be all wrong) Signed-off-by: Jon TURNEY <[email protected]>
* dri: install dri_interface.hMatt Turner2012-01-221-0/+3
| | | | | | Broken in commit 129213e7. Reported-by Kai Wasserbäch <[email protected]>
* Remove src/mesa/ppcMatt Turner2012-01-217-183/+0
| | | | It didn't actually do anything except modify the GL_RENDERER string.
* Fix mistake in 349845f7bAndrei Slăvoiu2012-01-211-1/+1
|
* automake: src/mesa/drivers/driMatt Turner2012-01-206-165/+35
|
* automake: src/mesa/drivers/dri/swrastMatt Turner2012-01-204-27/+74
|
* automake: src/mesa/drivers/dri/nouveauMatt Turner2012-01-203-22/+67
|
* automake: src/mesa/drivers/dri/r200Matt Turner2012-01-204-58/+100
|
* automake: src/mesa/drivers/dri/radeonMatt Turner2012-01-204-54/+99
|
* automake: src/mesa/drivers/dri/i915Matt Turner2012-01-205-32/+70
|
* Always build shared glapiMatt Turner2012-01-201-2/+0
| | | | | | | | libglapi.so, libGL.so, libGLESv2.so, libGLESv1_CM.so must all come from the same version of Mesa or bad things may happen. Acked-by: Kenneth Graunke <[email protected]> Signed-off-by: Matt Turner <[email protected]>
* intel/gen6: Some framebuffers having separate depthstencil should be unsupportedChad Versace2012-01-201-0/+9
| | | | | | | | | | | | | | | When the framebuffer has separate depth and stencil buffers, and HiZ is not enabled on the depth buffer, mark the framebuffer as unsupported. This happens when trying to create a framebuffer with Z16/S8 because we haven't enabled HiZ on Z16 yet. Fixes gles2conform test stencil8. Note: This is a candiate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44948 Reviewed-and-tested-by: Ian Romanick <[email protected]> Reviewed--by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: Loosen glBlitFramebuffer restrictions on depthstencil buffers (v2)Chad Versace2012-01-201-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This loosens the format validation in glBlitFramebuffer. When blitting depth bits, don't require an exact match between the depth formats; only require that the two formats have the same number of depth bits and the same depth datatype (float vs uint). Ditto for stencil. Between S8_Z24 buffers, the EXT_framebuffer_blit spec allows glBlitFramebuffer to blit the depth and stencil bits separately. So I see no reason to prevent blitting the depth bits between X8_Z24 and S8_Z24 or the stencil bits between S8 and S8_Z24. However, we of course don't want to allow blitting from Z32 to Z32_FLOAT. Fixes Piglit fbo/fbo-blit-d24s8 on Intel drivers with separate stencil enabled. The problem was that, on Intel drivers with separate stencil, the default framebuffer has separate depth and stencil buffers with formats X8_Z24 and S8. The test attempts to blit the depth bits from a S8_Z24 buffer into the default framebuffer. v2: Check that depth datatypes match. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44665 Note: This is a candidate for the 8.0 branch. Reported-by: Xunx Fang <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: allocate transform_feedback_info::Outputs array dynamicallyChristoph Bumiller2012-01-201-15/+17
| | | | | | | | | | | | The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS which made it always assert in the linker when TFB was used since the Outputs array was smaller than that maximum. v2: added assertions NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Paul Berry <[email protected]>
* mesa: include arrayobj.h to silence implicit function declaration warningBrian Paul2012-01-201-0/+1
| | | | Caused by commit 7a1e941ebee43cb97a2c77fd2269999b202308a2.
* mesa: Fix and speedup gl_array_object::_MaxElement computation.Mathias Fröhlich2012-01-202-139/+28
| | | | | | | | | | Use a bitmask approach to compute gl_array_object::_MaxElement. To make this work correctly depending on the shader type actually used, make use of the newly introduced typed bitmask getters. With this change I gain about 5% draw time on some osgviewer examples. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Introduce enabled bitfield helper functions.Mathias Froehlich2012-01-202-0/+41
| | | | | | | | | | Depending on the installed shader type, different arrays are used from gl_array_object. Provide helper functions that compute the bitmask of these arrays that are finally enabled for a given shader type. The will be used in a followup change. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Use BITFIELD64_RANGE for VERT_BIT_*_ALL.Mathias Fröhlich2012-01-201-5/+5
| | | | | Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* st/mesa: copy num_immediates field when copying the immediates arrayBrian Paul2012-01-191-1/+5
| | | | | | | | | | | | | | | Two assignments to num_immediates were missing in get_pixel_transfer_visitor() and get_bitmap_visitor(). The uninitialized value led to valgrind errors and crashes in some cases. Added new assertions to catch future problems in this area. Also changed num_immediates to unsigned to avoid signed/unsigned comparison warnings. NOTE: This is a candidate for the 8.0 branch. Reviewed-by: José Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 13:38:36 +0000