| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
As of commit 23ad86cfb91c294ce85a3116d4b825aaa3988a6e all messages go
through output_if_debug().
Add new parameter to output_if_debug() to indicate whether to emit a newline.
_mesa_warning() and _mesa_error() calls should not end their strings with \n.
_mesa_debug() calls should end their text with \n.
|
|
dri_bo_subdata()
This wraps up the unfinished business from commit a9a363f8298e9d534e60e3d2869f8677138a1e7e
|
|
This can be almost impossible to avoid - hopefully we won't encounter
a situation where this is a true requirement. Would probably require
drivers to flush between hardware and software vertex processing.
|
|
|
|
need to clamp point size to user set min/max values, even for constant
point size. Fixes glean pointAtten test.
|
|
|
|
The drm_intel_gem_bo_map_gtt() call that replaced dri_bo_map() is
producing errors like:
intel_bufmgr_gem.c:689: Error preparing buffer map 39 (vp_const_buffer): Invalid argument .
and returning NULL, causing a segfault in the memcpy().
Just reverting until we can get to the root issue...
|
|
forgot to commit the changes to actually support 4x aniso filtering...
|
|
Also fixes drawing to 3D texture depth levels.
|
|
This is a CPU win in general, but in particular reduces the pain of
Mesa's calculation of min/max indices in DrawElements (wtf?).
|
|
Need to use the data pointed to for pixmap contents in that case.
Fixes RENDER based text rendering.
|
|
For unsupported devices the screen/context creation should fail cleanly later
on.
|
|
|
|
Various breakage otherwise, e.g. _XSERVER64 not being defined on 64 bit leading
to inconsistent definitions of X server internal structs.
|
|
|
|
Call FLUSH_VERTICES() in _mesa_Histogram().
No need to signal _NEW_PIXEL in ResetHistogram(), ResetMinmax().
|
|
|
|
|
|
|
|
Calling _mesa_dump_textures() deleted the textures... oops!!!
|
|
|
|
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.
|
|
This is a follow-on to commit c1a3b852807fb160f0cd246c1364b7336b4b947e.
Note that (at this time) wherever _NEW_PROGRAM_CONSTANTS is set we're still
setting _NEW_PROGRAM so this won't really make any difference (for now).
|
|
Lost in commit e50dd26ca6d0eb0d0f97c2780020ea16e3d4a687.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
Need to do this to ensure vbo code unmaps its buffers before calling
the driver, which may be sitting on top of a memory manager which
objects to firing commands from a mapped buffer.
|
|
When a new program is bound but no constants are updated we still need
to update the Gallium const buffer.
|
|
|
|
We can simplify this now that we no longer have any dynamic atoms.
|
|
Just use the new _NEW_PROGRAM_CONSTANTS flag instead.
|
|
This state flag will be used to indicate that vertex/fragment program
constants have changed. _NEW_PROGRAM will be used to indicate changes
to the vertex/fragment shader itself, or misc related state.
_NEW_PROGRAM_CONSTANTS is also set whenever a program parameter that's
tracking GL state has changed. For example, if the projection matrix is
in the parameter list, calling glFrustum() will cause _NEW_PROGRAM_CONSTANTS
to be set. This will let to remove the need for dynamic state atoms in
some drivers.
For now, we still set _NEW_PROGRAM in all the places we used to. We'll no
longer set _NEW_PROGRAM in glUniform() after drivers/etc have been updated.
|
|
|
|
|
|
|
|
|
|
This fixes some warnings which appear because the driver assumes a wrong
cs size (13 vs 16 register writes in some cases).
|
|
|
|
Return the conservative PIPE_REFERENCED_FOR_READ | PIPE_REFERENCED_FOR_WRITE
value for now.
This fixes a bunch of regressions seen in piglit and glean.
|
|
This came from commit 1b2ab023673261b4b942e1126c0b599d02fbd4a0
|
|
|
|
These don't respect the stdcall, so they crash upon return.
|
|
|
|
|
|
This needs a proper fix to propogate the out-of-memory condition back
up to Mesa and the app as a GL error. Until then, at least catch the
problem at its source.
|
|
Try to avoid creating multiple blend atoms.
|
|
|
|
|
|
|
|
|
