This code was broken in some odd ways before. Too much state was being
saved, it was being restored in the wrong order, and in the wrong way.
The biggest problem was that the pipeline object was restored before
restoring the programs attached to the default pipeline.
Fixes a regression in the glean texgen test.
v3: Fairly significant re-write. I think it's much cleaner now, and it
avoids a bug with some meta ops that use shaders (reported by Chia-I).
v4: Check Pipeline.Current against NULL instead of Pipeline.Default.
Suggested by Chia-I.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
Pull most of the guts out of _mesa_BindPipeline into a new utility
function that can be use elsewhere (e.g., meta).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Don't do anything with variables that have explicitly assigned
locations. This is also how built-in varyings are handled.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
In February 2013 Paul unified the values used for shader stage outputs
and shader stage inputs. See commits 8a076c5f0^..eed6baf76. Since that
time, the location_base parameters are always VARYING_SLOT_VAR0.
Instead of passing that around, just hard code it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.
This fixes linking errors with the piglit CL tests.
v2:
- Use c++ features
- Fix error code handling
v3:
- Move <iostream> into api/util.hpp
- Fix indentation
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
v2: Use the user provided offset and stride when the buffer ID is zero.
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2)
Make set_ubo_binding() just update the binding, and move the code
that does validation, flushes the vertices etc. into a new
bind_uniform_buffer() function.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Document the difference between _mesa_lookup_bufferobj() and
_mesa_multi_bind_lookup_bufferobj().
v3: Don't create the buffer objects when they don't exist.
Reviewed-by: Brian Paul <brianp@vmware.com> (v2)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v2)
Make set_atomic_buffer_binding() just update the binding, and move
the code that does validation, flushes the vertices etc. into a new
bind_atomic_buffer() function.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is for glBindTextures(), since it doesn't change the active
texture unit.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch adds functions for locking/unlocking the mutex, along with
_mesa_HashLookupLocked() and _mesa_HashInsertLocked()
that do lookups and insertions without locking the mutex.
These functions will be used by the ARB_multi_bind entry points to
avoid locking/unlocking the mutex for each binding point.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The texture can only be bound to the index that corresponds to its
target, so there is no need to loop over all possible indices
for every unit and checking if the texture is bound to it.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will be used by glBindTextures() when unbinding textures,
to avoid having to loop over all the targets.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will be used by glBindTextures() so we don't have to look it up
for each texture.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We had the EGLimage structure laying around in intel_regions.h, but now
it's the only thing left in the file.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
v2: Fix bad pointer on unreference (caught by Chad)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
I slipped this in in the region->pitch change from pixels to bytes, but I
don't see any reason for it any more -- the libdrm code doesn't appear to
divide pitch by a cpp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
If the stride wasn't width*cpp, we wouldn't track how much of the src is
busy, and allow a subdata into the end to proceed unsynchronized.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Note: region->width/height used to reflect the total_width/height padding
of separate stencil, though mt->total_width didn't. region->width/height
was being used in EGL images, where the padded value would have been the
wrong one, so I converted them to use rb->Width/Height.
v2: Drop debug printf that slipped in (caught by Ken)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Regions aren't refcounted safely for multithreaded applications, and
they're not terribly useful wrappers of a BO, so I'm trying to remove
them.
Even the stride I added here could probably be reduced to use of an
existing field in the __DRIimageRec, but I want this to be as mechanical
of a change as possible.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
I want to do this to get the region removed from DRI images. However, it
does mean that we won't share the intel_region between the rb and the
texture for texture_from_pixmap. I think that's fine.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
I noticed that we were doing this while changing the DRI3 path to not use
regions, which involved changing the signature of
intel_update_winsys_renderbuffer_miptree() this way.
v2: Replace my comment with Chad's version.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Once a buffer has been named, drm_intel_bo_flink() is just a getter.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The drm function to get the tiling is just a getter storing the two
pointers, so we don't need to go out of our way to avoid it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
All the consumers are doing it on a miptree.
v2: fix a silly duplicated dereference (review by Ken)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v1)
All the consumers are doing it on a miptree.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
v1 of the patch got pushed, insted of the v2 that I had reviewed.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
intel_alloc_renderbuffer_storage() will clobber rb->Format which was
already set up by intel_create_renderbuffer(). This causes the driver
to potentially create the depth buffer in the wrong format.
In practice this makes the depth buffer Z24 even if the visual has
depthBits==16.
The incorrect depth buffer format doesn't seem to cause any actual
problems in i965, but it seems like we should fix it anyway. I see
Z16 has been more or less deprecated in the driver except the for
the depthBits==16 case. But if we want to use Z24 even in that
case (not sure it's really legal?) it would look better if the
code made that decision explicitly rather than relying on the
format to get magically overwritten by the renderbuffer code.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Gen2 doesn't support texturing from Z formats, so state as much.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
intel_alloc_renderbuffer_storage() will clobber rb->Format which was
already set up by intel_create_renderbuffer(). This causes the driver
to potentially create the depth buffer in the wrong format.
Long time ago things worked by accident because
_mesa_choose_tex_format() checked for ARB_depth_texture
and thus returned MESA_FORMAT_NONE on gen2 hardware. Somehow
that ended up working when depthBits==16 because the driver
would then pick DEPTH_FRMT_16_FIXED. Not sure how, but things
also seemed to work with depthBits==24.
Things started to go more sideways at:
commit 6ae473221a
Author: Eric Anholt <eric@anholt.net>
Date: Mon Apr 22 16:04:25 2013 -0700
intel: Fold the one last function intel_tex_format.c into the caller.
since that caused intel_miptree_create_layout() to divide by zero
when encoutering MESA_FORMAT_NONE (bw==0). So after this
commit things were broken enough that many applications wouldn't even
run.
Things got a bit better at:
commit c245efe7e8
Author: Eric Anholt <eric@anholt.net>
Date: Thu Mar 21 09:50:45 2013 -0700
mesa: Remove extension checking from ChooseTexFormat.
since now _mesa_choose_tex_format() would return MESA_FORMAT_X8_Z24
for GL_DEPTH_COMPONENT due to i915 erroneosly claiming that
MESA_FORMAT_X8_S24 (and others) are supported texture formats even
on gen2 hardware. So now the the div-by-zero was gone, but now the
driver would pick DEPTH_FRMT_24_FIXED_8_OTHER even when
depthBits==16 which caused rendering problems.
If we prevent rb->Format from getting clobbered for the depth buffer
things work much better. This makes the spinning title text visible
again in chromium-bsu at 16bpp, for example.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
V2: Follow the new naming convention for unpack functions.
Use double precision for converting Z24 to a float.
V3: Unpack stencil value to most significant byte.
Use 'struct z32f_x24s8' type.
V4: Unpack stencil value to least significant byte.
Add a comment to clarify stencil packing.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
