| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the generated shader for _TexEnvProgram is empty, force the use of
the fixed-function code. Otherwise, go ahead and use the shader.
This works around a mysterious issue on i915 where fixed-function
software fallbacks are not working correctly.
This isn't really the fix we want, but it works around the issue.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45872
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes a regression from commit 660ed923ded3552e023ef8c3dd9f92e6792f1bd2.
The basic idea is to look at the format of the dest renderbuffer and
choose either GLubyte or GLfloat for colors. The previous code used
_mesa_format_to_type_and_comps() which could return a bunch types other
than ubyte/float.
Determine the datatype at renderbuffer mapping time to avoid frequent
calls to the format query functions.
NOTE: This is a candidate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45577
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial revert of f9874fe. It turns out that the types
don't always match. Specifically, this can happen when doing
glCopyPixels from a float FBO to a RGBA8 FBO.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Not actually used yet though.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a recent commit,
commit 1c0f1dd42a50464eeb81de4aad8eecf24b3d6c89
Author: Chad Versace <[email protected]>
swrast: Fix fixed-function fragment processing
I defined a new function,_swrast_fragment_program, but neglected
to #include s_fragprog.h for clients of that function.
Note: This is a candidate for the 8.0 branch.
Reported-by: Brian Paul <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On i965, _mesa_ir_link_shader is never called. As a consequence, the
current fragment program (ctx->FragmentProgram->_Current) exists but is
invalid because it has no instructions. Yet swrast continued to attempt to
use the empty program.
To avoid using the empty program, this patch 1) defines a new function,
_swrast_use_fragment_program, which checks if the current fragment program
exists and differs from the fixed function fragment program, and, when
appropriate, 2) replaces checks of the form
if (ctx->FragmentProgram->_Current == NULL)
with
if (_swrast_use_fragment_program(ctx))
Fixes the following oglconform regressions on i965/gen6:
api-fogcoord(basic.allCases.log)
api-mtexcoord(basic.allCases.log)
api-seccolor(basic.allCases.log)
api-texcoord(basic.allCases.log)
blend-separate(basic.allCases)
colorsum(basic.allCases.log)
The tests were ran with the GLXFBConfig:
visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat
----------------------------------------------------------------------------
0x021 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
(Note: I originally believed that the hunk in
_swrast_update_fragment_program was unnecessary. But it is required to fix
blend-separate.)
Note: This is a candidate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327
Reveiwed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
| |
|
| |
|
|
|
|
| |
As with commit aed5c8299fe47b8e1728f8140d069bc89d3fa947
|
|
|
|
|
| |
No longer needed since we do all rendering to texture with the buffer
mapping and pixel packing functions.
|
|
|
|
|
|
|
| |
When we're actually rendering into a texture, map the texture image
instead of the corresponding renderbuffer. Before, we just copied
a pointer from the texture image to the renderbuffer. This change
will make the code usable by hardware drivers.
|
|
|
|
| |
No longer used anywhere.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This will let us move the swrast-specific fields out of gl_renderbuffer.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
To better indicate that this pointer to the malloc'd memory.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Instead of using the obsolete gl_renderbuffer::Data field.
Color buffer are still accessed through GetRow/PutRow().
|
| |
|
| |
|
| |
|
|
|
|
| |
To indicate that it points to mapped texture memory.
|
|
|
|
| |
The field will be going away so update this code.
|
|
|
|
| |
This field will go away, so remove some uses of it.
|
|
|
|
| |
They were only called from in s_span.c
|
|
|
|
| |
It was always GL_FLOAT.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
| |
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
v2: remove #ifdef _WIN32, __IBMC__, __IBMCPP_ tests inside ffs()
implementation. The #else clause was recursive.
Reviewed-by: Kenneth Graunke <[email protected]>
Tested-by: Alexander von Gluck <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
We were comparing 32-bit Z buffer values against 16-bit fragment values.
Need to do scaling like for the 24-bit case.
Triangle Z testing was OK since it didn't hit this code path.
|
|
|
|
| |
This is a bitfield of FRAG_BIT_x values so it should be 64-bits now.
|
| |
|
|
|
|
|
|
| |
The code is no longer used.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
These functions updated the gl_renderbuffer::_DepthBuffer and
_StencilBuffer fields. But those fields are no longer used.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes on i965:
ARB_depth_buffer_float/fbo-depthstencil-GL_DEPTH32F_STENCIL8-blit
ARB_depth_buffer_float/fbo-stencil-GL_DEPTH32F_STENCIL8-blit
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
I'm so surprised that gcc didn't catch this that I feel like I must be
misreading. srcMap is what we initialize (along with dstMap) from
this map value right after this check.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|