In make_image_for_buffer(), use VK_IMAGE_USAGE_SAMPLED_BIT when
transferring from the buffer and use VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
when transferring to the buffer.
Similar to 9ffc1049ca (freedreno/ir3: use nir two-sided-color lowering).
No piglit regression.
Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bring the following commit over to i915:
commit ec542d7457
Author: Eric Anholt <eric@anholt.net>
Date: Mon Mar 3 10:43:10 2014 -0800
i965: Drop broken front_buffer_reading/drawing optimization.
Not sure if it might fix anything, but since the i965 and i915 used to
share a bunch of that code, it would seem reasonable the same problems
could be present in the i915 code still, and the i965 approach is well
tested by now so bringing it over seems fairly safe.
No piglit regressions on 855.
v2: Rebase on _mesa_is_front_buffer_* refactor.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There are multiple similar implementations of these functions, and a
later patch was going to add another.
v2: Move removing intel_framebuffer to a different patch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
v2: Since state_tracker does not call _mesa_init_driver_functions, we
need to initialize the dd::NewFramebuffer pointer to
_mesa_new_framebuffer here. Suggested by Brian.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Flip the cull bits when rendering to a user fbo on gen2. This
was already done on gen3 (since before git history starts)
but was missing from the gen2 code.
Fixes rendering of the driver+kart model in supertuxkart kart
selection screen.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The hardware can draw lines 0.5 to 7.5 pixels wide. Adjust the limits
to 1.0-7.0. The old limits seems to be from the era when i915 and i965
were sharing this code.
Not really sure if 1.0-7.0 is correct. Maybe it could be 0.5.7.5 as
those are the hw limits, or maybe some combination of the two?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The sub-pixel adjustment for points was killed off in
commit 60d762aa62
Author: Xiang, Haihao <haihao.xiang@intel.com>
Date: Wed Jan 2 11:38:51 2008 +0800
i915: Needn't adjust pixel centers. fix#12944
so if we don't need it in intel_tris.c we don't need it in
intel_render.c either, which means we can allow intel_render.c to render
points.
No apparent regressions on PNV in ES1 or ES2 conformance.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
intelFastRenderClippedPoly() renders the polygon using triangles. For
polygons the provoking vertex is always the first one, and currently
this function assumes that the provoking vertex for triangles is the
last one. In case the user changed the provoking vertex convention,
the hardware may be configured to treat the first vertex of triangles
as the provoking vertex. So check the convention and emit the triangles
in the appropriate order to avoid having to change the hardware
provoking vertex convention for rendering polygons.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When drawing quads using triangles we need to be careful to make
the provoking vertices match when flat shading.
v2: Major rebase on top of Ian's other t_dd_dmatmp.h work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
When rendering quad strips via tri strips we can't get the provoking
vertex right, so disallow flat shading.
v2: Major rebase on top of Ian's other t_dd_dmatmp.h work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
We can allow rendering flat shaded polygons using tri fans if we check
the provoking vertex convention.
v2 (idr): Remove _EXT suffixes from GL_FIRST_VERTEX_CONVENTION.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From http://lists.freedesktop.org/archives/mesa-dev/2015-May/084883.html:
"There are no real error cases here, just dead code.
validate_render() is supposed to make sure we never call these
functions if the code can't actually render the primitives. The
fprintf()+return branches should really just contain assert(0) or
equivalent."
I also rearranged the if-else-block in render_quad_strip_verts to look
more like the other functions. A future patch is going to change a
bunch of that code anyway.
v2: Make "unreachable" message more descriptive. Suggested by Iago.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Chad Versace