| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Since the shine tables are now only used in the tnl lighting stage, where
they are validated through the tnl driver function NotifyMaterialChange
called in tnl/t_vb_light.c, we can not omit calling
_mesa_validate_all_lighting_tables (which only validates the shine tables)
in main/light.c.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Now that _tnl_RasterPos no longer uses the shine tables, avoid
revalidating them.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use direct computation of pow for computing the shininess
in _tnl_RasterPos. Since the _tnl_RasterPos function is still
used by plenty drivers that do only need the shine table for
_tnl_RasterPos but do not make use of swtnl computations, this
enables pushing down the shine table computation and validation
into the tnl module, which will happen in a followup change.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Since the shine tables are implicitly invalidated by having
a different shininess value than the current one, we can
omit the explicit invalidation of the shine table.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
| |
This variable is only used locally in _mesa_update_lighting.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
| |
It is only used as a temporary variable during computation of
_CosCutoff. So, don't store it.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
| |
|
|
|
|
|
| |
For 1D array textures, there is no border on the height dimension.
For 2D array textures, there is no border on the depth dimension.
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
| |
Move structs, enums, etc so they're in more logical order. In particular,
the shader and transform feedback-related structs/enums were pretty
scattered around.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to allocate new space every time to avoid blocking on the last
HiZ op completing. There are two easy ways to do this:
brw_state_batch() and intel_upload_data(). brw_state_batch() is
simpler and avoids another buffer allocation.
Improves Unigine Tropics performance 0.376416% +/- 0.148722% (n=7).
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mesa has a fast path for the generic fallback when using glReadPixels
for RGBA data which uses memcpy. However it was really difficult to
hit this case because it would not be used if any transferOps are
enabled. Any type apart from floating point or non-normalized integer
types (so any of the common types) would force enabling clamping so
the fast path could not be used. This patch makes it ignore clamping
when determining whether to use the fast path if the data type of the
buffer is an unsigned normalized type because in that case clamping
will not have any effect anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=46631
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
postpone unreferences until end of function, as the ones in use will
get naturally dereferenced.
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
Can't see any reason this wouldn't be better off as an inline.
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
r600g is the only driver which has made use of it. The reason the CAP was
added was to fix some piglit tests when the GLSL pass lower_output_reads
didn't exist.
However, not removing output reads breaks the fallback for glClampColorARB,
which assumes outputs are not readable. The fix would be non-trivial
and my personal preference is to remove the CAP, considering that reading
outputs is uncommon and that we can now use lower_output_reads to fix
the issue that the CAP was supposed to workaround in the first place.
|
|
|
|
|
|
|
|
| |
This patch allows the Mac OS X SCons build to complete. The assembly
sources contain psuedo-ops that not are supported on Mac OS X.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
| |
|
|
|
|
|
| |
Use the max 2D/rect texture size as the limit. If that's not true
for some devices we'll need new PIPE_CAP_ queries.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Define new MAX_VIEWPORT_WIDTH/HEIGHT and MAX_RENDERBUFFER_SIZE values
instead.
|
|
|
|
|
| |
define a PROG_MAX_WIDTH var instead. It has to match MAX_WIDTH in
swrast. More elaborate refactoring could fix that (someday).
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
We'll get rid of MAX_WIDTH, MAX_HEIGHT soon.
|
| |
|
| |
|
|
|
|
|
| |
There aren't any more stack-allocated arrays dimensioned by MAX_WIDTH
so there shouldn't be any more stack overflows.
|
| |
|
| |
|
| |
|
|
|
|
| |
Use some per-context temporary arrays instead.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Max texture and viewport size is only limited by MAX_WIDTH/HEIGHT for swrast.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt:
Accepted by the <cap> parameter of Enable, Disable and IsEnabled,
and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv
and GetDoublev:
TEXTURE_CUBE_MAP_SEAMLESS 0x884F
This caused a change in enums.c, which is manually built from the .xml
files.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
To allow creating floating point buffers / pbuffers.
Reviewed-by: Jose Fonseca <[email protected]>
|