| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Tested-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: Update a comment block about the different treatment of
location=-1 based on feedback from Ken.
Signed-off-by: Ian Romanick <[email protected]>
Tested-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prepend _mesa_uniform_ to the names and rework the calling
convention. The calling convention was changed for a couple reasons.
1. Having a single variable named 'location' have completely different
meanings at different places in the function is confusing. Before
calling split_location_offset the location is the encoded value
returned by glGetUniformLocation. After calling split_location_offset
it's the index of the uniform in the gl_uniform_list::Uniforms array.
2. In a later commit the original value of 'location' is needed after
split_location_offset has been called.
Signed-off-by: Ian Romanick <[email protected]>
Tested-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
| |
Also rename to _mesa_get_uniform.
Signed-off-by: Ian Romanick <[email protected]>
Tested-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
_mesa_GetUniformLocationARB
There are cases where we might want to internally query the location
of a uniform in a shader that failed linking.
Signed-off-by: Ian Romanick <[email protected]>
Tested-by: Tom Stellard <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Tested-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The spec says "Only ClearBufferiv should be used to clear
stencil buffers." and "Only ClearBufferfv should be used to clear
depth buffers." However, on the following page it also says:
"The result of ClearBuffer is undefined if no conversion between
the type of the specified value and the type of the buffer being
cleared is defined (for example, if ClearBufferiv is called for a
fixed- or floating-point buffer, or if ClearBufferfv is called
for a signed or unsigned integer buffer). *This is not an error.*"
Emphasis mine.
Fixes problems with piglit's clearbuffer-invalid-drawbuffer test.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression from the recent glReadPixels changes found
with the piglit hiz tests.
Use either MESA_FORMAT_RGBA8888 or MESA_FORMAT_RGBA8888_REV for color
buffers depending on endian-ness. Before, the gl_renderbuffer::Format
field was MESA_FORMAT_RGBA8888 but the data was really stored as
MESA_FORMAT_RGBA8888_REV when using a little endian machine.
Getting this right matters now that we can access renderbuffer data
without going through the span functions (namely glReadPixels() +
MapRenderbuffer()).
|
|
|
|
|
|
|
|
| |
These vars will just get overwritten when we call _mesa_add_renderbuffer()
anyway. We only need to set the InternalFormat field when we create the
software renderbuffer.
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
| |
Untested, but also unused at this point.
|
|
|
|
|
|
|
|
| |
This fixes the glReadPixels() regression for reading from the front/back
color buffers.
Note, we only allow one mapping of an XImage/Pixmap renderbuffer
at any time. That might need to be revisited in the future.
|
|
|
|
|
|
| |
One of the points of GL_ARB_texture_storage is to make it impossible
to have malformed mipmap stacks. If we know the texture object is
immutable, we can skip a bunch of size checking.
|
|
|
|
|
|
|
| |
Fixes bogus failed assertion when using NV_fragment_program, such
as with demos/fplight.c
Note: This is a candidate for the 7.11 branch.
|
| |
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Commit a73c65c5342bf41fa0dfefe7daa9197ce6a11db4 had a typo which
accidentally enabled the workaround-free Gen7 code on Gen6.
Fixes GPU hangs in anything using pow() or integer division/modulus.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the documentation, Ivybridge's math instruction works in
SIMD16 mode for the fragment shader, and no longer forbids align16 mode
for the vertex shader.
The documentation claims that SIMD16 mode isn't supported for INT DIV,
but empirical evidence shows that it works fine. Presumably the note
is trying to warn us that the variant that returns both quotient and
remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1
would be sechalf(dst), trashing half your results. Since we don't use
that variant, we don't care and can just enable SIMD16 everywhere.
The documentation also still claims that source modifiers and
conditional modifiers aren't supported, but empirical evidence and
study of the simulator both show that they work just fine.
Goodbye workarounds. Math just works now.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
Makes clang happier.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
The code expects the geometry shader to be NULL.
We don't have geometry shaders now, but it's good to be prepared.
v2: check for support in the cso context
|
|
|
|
|
| |
st_translate_program's data was taking 51K off the stack, causing stack
overflow on Windows.
|
|
|
|
| |
To smooth minor diff between dri_util & drisw_util
|
| |
|
| |
|
| |
|
|
|
|
| |
This is to reorder as screen/context/drawable similar to drisw_util
|
| |
|
|
|
|
| |
__driUtilMessage seems to have fallen out of favor and is only used by xmlconfig.c now
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also drop DriverAPI field, this is a static symbol and I don't see why it
should be accessed through __DRIscreenRec
|
|
|
|
| |
I dropped the comments because they don't add much.
|
| |
|
|
|
|
| |
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
This is needed to do proper renderbuffer operation on mipmaps.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
This just uses the base class copies.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
An error with MSVC.
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
Renderbuffer mapping handles flushing the batchbuffer if required, so
all we need to do is make sure any pending rendering has reached the
batchbuffer.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
There doesn't appear to be any particular reason for this -- it's not
like the width is changing between the deref and the use.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
In all of piglit, only two tests hit it (reading to RGBA float, where
GetRow would drop floats into place from R, RG, or RGB). Mostly this
is because _ColorReadClamp has been causing transferOps to always be
set, skipping any fast-paths anyway.
Reviewed-by: Brian Paul <[email protected]>
|