| Age | Commit message (Collapse) | Author |
|---|
|
_mesa_TexGenf calls _mesa_TexGenfv, which uses the params argument
as an array.
|
|
_mesa_TexGeni calls _mesa_TexGeniv, which uses the params argument
as an array.
|
|
|
|
_mesa_TexEnvf calls _mesa_TexEnvfv, which uses the param argument
as an array.
|
|
|
|
Uf. How embarrassing.
|
|
Sorry for not pushing this before, it got lost in stashes.
|
|
Simplifies things since the second to last one will then
be converted in the subsequent pass that ensures alignment
automatically.
|
|
The hardware wants the pattern the same way it is
passed to glPolygonStipple.
|
|
|
|
All code covered by scons is being built on multiple OSes, so pointer
arithmetic must really be addressed when spotted.
|
|
It's not portable. Warn to help catching it early.
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/drivers/r300/r300_texture.c
src/gallium/state_trackers/xorg/xorg_exa.c
src/mesa/state_tracker/st_cb_texture.c
|
|
Basically don't round up shared textures. This fixes compiz,
but I'm afraid that rounding up texture sizes here in the driver
is doomed, as it will inevitably break texture wrap modes.
|
|
|
|
|
|
This reverts commit 124ae596806f1a77af46f1f0e446d448da6e953a.
Pushed by mistake
|
|
|
|
|
|
|
|
|
|
|
|
I'm not sure if this is a great change, but helps with caching.
Probably we want to turn this on/off on a driver-by-driver basis.
|
|
|
|
This helps improve the surface cache behaviour in the face of the
large number of single-use render targets generated by EXA and the xorg
state tracker. Without this we can reference hundreds of individual
render targets from a command buffer, which leaves little scope for
sharing or reuse of those targets.
Flushing early means we can start reusing textures much sooner.
This shouldn't have much effect on normal 3d rendering as it's pretty
rare to have a command buffer with >8 different render targets in that
world.
|
|
|
|
Drop the 1.1 version suffix.
|
|
Drop the 1.1 version suffix.
|
|
|
|
|
|
|
|
Not really needed, never served its purpose.
|
|
|
|
width/height/depth arrays
|
|
|
|
|
|
We want to fallback to draw splitting when vertex element indices
might be too high for atomic draw path (currently limited to 4095).
|
|
|
|
SSE3 != SSSE3 and so far we only use the later.
|
|
There are no hard requirements at the moment.
We don't really emit any sse3 yet. Just some ssse3.
Thanks to Roland for spotting these incorrections.
|
|
This enum is only supported for OpenGL 2.0. If a driver supports
OpenGL 1.4 and GL_ARB_point_sprite, using this enum should generate an
error. This is important because, for example, i915 and i830 can
support GL_ARB_point_sprite, but they cannot support
GL_POINT_SPRITE_COORD_ORIGIN.
This commit just removes the check for NV_point_sprite, which is
completely wrong, and add some comments describing what the code
should do. I don't see an easy way to check for version >= 2.0 from
inside Mesa. Perhaps we should add an extension
GL_MESA_point_sprite_20 (like Intel's old GL_EXT_packed_pixels_12) to
indicate that this added bit of functionality is available.
Also note that glean's pointSprite test only checks for
GL_ARB_point_sprite before trying to use
GL_POINT_SPRITE_COORD_ORIGIN. Naturally, that fails on
non-2.0 implementations (i.e., Mac OS X on GMA 950).
|
|
Conflicts:
src/mesa/state_tracker/st_atom_shader.c
src/mesa/state_tracker/st_program.c
|
|
LLVM 2.5 is no longer supported on windows.
|
|
|
|
|
|
Thanks to Intel code which I've just stolen pretty much as usual.
This fixes fdo bug 22851 which is a dri1 regression since rewrite.
Tested by: fpiobaf (Fabio) on #radeon
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This makes the miptree rounds up to the near POT for each level for
all radeons, however since mipmaps aren't support with NPOT on previous
radeons this calculation shouldn't cause any problems. If it does
we can just make it r600 only.
I tested a few mipmap demos on r500 and they all seem to work.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
