Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
This is the only method supported in GLSL 1.20 so we take a few short-cuts.
|
|
This allows syntax like "float[8] foo, bar;"
|
|
These arrays will indicate per-input or per-output options for vertex/fragment
programs such as centroid-sampling and invariance.
|
|
Bug #18689
|
|
Fixes invalid memory reference bug when exiting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Plus, update the print/debug code.
|
|
Only one flag defined so far: PROG_PARAM_CENTROID_BIT
|
|
function
Bug #18659.
|
|
|
|
There were hacks in EmitCopyBlit before to adjust offsets so that y=0 after
the offsets had been adjusted for a negative pitch. It appears that those
hacks were due to an unclear and surprising aspect of the hardware: inverting
the pitch results in the blit into the specified rectangle being inverted,
without the user needing to adjust y and base offset.
Tested with piglit copytexsubimage test on 915GM and GM965. Should fix
serious performance issues with ETQW and other applications.
|
|
The blit bitmap code already handles scissoring. This is a 15-100% speedup on
blender benchmark.blend thanks to avoiding fallbacks. Bug #17951.
|
|
Instead, have i965 and i915 both call the generic function from their Viewport.
|
|
texture comparison logic is bypassed if the currently bound texture is not
a depth/depth_stencil texture.
|
|
According to Keith the docs have these offsets the other way around
|
|
|
|
|
|
|
|
RETURN0 macro reports file/line before returning zero.
|
|
We now express arrays in terms of indirect addressing. For example:
dst = a[i];
becomes:
MOV dst, TEMP[1 + TEMP[2].y];
At instruction-emit time indirect addressing is converted into ARL/
ADDR-relative form:
ARL ADDR.x, TEMP[2].y;
MOV dst, TEMP[1 + ADDR.x];
This fixes a number of array-related issues. Arrays of arrays and complex
array/struct nesting works now.
There may be some regressions, but more work is coming.
|
|
|
|
|
|
This fixes glReadPixels(GL_LUMINANCE, GL_FLOAT)/glGetTexImage(GL_LUMINANCE, GL_FLOAT) issue
on fixed-point color buffers.
|
|
The Swizzle and Size fields carry all the info we need now.
|
|
This is a step toward better array handling code. In particular, when more
than one operand of an instruction uses indirect addressing, we'll need some
temporary instructions and registers. By converting IR storage to instruction
operands all in one place (emit_instruction()) we can be smarter about this.
Also, somewhat better handling of dst register swizzle/writemask handling.
This results in tighter writemasks on some instructions which is good for
SOA execution.
And, cleaner instruction commenting with inst_comment().
Next: remove some more dead code and additional clean-ups...
|
|
|
|
|
|
Was broken by commit 9aca9a4b72b2a7b378e50bd88f9c3324d07375ec.
|
|
|
|
|
|
|
|
|
|
|
|
This was a regression in 59b2c2adbbece27ccf54e58b598ea29cb3a5aa85 that broke
blender, among other apps.
|
|
|
|
As far as I can read in the docs, VS threads can be 1:1 with the pairs of
VUE handles allocated for them. Also, G4X can run twice as many threads as
before (though we won't unless the we bump the preferred URB entries for VS).
|
|
We were dividing the number of URB entries by two to get number of threads,
which looks suspiciously like a copy'n'paste-o from brw_vs_state.c. Also, the
maximum number of threads is 24, not 12.
|
|
The clip thread could potentially deadlock when processing tristrips since
being moved back to dual-thread mode, as the two threads could each have 4 VUEs
referenced and not be able to allocate another one since SF processing
wasn't able to continue (needing 5 entries before it freed 2).
In constrained URB mode, similar deadlock could even have occurred with
polygons (so we cut back max_threads if we can't handle it any primitive type).
|
|
|
|
It shouldn't offer anything new over what's in the docs (except for G4X notes),
but here it's all in one place.
|