| Age | Commit message (Collapse) | Author |
|---|
|
GL doesn't actually let you begin an OQ while one is active, so the
extra work was pointless.
|
|
|
|
|
|
Rename old IGDNG to Ironlake, and set 'gen' number for
Ironlake as 5, so tracking the features with generation num
instead of special is_ironlake flag.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Saves an instruction in PINTERP, LINTERP, and PIXEL_W from
brw_wm_glsl.c For non-GLSL it isn't used yet because the deltas have
to be laid out differently.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/mesa/drivers/dri/intel/intel_screen.c
src/mesa/drivers/dri/intel/intel_swapbuffers.c
src/mesa/drivers/dri/r300/r300_emit.c
src/mesa/drivers/dri/r300/r300_ioctl.c
src/mesa/drivers/dri/r300/r300_tex.c
src/mesa/drivers/dri/r300/r300_texstate.c
|
|
|
|
As part of the DRI driver interface rewrite I merged __DRIscreenPrivate
and __DRIscreen, and likewise for __DRIdrawablePrivate and
__DRIcontextPrivate. I left typedefs in place though, to avoid renaming
all the *Private use internal to the driver. That was probably a
mistake, and it turns out a one-line find+sed combo can do the mass
rename. Better late than never.
|
|
Saves another 600 bytes or so of code.
|
|
Saves ~2KB of code.
|
|
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.
|
|
|
|
i965 might support more than 4 color draw buffers. But if not, this protects
from breakage if the Mesa limit is raised.
|
|
This is similar to what r300 does inside the driver, but I've added it as
a generic option since it seems most hardware will want it.
Fixes piglit nv-init-zero-reg.vpfp and nv-init-zero-addr.vpfp.
|
|
ARB_map_buffer_range."
This reverts commit 00413d87426f14df47d90ba3c995e1889e9f88ca. Even with
fixes, using ARB_map_buffer_range in the VBO module isn't showing up as a
significant win, and some cases apparently regressed.
Bug #23624.
|
|
This looks like it's a small win on blender.
|
|
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.
|
|
i915 actually supports up to 4 (according to header file - not tested),
i965 up to 16 (code already handled this but slightly broken), so don't use 2
for all chips, even though angular dependency is very high.
|
|
The default for EmitCondCodes got flipped when gallium-0.2 was merged.
This fixes GLSL if/else/endif regressions.
Drivers that use GLSL should always explicitly set the flag to be safe.
|
|
|
|
|
|
Rendering and textures are limited to 8kx8k, but mesa limits things to
4kx4k, and magic guard band stuff may break on 8kx8k drawing. This is safe
though, and makes compiz work on bigger screens.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
This lets GLSL shaders use up to 16 samplers.
Fixed function is still limited to 8 textures.
Tested with progs/glsl/samplers.c
|
|
Instead, have i965 and i915 both call the generic function from their Viewport.
|
|
Previously, since my check_aperture API change, we would check each piece of
state against the batchbuffer individually, but not all the state against the
batchbuffer at once. In addition to not being terribly useful in assuring
success, it probably also increased CPU load by calling check_aperture many
times per primitive.
|
|
|
|
The i965 driver previously had it's own set of code to convert
fixed-function TNL state to a vertex program. Core Mesa has code to
do this, so there is no reason to duplicate that effort in the driver.
In fact, this duplication leads to bugs when other aspects of the Mesa
infrastructure change.
|
|
This fixes bugzilla #17718.
|
|
Makefile.template
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
Conflicts:
src/mesa/drivers/dri/common/dri_bufmgr.c
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
|
|
This disallows vertex shader texture sampling. See bugs 16157, 13838.
|
|
|
|
fix double free issue(bug#14710). It also corrects glsl/bitmap demo behavior.
|
|
|
|
With DRI2 we there is no screen region until a drawable is bound to
the context. Set up the framebuffer texture in meta_draw_region instead
which should also handle the case where the draw region changes as a
result of resizing a redirected window or resizing the screen.
|
|
|
|
dd1d66fc4ab5d7064113a2017a431c3461598b91.
|
|
|
|
The user-space suballocator that was used avoided relocation computations by
using the general and surface state base registers and allocating those types
of buffers out of pools built on top of single buffer objects. It also
avoided calls into the buffer manager for these small state allocations, since
only one buffer object was being used.
However, the buffer allocation cost appears to be low, and with relocation
caching, computing relocations for buffers is essentially free. Additionally,
implementing the suballocator required a don't-fence-subdata flag to disable
waiting on buffer maps so that writing new data didn't block on rendering using
old data, and careful handling when mapping to update old data (which we need
to do for unavoidable relocations with FBOs). More importantly, when the
suballocator filled, it had no replacement algorithm and just threw out all
of the contents and forced them to be recomputed, which is a significant cost.
This is the first step, which just changes the buffer type, but doesn't yet
improve the hash table to not result in full recompute on overflow. Because
the buffers are all allocated out of the general buffer allocator, we can
no longer use the general/surface state bases to avoid relocations, and they
are set to 0 instead.
|
|
It makes quake4-demo works well on 965.
|
|
The only functional difference should be that 965 now gets the optimization
where textures default to 16bpp when the screen is 16bpp.
|
