| Age | Commit message (Collapse) | Author |
|---|
|
The i915 (and related graphics cores) only support TEXCOORDMODE_CLAMP and
TEXCOORDMODE_CUBE when using cube map texture coordinates, so fall back to
software rendering for other modes to avoid potential gpu hang issue. This
fixes scorched3d issue on 945GM(see bug 14539).
|
|
This leads to problems when the batchbuffer is flushed, but the bitmap
data could not fit into it.
|
|
Fixes a segfault in oglconform fbo.c test.
|
|
The images aren't mapped at this point, so we want the generic Mesa path for
GenerateMipmapEXT that does the mapping/unmapping for us. Ideally Mesa would
just call it for us.
|
|
This was another opportunity to either get clipped to screen size or not get
clipped enough and draw outside of object boundaries.
|
|
Bug #18914. Fixes fbo_firecube hang due to drawing outside the FBO bounds.
Thanks to Pierre Willenbrock for debugging the issue.
|
|
|
|
This is fallout from the ffvertex_prog.c work. It doesn't call
ProgramStringNotify, so we don't set param_state, so we wouldn't track when
VP parameters changed, and constants wouldn't get uploaded. Instead, remove
param_state entirely and just use the real value that we want to be tracking.
Fixes rendering in openarena since BRW_NEW_BATCH got disentangled from
BRW_NEW_INDICES.
Bug #18822.
|
|
|
|
Intel docs state that only 830/845 have VBOs, 855/865 don't. So
lets just not use them on i8xx at all.
This restores the old pre-vbo code and uses it on all 8xx hw.
|
|
The CACHE_NEW_SURFACE bit always gets spammed since we get many different
surface BOs per state emit, but the only consumer of it wanted to just know
how many surfaces were enabled.
|
|
Fixes upload of large amounts of state for every new primitive emit.
|
|
This was causing a prepare of wm state at every primitive emit.
|
|
|
|
|
|
Later primitives, even if they caused a full state validate, wouldn't check
that there was enough space in the batchbuffer, occasionally triggering the
sanity check. We also skipped the aperture space check, even if it would
mean bringing in new programs and associated state.
|
|
|
|
|
|
Fixes invalid memory reference bug when exiting.
|
|
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.
|
|
According to Keith the docs have these offsets the other way around
|
|
|
|
|
|
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.
|
|
This ensures all batchbuffers have a same cliprect mode after calling
_intel_batchbuffer_flush even if there aren't invalid commands in the
current batch buffer. (fix bug#18362).
|
|
|
|
See bug 18445.
When getting array results, __glXReadReply() always reads a multiple of
four bytes. This can cause writing to invalid memory when 'n' is not a
multiple of four.
Special-case the glAreTexturesResident() functions now.
To fix the bug, we use a temporary buffer that's a multiple of four bytes
in length.
NOTE: this commit also reverts part of commit 919ec22ecf72aa163e1b97d8c7381002131ed32c
(glx/x11: Added some #ifdef GLX_DIRECT_RENDERING protection) which
directly edited the indirect.c file rather than the python generator!
I'm not repairing that issue at this time.
|
|
|
|
Trunc is a more accurate description; there's no type conversion involved.
|
|
Now i965 also uses the vertex program created by Mesa Core, but this vertex program
is not only depend on mesa state _NEW_PROGRAM, so always check the current vertex
program is updated or not. This fixes broken demo cubemap.
|
|
OPCODE_NOISE4 coming later.
|
|
|
|
This cuts one MOV out when setting a zero header.
|
|
The mobile and desktop chipsets are the same, and having them separate is
more typing and more chances to screw up.
|
|
Also, add a comment explaining what brw->urb.constrained tries to do.
|
|
Quoting section 11.3.10, paragraph 10.2 of the 965PRM:
10.2. If ExecSize is 1, dst.HorzStride must not be 0. Note that this is
relaxed from rule 10.1.2. Also note that this rule for destination
horizontal stride is different from that for source as stated in
rule #7.
GM45 gets very angry when rule 10.2 is violated.
Patch 58dc8b7 (i965: support destination horiz strides in align1 access mode)
added support for additional horizontal strides in the ExecSize 1 case, but
failed to notice that mesa occasionally re-purposes a register as a
temporary destination, even though it was constructed as a repeating source
with HorzStride = 0.
While, ideally, we should probably fix the code using these register
specifications, this patch simply rewrites them to use HorzStride 1 as the
pre-58dc8b7 code did.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
GL_COLOR_INDEX mode is just like other normal formats (that is, not
depth/stencil) and is uploaded fine by TexImage.
|
|
|
|
(Only in fragment shaders, so far. Support for NOISE3 and NOISE4 to come.)
|
|
This is required for scatter writes in destination regions to work.
|
|
|
