| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 840c09fc71542fdfc71edd2a2802925d467567bb)
|
|
We currently weasel out of supporting the timeout parameter, but otherwise
this extension looks ready, and should make the common case happy.
|
|
ARB_map_buffer_range."
This reverts commit 00413d87426f14df47d90ba3c995e1889e9f88ca. Even with
fixes, using ARB_map_buffer_range in the VBO module isn't showing up as a
significant win, and some cases apparently regressed.
Bug #23624.
|
|
|
|
|
|
|
|
|
|
This looks like it's a small win on blender.
|
|
Previously we blocked because I hadn't added the libdrm function. Now it's
there, so update your libdrm.
|
|
Increase the number of native program parameters to the same values
exposed by GLSL.
|
|
Several changes are made to program parameter limits. Several of the
non-NATIVE limits are set higher. All of the NATIVE limits are set to
zero in the core Mesa code. Each driver must set the actual value in
its context creation routine. If the NATIVE value remains zero, this
indicates that hardware shaders may not be supported.
Each of the preceeding changes matches the bahavior of Apple's shader
assembler, so it seems safe.
Finally, we limit the value of MaxEnvParams to be no greater than
MaxNativeAttribs. At least one case has been found where an
application does the wrong thing if MaxNativeAttribs < MaxEnvParams.
See also bugzilla #23490.
|
|
|
|
The instructions we're translating already went through the brw_wm_pass_fp()
function which does the sampler->texture unit mapping. We were applying
the sample->unit mapping a second time in the GLSL texture emitters.
Often, this made no difference but other times it could lead to accessing
an invalid texture and could cause a GPU lockup.
|
|
|
|
Check that all the textures needed by the current fragment program
actually exist and are valid.
|
|
We'll use this for debug/sanity checking.
|
|
|
|
|
|
DPH can output to any component, not just to X. This allows fpalu.c
to run without hitting the assertion in emit_dph.
|
|
|
|
|
|
if stride is 0 we cannot use count as max index for bounds checking,
since the hardware will simply return 0 as data for indices failing
bounds check. If stride is 0 any index should be valid hence simply
disable bounds checking in this case.
This fixes bugs introduced with e643bc5fc7afb563028f5a089ca5e38172af41a8.
|
|
|
|
|
|
This branch introduces new FRAG_ATTRIB_FACE and FRAG_ATTRIB_PNTC fragment
program inputs for GLSL gl_FrontFacing and gl_PointCoord. Before, these
attributes were packed with the FOG attribute. That made things
complicated elsewhere.
|
|
Fixes cube mapping since the scalar changes.
|
|
This matches brw_wm_pass*.c behavior, and fixes the norsetto shadow demo.
Bug #19489
|
|
|
|
|
|
|
|
|
|
I'll be using this in merging brw_wm_emit.c and brw_wm_glsl.c
|
|
This is preparation for merging of brw_wm_glsl.c and
brw_wm_emit.c, and glsl.c doesn't swizzle channel results around.
|
|
This doesn't fix the glean testcase, but I guess it provides hope.
|
|
|
|
No performance difference proven at 95% confidence with my GLSL demo (n=10).
|
|
This saves mapping the index buffer to get a bounds on the indices that
drivers just drop on the floor in the VBO case (cache win), saves a bonus
walk of the indices in the CheckArrayBounds case, and other miscellaneous
validation. On intel it's a particularly a large win (50-100% in my app)
because even though we let the indices stay in both CPU and GPU caches, we
still end up waiting for the GPU to be done with the buffer before reading
from it.
Drivers that want the min/max_index fields must now check index_bounds_valid
and use vbo_get_minmax_index before using them.
|
|
|
|
|
|
This showed a 1.9% (+/-.3%, n=3) improvement in OA performance with high
geometry settings.
|
|
|
|
For some IZ setups, we'd forget to account for the source depth register
being present, so we'd both read the wrong reg, and write output depth to
the wrong reg.
Bug #22603.
|
|
|
|
Fixes piglit glsl-vs-if-bool and progs/glsl/twoside, and will likely be
useful for the looping code.
Bug #18992
|
|
Previously, we'd be branching based on whatever condition code happened to be
laying around.
|
|
|
|
|
|
|
|
|
|
I was getting tired of doing the dance of INTEL_DEBUG=batch, copying it out,
and running intel-gen4disasm on it.
|
