| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
src/gallium/state_trackers/xorg/xorg_xv.c
src/mesa/drivers/dri/intel/intel_span.c
|
|
Now that XRGB is supported, we don't need to hack around cases of an RGBA
format buffer with an internal format of GL_RGB.
|
|
It turns out that 965 and friends cannot actually render to an xRGB
surfaces. Instead, the surface has to be RGBA with writes to alpha
disabled and the blend function modified to always use 1.0 for
destination alpha.
|
|
Since the texformat branch merge, the value of intel_renderbuffer::texformat
is just a copy of gl_renderbuffer::Format.
|
|
The MaxCombinedTextureImageUnits is the total number of samplers that can
be bound between vertex, geometry, and fragment, not 0. This should report
the correct value on 965 now. Other DRI drivers may also need updating if
their MaxVertexTextureImageUnits != 0 (for example, if using the sw vertex
pipeline).
It's not clear to me if there's going to be a valid value for this
limit other than MaxTextureImageUnits + MaxVertexTextureImageUnits (+
MaxGeometryTextureImageUnits eventually). If not, then we should probably
just move this into the core at Get time.
Bug #25518 (wine regression). Fixes piglit vp-combined-image-units.
|
|
|
|
|
|
Bug #25194.
|
|
This really isn't supported at this point. GEM's been in the kernel for
a year, and the fake bufmgr never really worked.
|
|
|
|
|
|
The padding was there to indicate the amount of space left from the
number of expected bytes in the struct minus allocated bits. But
uint bitfields get packed so that they don't cross uint boundaries, and we
ended up allocating an extra dword to hold the pad field!
|
|
|
|
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
|
|
|
This should fix TXB on G45 and older in the GLSL case.
|
|
New comments should explain some of the confusion about how this message
works.
|
|
|
|
|
|
Fixing this is a prereq for avoiding flagging all state at new
batch time. Eliminating that still causes problems, though (notably
glean logicOp fails on my GM965).
|
|
|
|
|
|
Saves CPU time, resulting in a 2.5% FPS win on ETQW.
|
|
|
|
They're the same regardless of execution width for 8, 4x2, and 16.
|
|
This is a 2.9% (+/-.3%) performance win for my GL demo, which hits MAD
sequences for matrix transforms.
|
|
The cube map array index arg is always present.
|
|
Instead of doing math based on the (broken for VBO && offset != 0)
input->count number, just use the BO size. Fixes assertion failure in ETQW.
|
|
This didn't work for quad/quadstrips at all, and for all other primitive types
it only worked when they were unclipped.
Fix up the former in gs stage (could probably do without these changes and
instead set QuadsFollowProvokingVertexConvention to false), and the rest in
clip stage.
|
|
Previously, we'd load linearly from ParameterValues[0] for the constants,
though ParameterValues[1] may not equal ParameterValues[0] + 4. Additionally,
the STATE_VAL type paramters didn't get updated.
Fixes piglit vp-constant-array-huge.vpfp and ET:QW object locations.
Bug #23226.
|
|
Fixes piglit vp-sge-alias test, and the googleearth ground shader. \o/
Bug #22228
(cherry picked from commit 56ab92bad8f1d05bc22b8a8471d5aeb663f220de)
|
|
Fixes piglit arl.vp.
(cherry picked from commit d52d78b4bcd6d4c0578f972c0b8ebac09e632196)
|
|
|
|
For an app that's blowing out the state cache, like sauerbraten, the
memset of the giant arrays ended up taking 11% of the CPU even when only a
"few" of the entries got used. With this, the WM program compile drops back
down to 1% of CPU time.
Bug #24981 (bisected to BRW_WM_MAX_INSN increase).
|
|
|
|
Fixes piglit vp-sge-alias test, and the googleearth ground shader. \o/
Bug #22228
|
|
Fixes piglit arl.vp.
|
|
No statistically significant performance difference at n=3 with either
openarena or my GL demo, but cutting program size seems like a good
thing to be doing for the hypothetical app that has a working set near
icache size.
|
|
|
|
This should fix issues with antialiased lines in GLSL.
|
|
The PINTERP code should be faster for brw_wm_glsl.c now since brw_wm_emit.c's
had been improved, and pixel_w should no longer stomp on a neighbor to dst.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This drops support for get_src_reg_imm in these, but the prospect of getting
brw_wm_pass*.c onto our GLSL path is well worth some temporary pain.
|
|
This matches brw_wm_emit.c, which we'll be using shortly. There's a
possible penalty here in that we'll allocate registers for unused channels,
since we aren't doing ref tracking like brw_wm_pass*.c does. However, my
measurements on GM965 don't show any for either OA or UT2004 with the GLSL
path forced.
|
|
This keeps the individual state files from having to export their
structures for brw_state_cache initialization.
|
