| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
There's a bunch of stuff from gen4asm and gpu-tools that we probably want
to make into a library instead of cargo-culting it around.
|
|
|
|
Bug #20821
|
|
This avoids sending a bad buffer address to the GPU due to programmer error,
and is permitted by the ARB_vbo spec. Note that we still have the opportunity
to dereference past the end of the GPU, because we aren't clipping to a
correct _MaxElement, but that appears to be harder than it should be. This
gets us the 90% solution.
Bug #19911.
|
|
See comment on Vertex URB Entry Read Length for VS_STATE.
This, combined with the previous three commits, fixes #22945.
|
|
This fix is just from code and docs inspection, but it may fix hangs on
some applications.
|
|
It appears that sometimes Mesa (and I suppose a VS could as well) emits
a program which references no vertex data, and thus we end up with
nr_enabled == 0 even though some VBs are enabled. We'd end up emitting
VB/VE packet headers of 0xffffffff in that case, leading to GPU hangs.
Bug #22945 (wine with an uncompiled VS)
|
|
The code duplication bothered me.
|
