| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
We don't have all of the features of this extension hooked up yet, but
the consensus yesterday was that since those features are things that
we should also be supporting in our ES2 implementation, claiming ES2
here too doesn't make anything worse and will make incremental
improvement through piglit easier.
|
|
|
|
|
|
| |
This code should never have been triggered, but I often did anyway
when I disabled optimization passes during debugging, then spent my
time debugging that this code doesn't work.
|
|
|
|
| |
No effect, since it was called before live intervals were calculated.
|
| |
|
|
|
|
|
|
|
| |
Until we get the EXT_framebuffer_sRGB extension we should bind the sRGB
formats for FBO as linear.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
OES_standard_derivatives must be manually disabled for i915 because Mesa
enables it by default.
|
| |
|
|
|
|
|
|
|
|
|
| |
Without this, X doesn't start with UMS on r300g.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
We were trying to interpolate, which would end up doing unnecessary
math, and doing so on undefined values. Fixes glsl-fs-flat-color.
|
|
|
|
|
|
|
|
| |
With the change to not reset baselevel, this GL_LINEAR filtering was
resulting in generating mipmaps off of the base level instead of the
next higher detail level. Fixes fbo-generatemipmap-filtering.
Reported by: Neil Roberts <[email protected]>
|
|
|
|
|
|
| |
The ad-hoc placement of recalculation somewhere between when they got
invalidated and when they were next needed was confusing. This should
clarify what's going on here.
|
|
|
|
|
| |
We were returning the negative absolute value, instead of the absolute
value. Fixes glsl-vs-abs-neg.
|
|
|
|
|
| |
We were returning the negative absolute value, instead of the absolute
value. Fixes glsl-fs-abs-neg.
|
|
|
|
|
|
| |
This greatly improves codegen for programs with flow control by
allowing coalescing for all instructions at the top level, not just
ones that follow the last flow control in the program.
|
|
|
|
|
| |
The _Enabled field is the thing that takes into account whether
there's a stencil buffer. Tested with piglit glx-visuals-stencil.
|
|
|
|
| |
Signed-off-by: Alberto Milone <[email protected]>
|
|
|
|
|
|
|
|
|
| |
When attaching a small mipmap level to an FBO, the original gen4
didn't have the bits to support rendering to it. Instead of falling
back, just blit it to a new little miptree just for it, and let it get
revalidated into the stack later just like any other new teximage.
Bug #30365.
|
|
|
|
|
| |
It's been replaced by just setting texObj->mt to image->mt at TexImage
time.
|
|
|
|
|
|
|
| |
This avoids relayouts in the common case of glGenerateMipmap() or
people doing similar things.
Bug #30366.
|
|
|
|
|
|
|
|
| |
If we hit this path, we're level 1+ and the base level got allocated
as a single level instead of a full tree (so we don't match
intelObj->mt). This tries to recover from that so that we end up with
2 allocations and 1 validation blit (old -> new) instead of
allocations equal to number of levels and levels - 1 blits.
|
|
|
|
|
|
|
| |
We don't need to worry about levels other than MaxLevel because we're
minifying -- the lower levels (higher detail) won't contribute to the
result. By changing BaseLevel, we forced hardware that doesn't
support BaseLevel != 0 to relayout the texture object.
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 7ce6517f3ac41bf770ab39aba4509d4f535ef663.
This reverts commit d60145d06d999c5c76000499e6fa9351e11d17fa.
I was wrong about which generations supported baselevel adjustment --
it's just gen4, nothing earlier. This meant that i915 would have
never used the mag filter when baselevel != 0. Not a severe bug, but
not an intentional regression. I think we can fix the performance
issue another way.
|
| |
|
| |
|
|
|
|
| |
Again, this makes it match the documentation.
|
|
|
|
|
|
|
|
|
| |
Most _3DSTATE defines contain the command type, sub-type, opcode, and
sub-opcode (i.e. 0x7905). These, however, contain only the sub-opcode
(i.e. 0x05). Since they are inconsistent with the rest of the code and
nothing uses them, simply delete them.
The _3DOP and _3DCONTROL defines seemed similar, and were also unused.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
There really shouldn't be any difference between the two for us.
Fixes a bug where Z16 renderbuffers would be untiled on gen6, likely
leading to hangs.
|
| |
|
| |
|
|
|
|
| |
Fixes an abort in fbo-generatemipmap-formats.
|
|
|
|
|
|
|
| |
By relying on just intel_span_supports_format, some formats that
aren't supported pre-gen4 were not reporting FBO incomplete. And we
also complained in stderr when it happened on i915 because draw_region
gets called before framebuffer completeness validation.
|
|
|
|
|
|
|
|
|
|
|
| |
ARB_fbo no longer disallows mismatched width/height on attachments
(shouldn't be any problem), mixed format color attachments (we only
support 1), and L/A/LA/I color attachments (we already reject them on
965 too). It requires Gen'ed names (driver doesn't care), and adds
FramebufferTextureLayer (we don't do texture arrays). So it looks
like we're already in the position we need to be for this extension.
Bug #27468, #32381.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general, we have to negate in immediate values we pass in because
the src1 negate field in the register description is in the bits3 slot
that the 32-bit value is loaded into, so it's ignored by the hardware.
However, the src0 negate field is in bits1, so after we'd negated the
immediate value loaded in, it would also get negated through the
register description. This broke this VP instruction in the position
calculation in civ4:
MAD TEMP[1], TEMP[1], CONST[256].zzzz, CONST[256].-y-y-y-y;
Bug #30156
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This should make it easier to cross-reference the code and hardware
documentation, as well as clear up any confusion on whether constants
like CMD_3D_WM_STATE mean WM_STATE (pre-gen6) or 3DSTATE_WM (gen6+).
This does not rename any pre-gen6 defines.
|
|
|
|
|
|
|
|
| |
See http://bugs.freedesktop.org/show_bug.cgi?id=32859
NOTE: This is a candidate for the 7.9 and 7.10 branches.
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
this fixes doom3 crash.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
BaseLevel/MaxLevel are mostly used for two things: clamping texture
access for FBO rendering, and limiting the used mipmap levels when
incrementally loading textures. By restricting our mipmap trees to
just the current BaseLevel/MaxLevel, we caused reallocation thrashing
in the common case, for a theoretical win if someone really did want
just levels 2..4 or whatever of their texture object.
Bug #30366
|
|
|
|
| |
We're always making a single-level, 0-baselevel miptree.
|
|
|
|
|
|
|
|
|
| |
This has always been ugly about our texture code -- object base/max
level vs intel object first/last level vs image level vs miptree
first/last level. We now get rid of intelObj->first_level which is
just tObj->BaseLevel, and make intelObj->_MaxLevel clearly based off
of tObj->_MaxLevel instead of duplicating its code (incorrectly, as
image->MaxLog2 only considers width/height and not depth!)
|
|
|
|
| |
Fixes lodclamp-between and lodclamp-between-max.
|
|
|
|
|
| |
This avoids 8xx-specific texture relayout for min/max lod changes.
One step closer to avoiding relayout for base/maxlevel changes!
|