| Age | Commit message (Collapse) | Author |
|---|
|
Should help with a few non-TCL bugs.
|
|
This fixes some missing primitives which had been drawn right before the next glClear().
|
|
Attribs must be packed: position, point size, colors, texcoords.
Thanks to osiris for pointing it out.
|
|
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
|
|
|
|
|
|
Here is a couple of fixes for GNU/Hurd:
- dri_interface.h: no libdrm support either.
- configure.ac:
- GNU/Hurd is a GNU OS with _GNU_SOURCE and PTHREADS.
- GNU needs a couple of flags like other OSes
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
|
|
|
|
Fall back to interpreter in this case.
|
|
This interface gives the driver two important features. First, it can
allocate the (fake) front-buffer only when needed. Second, it can
tell the buffer allocator the format of buffers being allocated. This
enables support for back-buffer and depth-buffer with different bits
per pixel.
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>
|
|
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
|
|
|
|
Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
|
|
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.
|
|
|
|
|
|
|
|
Move between mipmaps, render a triangle, reload textures with either
the original arch (and GenMipmaps) or via straightforward glTexImage.
|
|
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!!!
|
|
|
|
In the VS constants can now be handled in two different ways:
1. If there's room in the GRF, put constants there. They're preloaded from
the CURBE prior to VS execution. This is the historical approach. The
problem is the GRF may not have room for all the shader's constants and
temps and misc registers. Hence...
2. Use a separate constant buffer which is read from using a READ message.
This allows a very large number of constants and frees up GRF regs for
shader temporaries. This is the new approach. May be a little slower
than 1.
1 vs. 2 is chosen according to how many constants and temps the shader needs.
|
|
|
|
These types are only found in the new surface state cache now.
|
|
|
|
|
|
|
|
The new, second cache will only be used for surface-related items.
Since we can create many surfaces the original, single cache could get
filled quickly. When we cleared it, we had to regenerate shaders, etc.
With two caches, we can avoid doing that.
|
|
|
|
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.
|
