Age | Commit message (Collapse) | Author |
|
|
|
Conflicts:
src/gallium/auxiliary/util/u_network.c
src/gallium/auxiliary/util/u_network.h
src/gallium/drivers/i915/i915_state.c
src/gallium/drivers/trace/tr_rbug.c
src/gallium/state_trackers/vega/bezier.c
src/gallium/state_trackers/vega/vg_context.c
src/gallium/state_trackers/xorg/xorg_crtc.c
src/gallium/state_trackers/xorg/xorg_driver.c
src/gallium/winsys/xlib/xlib_brw_context.c
src/mesa/main/mtypes.h
|
|
|
|
Shaves 400 bytes or so from i915_dri.so.
|
|
We don't actually care which register is used since we're just
swizzling (0,0,0,0), but it should be a valid variable number.
Detected by clang.
|
|
The same code is generated, and readers and static analyzers are
happier.
|
|
Conflicts:
src/mesa/main/version.h
src/mesa/state_tracker/st_atom_shader.c
|
|
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.
|
|
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.
|
|
|
|
The base of the texture is always the base of the miptree. If it wasn't,
we'd have issues with this code due to miptrees not walking the same
direction for all LODs.
|
|
Conflicts:
src/gallium/drivers/svga/svga_screen_texture.c
src/gallium/state_trackers/xorg/xorg_composite.c
src/gallium/state_trackers/xorg/xorg_exa.c
src/gallium/state_trackers/xorg/xorg_renderer.c
src/gallium/state_trackers/xorg/xorg_xv.c
src/mesa/main/texgetimage.c
src/mesa/main/version.h
|
|
Conflicts:
progs/util/shaderutil.c
src/mesa/drivers/dri/r600/r600_context.c
src/mesa/main/version.h
|
|
|
|
|
|
|
|
Support still isn't completely correct, but it's better. piglit
point-sprite now passes. However, glean's pointSprite test fails. In
that test the texture on the sprite is somehow inverted as though
GL_POINT_SPRITE_COORD_ORIGIN were set to GL_LOWER_LEFT. i915 hardware
shouldn't be able to do that!
I believe there are also problems when not all texture units have
GL_COORD_REPLACE set. The hardware enable seems to be all or nothing.
Fixes bug #25313.
|
|
|
|
|
|
|
|
|
|
This should do all the things that MI_FLUSH did, but it can be pipelined
so that further rendering isn't blocked on the flush completion unless
necessary.
|
|
Before, if we just called glXMakeCurrent() and didn't render anything we'd
still trigger a flushFrontBuffer() call.
Now only set the intel->front_buffer_dirty field at state validation time
just before we draw something.
NOTE: additional calls to intel_check_front_buffer_rendering() might be
needed if I missed some rendering paths.
|
|
Pass a gl_format to intel_create_renderbuffer() instead of GLenum.
Add cases for MESA_FORMAT_XRGB8888 textures and renderbuffers.
However, we don't yet create any renderbuffers or textures with that
format. It seems the default alpha value is zero instead of one.
Need to investigate that first.
|
|
Fixes piglit tex1d-2dborder test.
|
|
Previously, S8_Z24 depth textures would always be treated as intensity.
Fixes piglit depth-tex-modes.
|
|
This gets us expected behavior for clamping between mipmap levels, and
avoids relayout of textures for doing clamping.
Fixes piglit lodclamp-between.
|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
Bug #24734.
|
|
Bug #24734.
|
|
|
|
|
|
And change parameter type.
|
|
Driver Makefiles can still add symlink dependencies/rules if needed.
|
|
This lets us get rid of intel_miptree_depth_offsets() and simplify all
of the calling code.
|
|
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
|
|
And remove other unneeded #includes while we're at it.
|
|
Other vendors have enabled ARB_fragment_shader as part of OpenGL 2.0
enablement even on hardware like the 915 with no dynamic branching or
dFdx/dFdy support. But for now we'll leave it disabled because we don't
do any flattening of ifs or loops, which is rather restrictive.
This support is not complete, and may be unstable depending on your shaders.
It passes 10/15 of the piglit glsl tests, but hangs on glean glsl1.
|
|
|
|
|
|
Since the TNL is all done in software anyway, it should be the same to
the user who's probably using ARB_vertex_program otherwise, but gives them
a nicer programming environment.
|
|
This fixes potential heap trashing if the program of choice exceeds limits,
and fixes the native instructions limit being lower than what can be
used by valid programs.
|
|
Previously, we were doing it in the midst of the pipeline run, which gave
an opportunity to enable/disable fallbacks, which is certainly the wrong
time to be doing so. This manifested itself in a NULL dereference for PutRow
after transitioning out of a fallback during a run_pipeline in glean glsl1.
|
|
This reverts commit e7044d552c6d16389447880b8744a51de1cf0199. It
prevented the driver from ever recovering from a software fallback due
to a program error. The original bug it claimed to fix doesn't appear to
exist post-revert.
|
|
Previously, we'd go trashing the heap.
|
|
It's misleading to report things like the program having too many native
instructions as a Mesa implementation error, when the program may just be
too big for the hardware.
|