Re: [Mesa-dev] [PATCH] gallium: add bits for clipping points as tris (d3d-style)
Am 10.01.2014 12:04, schrieb Erik Faye-Lund: > On Fri, Jan 10, 2014 at 10:33 AM, Lauri Kasanen wrote: >> On Fri, 10 Jan 2014 03:57:45 +0100 >> srol...@vmware.com wrote: >> >>> From: Roland Scheidegger >>> >>> OpenGL does whole-point clipping, that is a large point is either fully >>> clipped or fully unclipped (the latter means it may extend beyond the >>> viewport as long as the center is inside the viewport). d3d9 (d3d10 has >>> no large points) however requires points to be clipped after they are >>> expanded to a rectangle. (Note some IHVs are known to ignore GL rules at >>> least with some hw/drivers.) >>> >>> Hence add a rasterizer bit indicating which way points should be clipped >>> (some drivers probably will always ignore this), and add the draw >>> interaction >>> this requires. Drivers wanting to support this and using draw must support >>> large points on their own as draw doesn't implement vp clipping on the >>> expanded points (it potentially could but the complexity doesn't seem >>> warranted), and the driver needs to do viewport scissoring on such points. >> >> Is there any possibility of this being exposed to user-space? With that >> hat on, it would have been useful to me several times in the past. >> >> Perhaps whoever was Mesa's ARB contact could propose an extension? I >> know nothing about how that happens, just would like this functionality. > > IIRC there were some draft by NVIDIA discussed in Khronos OpenGL ES > meetings 6-7 years ago, but I don't think it ever resulted in a > released extension spec > I think the spec would actually be a bit messy, as it means you have to convert points essentially to tris before before rasterization (before clipping in fact), so it doesn't really fit into "normal" pipeline. The llvmpipe implementation (which is only in a private branch as it can't be merged easily to master due to needing fake viewport scissoring) of course doesn't do this (points rasterization is way easier than tris) but just pretends like it does. It is worth noting d3d10 got rid of the problem entirely (for large points you have to explicitly convert your points to tris in the gs). Also, even if we had such an extension, drivers need to implement this. I don't know if all hw can easily do that, though at least some nvidia cards with blob will always follow d3d9 behavior (but I have no idea if the hw couldn't do GL behavior or nvidia just thought the d3d9 behavior is more useful anyway). (Not saying I'd object such an extension just rather it's out of the scope of this patch as we just need it for d3d9.) Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add bits for clipping points as tris (d3d-style)
On Fri, Jan 10, 2014 at 10:33 AM, Lauri Kasanen wrote: > On Fri, 10 Jan 2014 03:57:45 +0100 > srol...@vmware.com wrote: > >> From: Roland Scheidegger >> >> OpenGL does whole-point clipping, that is a large point is either fully >> clipped or fully unclipped (the latter means it may extend beyond the >> viewport as long as the center is inside the viewport). d3d9 (d3d10 has >> no large points) however requires points to be clipped after they are >> expanded to a rectangle. (Note some IHVs are known to ignore GL rules at >> least with some hw/drivers.) >> >> Hence add a rasterizer bit indicating which way points should be clipped >> (some drivers probably will always ignore this), and add the draw interaction >> this requires. Drivers wanting to support this and using draw must support >> large points on their own as draw doesn't implement vp clipping on the >> expanded points (it potentially could but the complexity doesn't seem >> warranted), and the driver needs to do viewport scissoring on such points. > > Is there any possibility of this being exposed to user-space? With that > hat on, it would have been useful to me several times in the past. > > Perhaps whoever was Mesa's ARB contact could propose an extension? I > know nothing about how that happens, just would like this functionality. IIRC there were some draft by NVIDIA discussed in Khronos OpenGL ES meetings 6-7 years ago, but I don't think it ever resulted in a released extension spec. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add bits for clipping points as tris (d3d-style)
On Fri, 10 Jan 2014 03:57:45 +0100 srol...@vmware.com wrote: > From: Roland Scheidegger > > OpenGL does whole-point clipping, that is a large point is either fully > clipped or fully unclipped (the latter means it may extend beyond the > viewport as long as the center is inside the viewport). d3d9 (d3d10 has > no large points) however requires points to be clipped after they are > expanded to a rectangle. (Note some IHVs are known to ignore GL rules at > least with some hw/drivers.) > > Hence add a rasterizer bit indicating which way points should be clipped > (some drivers probably will always ignore this), and add the draw interaction > this requires. Drivers wanting to support this and using draw must support > large points on their own as draw doesn't implement vp clipping on the > expanded points (it potentially could but the complexity doesn't seem > warranted), and the driver needs to do viewport scissoring on such points. Is there any possibility of this being exposed to user-space? With that hat on, it would have been useful to me several times in the past. Perhaps whoever was Mesa's ARB contact could propose an extension? I know nothing about how that happens, just would like this functionality. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add bits for clipping points as tris (d3d-style)
From: Roland Scheidegger
OpenGL does whole-point clipping, that is a large point is either fully
clipped or fully unclipped (the latter means it may extend beyond the
viewport as long as the center is inside the viewport). d3d9 (d3d10 has
no large points) however requires points to be clipped after they are
expanded to a rectangle. (Note some IHVs are known to ignore GL rules at
least with some hw/drivers.)
Hence add a rasterizer bit indicating which way points should be clipped
(some drivers probably will always ignore this), and add the draw interaction
this requires. Drivers wanting to support this and using draw must support
large points on their own as draw doesn't implement vp clipping on the
expanded points (it potentially could but the complexity doesn't seem
warranted), and the driver needs to do viewport scissoring on such points.
Conflicts:
src/gallium/drivers/llvmpipe/lp_context.c
src/gallium/drivers/llvmpipe/lp_state_derived.c
---
src/gallium/auxiliary/draw/draw_context.c | 12 +++-
src/gallium/auxiliary/draw/draw_context.h |3 +-
src/gallium/auxiliary/draw/draw_pipe_clip.c| 31 ++--
src/gallium/auxiliary/draw/draw_private.h |2 ++
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c |3 +-
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |3 +-
src/gallium/docs/source/cso/rasterizer.rst | 15 +++---
src/gallium/drivers/svga/svga_swtnl_draw.c |2 +-
src/gallium/include/pipe/p_state.h |1 +
9 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b/src/gallium/auxiliary/draw/draw_context.c
index 2b3bc0d..9b5bcb5 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -262,6 +262,10 @@ static void update_clip_flags( struct draw_context *draw )
draw->rasterizer && draw->rasterizer->depth_clip);
draw->clip_user = draw->rasterizer &&
draw->rasterizer->clip_plane_enable != 0;
+ draw->clip_points_xy = draw->clip_xy &&
+ (!draw->driver.bypass_clip_points ||
+ (draw->rasterizer &&
+ !draw->rasterizer->point_tri_clip));
}
/**
@@ -287,17 +291,23 @@ void draw_set_rasterizer_state( struct draw_context *draw,
* Some hardware can turn off clipping altogether - in particular any
* hardware with a TNL unit can do its own clipping, even if it is
* relying on the draw module for some other reason.
+ * Setting bypass_clip_points to achieve d3d-style point clipping (the driver
+ * will need to do the "vp scissoring") _requires_ the driver to implement
+ * wide points / point sprites itself (points will still be clipped if
rasterizer
+ * point_tri_clip isn't set). Only relevant if bypass_clip_xy isn't set.
*/
void draw_set_driver_clipping( struct draw_context *draw,
boolean bypass_clip_xy,
boolean bypass_clip_z,
- boolean guard_band_xy)
+ boolean guard_band_xy,
+ boolean bypass_clip_points)
{
draw_do_flush( draw, DRAW_FLUSH_STATE_CHANGE );
draw->driver.bypass_clip_xy = bypass_clip_xy;
draw->driver.bypass_clip_z = bypass_clip_z;
draw->driver.guard_band_xy = guard_band_xy;
+ draw->driver.bypass_clip_points = bypass_clip_points;
update_clip_flags(draw);
}
diff --git a/src/gallium/auxiliary/draw/draw_context.h
b/src/gallium/auxiliary/draw/draw_context.h
index e2e0cb4..65716c9 100644
--- a/src/gallium/auxiliary/draw/draw_context.h
+++ b/src/gallium/auxiliary/draw/draw_context.h
@@ -263,7 +263,8 @@ void draw_set_render( struct draw_context *draw,
void draw_set_driver_clipping( struct draw_context *draw,
boolean bypass_clip_xy,
boolean bypass_clip_z,
- boolean guard_band_xy);
+ boolean guard_band_xy,
+ boolean bypass_clip_points);
void draw_set_force_passthrough( struct draw_context *draw,
boolean enable );
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index dbb6757..adfa4b6 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -609,12 +609,37 @@ do_clip_line( struct draw_stage *stage,
static void
clip_point( struct draw_stage *stage,
- struct prim_header *header )
+struct prim_header *header )
{
- if (header->v[0]->clipmask == 0)
+ if (header->v[0]->clipmask == 0)
stage->next->point( stage->next, header );
}
+/*
+ * Clip points but ignore the first 4 (xy) clip planes.
+ * (This is necessary because we don't generate a differe
