Re: [Mesa-dev] [PATCH 1/4] Gallium: fix indentation in u_blitter.c
Looks good. Marek 2011/6/4 Stéphane Marchesin : > --- > src/gallium/auxiliary/util/u_blitter.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/auxiliary/util/u_blitter.c > b/src/gallium/auxiliary/util/u_blitter.c > index a4c3990..528f344 100644 > --- a/src/gallium/auxiliary/util/u_blitter.c > +++ b/src/gallium/auxiliary/util/u_blitter.c > @@ -770,7 +770,7 @@ void util_blitter_copy_region(struct blitter_context > *blitter, > > /* Check if we can sample from and render to the surfaces. */ > /* (assuming copying a stencil buffer is not possible) */ > - if ((!ignore_stencil && is_stencil) || > + if ((!ignore_stencil && is_stencil) || > !screen->is_format_supported(screen, dst->format, dst->target, > dst->nr_samples, bind) || > !screen->is_format_supported(screen, src->format, src->target, > -- > 1.7.5.3.367.ga9930 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] Gallium: fix indentation in u_blitter.c
2011/6/3 Stéphane Marchesin : > --- > src/gallium/auxiliary/util/u_blitter.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/auxiliary/util/u_blitter.c > b/src/gallium/auxiliary/util/u_blitter.c > index a4c3990..528f344 100644 > --- a/src/gallium/auxiliary/util/u_blitter.c > +++ b/src/gallium/auxiliary/util/u_blitter.c > @@ -770,7 +770,7 @@ void util_blitter_copy_region(struct blitter_context > *blitter, > > /* Check if we can sample from and render to the surfaces. */ > /* (assuming copying a stencil buffer is not possible) */ > - if ((!ignore_stencil && is_stencil) || > + if ((!ignore_stencil && is_stencil) || > !screen->is_format_supported(screen, dst->format, dst->target, > dst->nr_samples, bind) || > !screen->is_format_supported(screen, src->format, src->target, > -- > 1.7.5.3.367.ga9930 For the series, Reviewed-by: Brian Paul Do you have git-commit? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37862] Mesa 7.11-devel implementation error: _mesa_texstore_null() is called
https://bugs.freedesktop.org/show_bug.cgi?id=37862 --- Comment #4 from Pepi 2011-06-04 08:43:09 PDT --- Thanks Marek, I downloaded it from: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6491e9593d5cbc5644eb02593a2f562447efdcbb Extract it. Make it with: "make linux-x86-64". But then...what? On the build folder (lib64) I have the following: libOpenVG.so -> libOpenVG.so.1 libOpenVG.so.1 -> libOpenVG.so.1.0.0 libOpenVG.so.1.0.0 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] Gallium: fix indentation in u_blitter.c
2011/6/4 Brian Paul : > 2011/6/3 Stéphane Marchesin : >> --- >> src/gallium/auxiliary/util/u_blitter.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/src/gallium/auxiliary/util/u_blitter.c >> b/src/gallium/auxiliary/util/u_blitter.c >> index a4c3990..528f344 100644 >> --- a/src/gallium/auxiliary/util/u_blitter.c >> +++ b/src/gallium/auxiliary/util/u_blitter.c >> @@ -770,7 +770,7 @@ void util_blitter_copy_region(struct blitter_context >> *blitter, >> >> /* Check if we can sample from and render to the surfaces. */ >> /* (assuming copying a stencil buffer is not possible) */ >> - if ((!ignore_stencil && is_stencil) || >> + if ((!ignore_stencil && is_stencil) || >> !screen->is_format_supported(screen, dst->format, dst->target, >> dst->nr_samples, bind) || >> !screen->is_format_supported(screen, src->format, src->target, >> -- >> 1.7.5.3.367.ga9930 > > For the series, Reviewed-by: Brian Paul > > Do you have git-commit? > Yes I do, but more will come in the next days, so I'll push all my patches then. Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
2011/4/26 Christian König : > Hi Andy and everybody on the list, > > sorry for the late reply, but i've been on vacation the last couple of > days. > > Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss: >> In addition to the quit crash I notice that resizing will also crash. > Should be fixed by now. I implemented most of the missing "base" > functionality in vdpau state tracker, so video displaying should now > work fine. > >> When testing this HD vid - >> >> http://www.w6rz.net/newmobcal1920.ts >> >> It played and looked OK for about 5 seconds, but then stopped and I got >> lots of - >> >> radeon_bo_fixed_map failed to map bo >> EE radeon_bo.c:120 radeon_bo - failed to map bo > I couldn't reproduce the error, but it sounds like a out of (video) > memory problem to me. Please try again and see if it still crashes. > > Additional to the work on the vdpau state tracker, I've worked on the > xvmc and general decoding stuff a bit more: > > * Added attributes for brightness, contrast, saturation, hue and > colourspace > * Got xines xxmc output plugin working with the xvmc implementation > * Fixed the bug in the mc code that caused most of the artefacts in the > pendulum video > * Reorganized and cleaned up the xvmc<->driver interface so it's using > allot less cpu power. > * Implemented basic support for a "zscan and quantification" stage > > To sum it up: Video output of a 1920x1080 video now uses something > around ~20% CPU time on my old test system, compared to ~50% with Xv, > including all the nice features like overlay menu rendering for example > (ok only working with mplayer right now, not xine). > > So is there something still missing for the xvmc state tracker, or can I > continue with implementing the vdpau state tracker? > > Regards, > Christian. Is there a reason that this can't be merged to master? It seems like the longer it remains as a branch, the more mess there is going to be from merging master into pipe-video over and over again. It won't hurt anyone to have it in master, so I think you should just go ahead and merge it. I also don't think it's too late to wipe out the "Merge remote-tracking branch 'mareko/r300g-draw-instanced' into pipe-video" and subsequent revert from git. No one is basing their work on your branch. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37862] Mesa 7.11-devel implementation error: _mesa_texstore_null() is called
https://bugs.freedesktop.org/show_bug.cgi?id=37862 --- Comment #5 from Marek Olšák 2011-06-04 12:21:06 PDT --- Use autogen.sh with --enable-gallium-r600, then type make. These: lib/libGL.so* lib/gallium/r600_dri.so are the files you should use. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function
Le 03/06/2011 01:40, Brian Paul a écrit :
> I'd like to avoid the warning if at all possible. If you replace (val
>>> 32) with (val >> (sizeof(unsigned) * 4)) does that silence it?
Yes it fix, but as Matt Turner said, it's not necessary to check this.
Btw we don't check that in the other functions.
Le 03/06/2011 06:09, Matt Turner a écrit :
> Also, if you want to check if the value is already a power-of-two,
> instead of a case statement for every POT (including 0), just do the
> standard is-power-of-two check:
>
> (x & (x - 1)) == 0
My own tests (on a Core2) shows that it's less efficient to do that, at
least with -O2 optimization enabled. With -O0, it's equal.
So here is a v2 patch with a builtin GCC optimization which is the
fastest (thx Matt to point me to this solution).
Regards.
Benjamin Bellec
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..1b984b6 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -42,7 +42,6 @@
#include "pipe/p_compiler.h"
#include "util/u_debug.h"
-
#ifdef __cplusplus
extern "C" {
#endif
@@ -486,24 +485,49 @@ util_logbase2(unsigned n)
return pos;
}
-
/**
* Returns the smallest power of two >= x
*/
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
-
+#if defined(PIPE_CC_GCC)
if (x == 0)
return 1;
-
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ else
+ return (1 << (32 - __builtin_clz(x - 1)));
+#else
+ unsigned val = x;
+
+ switch (x)
+ {
+ case 1:
+ case 2:
+ case 4:
+ case 8:
+ case 16:
+ case 32:
+ case 64:
+ case 128:
+ case 256:
+ case 512:
+ case 1024:
+ case 2048:
+ case 4096:
+ return x; /* this is the most commonly used values */
+ case 0:
+ return 1;
+ default:
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ val++;
+ return val;
+ }
+#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/brw: Emit state for hiz and separate stencil buffers
On 06/03/2011 03:33 PM, Kenneth Graunke wrote:
> On 06/03/2011 12:47 PM, Chad Versace wrote:
>> When emitting 3DSTATE_DEPTH_BUFFER, also emit 3DSTATE_HIER_DEPTH_BUFFER if
>> there is a hiz buffer. Ditto for 3DSTATE_STENCIL_BUFFER and a separate
>> stencil buffer.
>>
>> Signed-off-by: Chad Versace
>
> Overall, looks good...a few comments inline.
>
>> ---
>> src/mesa/drivers/dri/i965/brw_misc_state.c | 114
>> --
>> src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 +
>> 2 files changed, 106 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
>> b/src/mesa/drivers/dri/i965/brw_misc_state.c
>> index 3ec9009..84120da 100644
>> --- a/src/mesa/drivers/dri/i965/brw_misc_state.c
>> +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
>> @@ -202,6 +202,8 @@ static void prepare_depthbuffer(struct brw_context *brw)
>>
>> if (drb)
>> brw_add_validated_bo(brw, drb->region->buffer);
>> + if (drb&& drb->hiz_region)
>> + brw_add_validated_bo(brw, drb->hiz_region->buffer);
>> if (srb)
>> brw_add_validated_bo(brw, srb->region->buffer);
>> }
>> @@ -212,14 +214,28 @@ static void emit_depthbuffer(struct brw_context *brw)
>> struct gl_context *ctx =&intel->ctx;
>> struct gl_framebuffer *fb = ctx->DrawBuffer;
>> /* _NEW_BUFFERS */
>> - struct intel_renderbuffer *irb = intel_get_renderbuffer(fb,
>> BUFFER_DEPTH);
>> + struct intel_renderbuffer *depth_irb = intel_get_renderbuffer(fb,
>> BUFFER_DEPTH);
>> + struct intel_renderbuffer *stencil_irb = intel_get_renderbuffer(fb,
>> BUFFER_STENCIL);
>> + struct intel_region *hiz_region = depth_irb ? depth_irb->hiz_region :
>> NULL;
>> unsigned int len;
>>
>> - /* If we're combined depth stencil but no depth is attached, look
>> -* up stencil.
>> + /*
>> +* If depth and stencil buffers are identical, then don't use separate
>> +* stencil.
>> */
>> - if (!irb)
>> - irb = intel_get_renderbuffer(fb, BUFFER_STENCIL);
>> + if (depth_irb&& depth_irb == stencil_irb) {
>> + stencil_irb = NULL;
>> + }
>> +
>> + /*
>> +* If stencil buffer uses combined depth/stencil format, but no depth
>> buffer
>> +* is attached, then use stencil buffer as depth buffer.
>> +*/
>> + if (!depth_irb&& stencil_irb
>> +&& stencil_irb->Base.Format == MESA_FORMAT_S8_Z24) {
>> + depth_irb = stencil_irb;
>> + stencil_irb = NULL;
>> + }
>>
>> if (intel->gen>= 6)
>> len = 7;
>> @@ -228,7 +244,7 @@ static void emit_depthbuffer(struct brw_context *brw)
>> else
>> len = 5;
>>
>> - if (!irb) {
>> + if (!depth_irb&& !stencil_irb) {
>> BEGIN_BATCH(len);
>> OUT_BATCH(_3DSTATE_DEPTH_BUFFER<< 16 | (len - 2));
>> OUT_BATCH((BRW_DEPTHFORMAT_D32_FLOAT<< 18) |
>> @@ -244,11 +260,57 @@ static void emit_depthbuffer(struct brw_context *brw)
>>OUT_BATCH(0);
>>
>> ADVANCE_BATCH();
>> +
>> + } else if (!depth_irb&& stencil_irb) {
>> + /*
>> + * There exists a separate stencil buffer but no depth buffer.
>> + *
>> + * The stencil buffer inherits most of its fields from
>> + * 3DSTATE_DEPTH_BUFFER: namely the tile walk, surface type, width,
>> and
>> + * height.
>> + *
>> + * Since the stencil buffer has quirky pitch requirements, its region
>> + * was allocated with half height and double cpp. So we need
>> + * a multiplier of 2 to obtain the surface's real height.
>> + *
>> + * Enable the hiz bit because it and the separate stencil bit must
>> have
>> + * the same value. From Section 2.11.5.6.1.1 3DSTATE_DEPTH_BUFFER, Bit
>> + * 1.21 "Separate Stencil Enable":
>> + * [DevIL]: If this field is enabled, Hierarchical Depth Buffer
>> + * Enable must also be enabled.
>> + *
>> + * [DevGT]: This field must be set to the same value (enabled or
>> + * disabled) as Hierarchical Depth Buffer Enable
>> + */
>> + assert(intel->has_separate_stencil);
>> + assert(stencil_irb->Base.Format == MESA_FORMAT_S8);
>> +
>> + BEGIN_BATCH(len);
>> + OUT_BATCH(_3DSTATE_DEPTH_BUFFER<< 16 | (len - 2));
>> + OUT_BATCH((BRW_DEPTHFORMAT_D32_FLOAT<< 18) |
>> +(1<< 21) | /* separate stencil enable */
>> +(1<< 22) | /* hiz enable */
>> +(BRW_TILEWALK_YMAJOR<< 26) |
>> +(BRW_SURFACE_2D<< 29));
>> + OUT_BATCH(0);
>> + OUT_BATCH(((stencil_irb->region->width - 1)<< 6) |
>> + (2 * stencil_irb->region->height - 1)<< 19);
>> + OUT_BATCH(0);
>> + OUT_BATCH(0);
>> +
>> + if (intel->gen>= 6)
>> + OUT_BATCH(0);
>> +
>> + ADVANCE_BATCH();
>> +
>> } else {
>> - struct intel_region *region = irb->region;
>> + struct intel_region *region = depth_irb->region;
>> unsigned int format;
>> uint32_t tile_x, tile_y, offse
Re: [Mesa-dev] [PATCH 2/2] intel: Define span functions for S8 renderbuffers
On 06/03/2011 03:36 PM, Kenneth Graunke wrote: > On 06/03/2011 12:47 PM, Chad Versace wrote: >> Since the stencil buffer is interleaved, the generic Mesa renderbuffer >> accessors do not suffice. Custom span functions are necessary. >> >> Signed-off-by: Chad Versace > > I know you had done this with handwritten functions at one point, rather than > using stenciltmp.h. Why the change, if you don't > mind me asking? Either way is fine, of course. Before finalizing the patch, I decided to thoroughly inspect the macros-from-hell one more time, just to make sure that I didn't miss some necessary magic they did. And, I did miss some magic. The macros perform clipping on the span ranges. Rather than try to duplicate (likely incorrectly) the macros' clipping logic, I just bit the bullet and used them. > I haven't verified your math but I know that it's necessary and that you've > tested it. > > Acked-by: Kenneth Graunke -- Chad Versace c...@chad-versace.us ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
Am Samstag, den 04.06.2011, 15:20 -0400 schrieb Matt Turner: > Is there a reason that this can't be merged to master? Since float buffer support was merged to master I can't see any more obstacles. Just gone over the branch one more time and fixed some problem created by merging. > It seems like the longer it remains as a branch, the more mess there > is going to be from merging master into pipe-video over and over > again. Merging with master is actually quite simple most of the time, but I haven't tried the other way around jet. > It won't hurt anyone to have it in master, so I think you should just > go ahead and merge it. Ok, If nobody objects till tomorrow evening I going to push it to master. > I also don't think it's too late to wipe out the "Merge > remote-tracking branch 'mareko/r300g-draw-instanced' into pipe-video" > and subsequent revert from git. No one is basing their work on your > branch. Already reverted it. Thanks, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/10] i965: Implement hiz and separate stencil for window framebuffer
Patch 01: dri2proto Patch 02: xf86-video-intel Patch 03-10: mesa I'm aware that this patch series is painful to review. Thank you in advance for your reviewed-by's. There is a related patch series on the intel-gfx list that adds the necessary functionality to xf86-video-intel. See the thread with subject: ddx/dri: Add support for hiz and separate stencil buffers Give close attention to the comments in "intel: Define enum intel_dri2_has_hiz". That gives an overview of how the DRI2 handshake works and why it is necessary. I hear the grumbling already... "Chad significantly altered ancient, core driver routines! Did he break the world?" I can confidently say "No"; this patch series causes no regressions. I have performed full piglit runs that cover all (meaningful) combinations of the following: * xf86-video-intel: master vs my hiz branch * mesa: master vs my hiz branch * hiz enabled and disabled via environment var overrides You can find the test results here: [1] http://people.freedesktop.org/~chadversary/piglit-results/2011-06-04-1600-hiz-compare/summary/index.html [2] http://people.freedesktop.org/~chadversary/piglit-results/2011-06-04-1600-hiz-compare/summary/changes.html The column's titles should clearly mark what's what; the title format is "uuid--hostname--mesa@version--xf86-video-intel@version--hiz-[on|off]" Column 1 is the baseline (mesa@master, ddx@master). Columns 2 and 5 use my mesa hiz branch with hiz and separate stencil disabled. The diff from column 1 to 2 shows no regressions and one fix. CC: Eric Anholt CC: Ian Romanick CC: Kenneth Graunke CC: Kristian Høgsberg Chad Versace (8): dri2: Add token for DRI2BufferHiz intel: Define enum intel_dri2_has_hiz intel: Add flags to intel_screen for hiz and separate stencil intel/intel_context.c: Remove unused functions intel: Add function intel_renderbuffer_set_hiz_region() intel: Refactor intel_update_renderbuffers() intel: Add assertions to intelCreateBuffer() intel: Request DRI2 buffers for separate stencil and hiz include/GL/internal/dri_interface.h|1 + src/mesa/drivers/dri/intel/intel_context.c | 792 ++-- src/mesa/drivers/dri/intel/intel_fbo.c | 12 + src/mesa/drivers/dri/intel/intel_fbo.h |5 + src/mesa/drivers/dri/intel/intel_screen.c | 103 - src/mesa/drivers/dri/intel/intel_screen.h | 62 +++ 6 files changed, 803 insertions(+), 172 deletions(-) -- 1.7.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] Add attachment token DRI2BufferHiz
... and bump version to 2.6.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
configure.ac |2 +-
dri2proto.txt |6 +-
dri2tokens.h |1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 297be0e..d671f5a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([DRI2Proto], [2.5],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([DRI2Proto], [2.6],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/dri2proto.txt b/dri2proto.txt
index dc46e58..df763c7 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -178,7 +178,8 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
DRI2BufferAccum
DRI2BufferFakeFrontLeft
DRI2BufferFakeFrontRight
-DRI2BufferDepthStencil }
+DRI2BufferDepthStencil
+DRI2BufferHiz }
These values describe various attachment points for DRI2
buffers.
@@ -509,6 +510,8 @@ The DRI2 extension has undergone a number of revisions
before
2.3: Added the DRI2InvalidateBuffers event.
+ 2.6: Enlightenment attained. Added the DRI2BufferHiz attachment.
+
Compatibility up to 2.0 is not preserved, but was also never released.
@@ -569,6 +572,7 @@ A.1 Common Types
0x7 DRI2BufferFakeFrontLeft
0x8 DRI2BufferFakeFrontRight
0x9 DRI2BufferDepthStencil
+ 0xa DRI2BufferHiz
└───
Used to encode the possible attachment points. The attachment
DRI2BufferDepthStencil is only available with protocol version 1.1 or
diff --git a/dri2tokens.h b/dri2tokens.h
index 7804e4d..16c9008 100644
--- a/dri2tokens.h
+++ b/dri2tokens.h
@@ -43,6 +43,7 @@
#define DRI2BufferFakeFrontLeft7
#define DRI2BufferFakeFrontRight 8
#define DRI2BufferDepthStencil 9
+#define DRI2BufferHiz 10
#define DRI2DriverDRI 0
#define DRI2DriverVDPAU1
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] dri: Add support for DRI2BufferStencil and DRI2BufferHiz
Before this commit, if a client were to request a stencil or hiz buffer, then
I830DRI2CreateBuffer() allocated and returned an X-tiled buffer by
accident. (DRI2BufferStencil and DRI2BufferHiz were unintentionally caught
by the default case of a switch statement.)
Now, I830DRI2CreateBuffer() correctly returns a Y-tiled buffer and handles
the stencil buffer as a special case due its quirky pitch requirements.
This shouldn't break older Mesa versions, because they never query (via
DRI2GetBuffersWithFormat) for the drawable's DRI2BufferStencil.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/intel_dri.c | 30 ++
1 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 48d0f56..4bcec45 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -329,11 +329,16 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int
attachment,
pixmap = get_front_buffer(drawable);
if (pixmap == NULL) {
unsigned int hint = INTEL_CREATE_PIXMAP_DRI2;
+ int pixmap_width = drawable->width;
+ int pixmap_height = drawable->height;
+ int pixmap_cpp = (format != 0) ? format : drawable->depth;
if (intel->tiling & INTEL_TILING_3D) {
switch (attachment) {
case DRI2BufferDepth:
case DRI2BufferDepthStencil:
+ case DRI2BufferStencil:
+ case DRI2BufferHiz:
if (SUPPORTS_YTILING(intel)) {
hint |= INTEL_CREATE_PIXMAP_TILING_Y;
break;
@@ -344,11 +349,28 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int
attachment,
}
}
+ /*
+* The stencil buffer has quirky pitch requirements. From Vol
+* 2a, 11.5.6.2.1 3DSTATE_STENCIL_BUFFER, field "Surface
+* Pitch":
+*The pitch must be set to 2x the value computed based on
+*width, as the stencil buffer is stored with two rows
+*interleaved.
+* To accomplish this, we resort to the nasty hack of doubling
+* the drm region's cpp and halving its height.
+*
+* If we neglect to double the pitch, then
+* drm_intel_gem_bo_map_gtt() maps the memory incorrectly.
+*/
+ if (attachment == DRI2BufferStencil) {
+ pixmap_height /= 2;
+ pixmap_cpp *= 2;
+ }
+
pixmap = screen->CreatePixmap(screen,
- drawable->width,
- drawable->height,
- (format != 0) ? format :
- drawable->depth,
+ pixmap_width,
+ pixmap_height,
+ pixmap_cpp,
hint);
if (pixmap == NULL || intel_get_pixmap_bo(pixmap) == NULL) {
if (pixmap)
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] dri2: Add token for DRI2BufferHiz
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
include/GL/internal/dri_interface.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index d791557..f022b44 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -692,6 +692,7 @@ struct __DRIswrastExtensionRec {
#define __DRI_BUFFER_FAKE_FRONT_LEFT 7
#define __DRI_BUFFER_FAKE_FRONT_RIGHT 8
#define __DRI_BUFFER_DEPTH_STENCIL 9 /**< Only available with DRI2 1.1 */
+#define __DRI_BUFFER_HIZ 10
struct __DRIbufferRec {
unsigned int attachment;
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] intel: Define enum intel_dri2_has_hiz
... which indicates if the X driver supports DRI2BufferHiz and
DRI2BufferStencil.
I'm placing this in its own commit due to the large comment block.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_screen.h | 54 +
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.h
b/src/mesa/drivers/dri/intel/intel_screen.h
index 4613c98..d4add6a 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.h
+++ b/src/mesa/drivers/dri/intel/intel_screen.h
@@ -34,6 +34,60 @@
#include "i915_drm.h"
#include "xmlconfig.h"
+/**
+ * \brief Does the X driver support DRI2BufferHiz and DRI2BufferStencil?
+ *
+ * The DRI2 protocol does not allow us to query the X driver's version nor
+ * query for a list of buffer formats that the driver supports. So, to
+ * determine if the X driver supports DRI2BufferHiz and DRI2BufferStencil we
+ * must resort to a handshake.
+ *
+ * If the hardware lacks support for separate stencil (and consequently, lacks
+ * support for hiz also), then the X driver's separate stencil and hiz support
+ * is irrelevant and the handshake never occurs.
+ *
+ * Complications
+ * -
+ * The handshake is complicated by a bug in the current driver version. Even
+ * though the driver currently does not support requests for DRI2BufferHiz or
+ * DRI2BufferStencil, if requested one it still allocates and returns one. The
+ * returned buffer, however, is incorrectly X tiled.
+ *
+ * How the handshake works
+ * ---
+ * (TODO: To be implemented on a future commit).
+ *
+ * Initially, intel_screen.dri2_has_hiz is set to unknown. The first time the
+ * user requests a depth and stencil buffer, intelCreateBuffers() creates a
+ * framebuffer with separate depth and stencil attachments (with formats
+ * x8_z24 and s8).
+ *
+ * Eventually, intel_update_renderbuffers() makes a DRI2 request for
+ * DRI2BufferStencil and DRI2BufferHiz. If the returned buffers are Y tiled,
+ * then we joyfully set intel_screen.dri2_has_hiz to true and continue as if
+ * nothing happend.
+ *
+ * If the buffers are X tiled, however, the handshake has failed and we must
+ * clean up.
+ *1. Angrily set intel_screen.dri2_has_hiz to false.
+ *2. Discard the framebuffer's depth and stencil attachments.
+ *3. Attach a packed depth/stencil buffer to the framebuffer (with format
+ * s8_z24).
+ *4. Make a DRI2 request for the new buffer, using attachment type
+ * DRI2BufferDepthStencil).
+ *
+ * Future Considerations
+ * -
+ * On a sunny day in the far future, when we are certain that no one has an
+ * X driver installed without hiz and separate stencil support, then this
+ * enumerant and the handshake should die.
+ */
+enum intel_dri2_has_hiz {
+ INTEL_DRI2_HAS_HIZ_UNKNOWN,
+ INTEL_DRI2_HAS_HIZ_TRUE,
+ INTEL_DRI2_HAS_HIZ_FALSE,
+};
+
struct intel_screen
{
int deviceID;
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] intel: Add flags to intel_screen for hiz and separate stencil
Add the fields below to intel_screen. The expression in parens is the
value to which intelInitScreen2() currently sets the field.
GLboolean hw_has_separate_stencil (true iff gen >= 7)
GLboolean hw_must_use_separate_stencil (true iff gen >= 7)
GLboolean hw_has_hiz (always false)
enum intel_dri2_has_hiz dri2_has_hiz (INTEL_DRI2_HAS_HIZ_UNKNOWN)
The analogous fields in intel_context now inherit their values from
intel_screen.
When hiz and separate stencil become completely implemented for a given
chipset, then the respective fields need to be enabled.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c | 10 +---
src/mesa/drivers/dri/intel/intel_screen.c | 60
src/mesa/drivers/dri/intel/intel_screen.h | 10 +
3 files changed, 73 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 2ea52c2..7404016 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -714,14 +714,9 @@ intelInitContext(struct intel_context *intel,
if (IS_GEN7(intel->intelScreen->deviceID)) {
intel->needs_ff_sync = GL_TRUE;
intel->has_luminance_srgb = GL_TRUE;
- /* FINISHME: Enable intel->has_separate_stencil on Gen7. */
- /* FINISHME: Enable intel->must_use_separate_stencil on Gen7. */
- /* FINISHME: Enable intel->has_hiz on Gen7. */
} else if (IS_GEN6(intel->intelScreen->deviceID)) {
intel->needs_ff_sync = GL_TRUE;
intel->has_luminance_srgb = GL_TRUE;
- /* FINISHME: Enable intel->has_separate_stencil on Gen6. */
- /* FINISHME: Enable intel->has_hiz on Gen6. */
} else if (IS_GEN5(intel->intelScreen->deviceID)) {
intel->needs_ff_sync = GL_TRUE;
intel->has_luminance_srgb = GL_TRUE;
@@ -741,8 +736,9 @@ intelInitContext(struct intel_context *intel,
}
}
- intel_override_hiz(intel);
- intel_override_separate_stencil(intel);
+ intel->has_separate_stencil = intel->intelScreen->hw_has_separate_stencil;
+ intel->must_use_separate_stencil =
intel->intelScreen->hw_must_use_separate_stencil;
+ intel->has_hiz = intel->intelScreen->hw_has_hiz;
memset(&ctx->TextureFormatSupported, 0,
sizeof(ctx->TextureFormatSupported));
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index deca11d..646b960 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -507,6 +507,54 @@ intel_init_bufmgr(struct intel_screen *intelScreen)
}
/**
+ * Override intel_screen.hw_has_hiz with environment variable INTEL_HIZ.
+ *
+ * Valid values for INTEL_HIZ are "0" and "1". If an invalid valid value is
+ * encountered, a warning is emitted and INTEL_HIZ is ignored.
+ */
+static void
+intel_override_hiz(struct intel_screen *intel)
+{
+ const char *s = getenv("INTEL_HIZ");
+ if (!s) {
+ return;
+ } else if (!strncmp("0", s, 2)) {
+ intel->hw_has_hiz = false;
+ } else if (!strncmp("1", s, 2)) {
+ intel->hw_has_hiz = true;
+ } else {
+ fprintf(stderr,
+ "warning: env variable INTEL_HIZ=\"%s\" has invalid value "
+ "and is ignored", s);
+ }
+}
+
+/**
+ * Override intel_screen.hw_has_separate_stencil with environment variable
+ * INTEL_SEPARATE_STENCIL.
+ *
+ * Valid values for INTEL_SEPARATE_STENCIL are "0" and "1". If an invalid
+ * valid value is encountered, a warning is emitted and INTEL_SEPARATE_STENCIL
+ * is ignored.
+ */
+static void
+intel_override_separate_stencil(struct intel_screen *screen)
+{
+ const char *s = getenv("INTEL_SEPARATE_STENCIL");
+ if (!s) {
+ return;
+ } else if (!strncmp("0", s, 2)) {
+ screen->hw_has_separate_stencil = false;
+ } else if (!strncmp("1", s, 2)) {
+ screen->hw_has_separate_stencil = true;
+ } else {
+ fprintf(stderr,
+ "warning: env variable INTEL_SEPARATE_STENCIL=\"%s\" has "
+ "invalid value and is ignored", s);
+ }
+}
+
+/**
* This is the driver specific part of the createNewScreen entry point.
* Called when using DRI2.
*
@@ -570,6 +618,18 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
intelScreen->gen = 2;
}
+ /*
+* FIXME: The hiz and separate stencil fields need updating once the
+* FIXME: features are completely implemented for a given chipset.
+*/
+ intelScreen->hw_has_separate_stencil = intelScreen->gen >= 7;
+ intelScreen->hw_must_use_separate_stencil = intelScreen->gen >= 7;
+ intelScreen->hw_has_hiz = false;
+ intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_UNKNOWN;
+
+ intel_override_hiz(intelScreen);
+ intel_override_separate_stencil(intelScreen);
+
api_mask = (1 << __DRI_API_OPENGL);
#if FEATURE_ES1
api_mask |= (1 << __DRI_API_
[Mesa-dev] [PATCH 06/10] intel/intel_context.c: Remove unused functions
Remove functions intel_override_hiz() and
intel_override_separate_stencil(). They are now located in intel_screen.c.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c | 48
1 files changed, 0 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 7404016..8091d4f 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -620,54 +620,6 @@ intelInitDriverFunctions(struct dd_function_table
*functions)
intel_init_syncobj_functions(functions);
}
-/**
- * Override intel->has_hiz with environment variable INTEL_HIZ.
- *
- * Valid values for INTEL_HIZ are "0" and "1". If an invalid valid value is
- * encountered, a warning is emitted and INTEL_HIZ is ignored.
- */
-static void
-intel_override_hiz(struct intel_context *intel)
-{
- const char *s = getenv("INTEL_HIZ");
- if (!s) {
- return;
- } else if (!strncmp("0", s, 2)) {
- intel->has_hiz = false;
- } else if (!strncmp("1", s, 2)) {
- intel->has_hiz = true;
- } else {
- _mesa_warning(&intel->ctx,
-"env variable INTEL_HIZ=\"%s\" has invalid value and "
-"is ignored", s);
- }
-}
-
-/**
- * Override intel->has_separate_stencil with environment variable
- * INTEL_SEPARATE_STENCIL.
- *
- * Valid values for INTEL_SEPARATE_STENCIL are "0" and "1". If an invalid
- * value is encountered, a warning is emitted and INTEL_SEPARATE_STENCIL is
- * ignored.
- */
-static void
-intel_override_separate_stencil(struct intel_context *intel)
-{
- const char *s = getenv("INTEL_SEPARATE_STENCIL");
- if (!s) {
- return;
- } else if (!strncmp("0", s, 2)) {
- intel->has_separate_stencil = false;
- } else if (!strncmp("1", s, 2)) {
- intel->has_separate_stencil = true;
- } else {
- _mesa_warning(&intel->ctx,
-"env variable INTEL_SEPARATE_STENCIL=\"%s\" has invalid "
-"value and is ignored", s);
- }
-}
-
GLboolean
intelInitContext(struct intel_context *intel,
int api,
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] intel: Add function intel_renderbuffer_set_hiz_region()
It's the analog of intel_renderbuffer_set_region(), but for the hiz region
of course.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 12
src/mesa/drivers/dri/intel/intel_fbo.h |5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 7434e0e..83f622d 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -321,6 +321,18 @@ intel_renderbuffer_set_region(struct intel_context *intel,
}
+void
+intel_renderbuffer_set_hiz_region(struct intel_context *intel,
+ struct intel_renderbuffer *rb,
+ struct intel_region *region)
+{
+ struct intel_region *old = rb->hiz_region;
+ rb->hiz_region = NULL;
+ intel_region_reference(&rb->hiz_region, region);
+ intel_region_release(&old);
+}
+
+
/**
* Create a new intel_renderbuffer which corresponds to an on-screen window,
* not a user-created renderbuffer.
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.h
b/src/mesa/drivers/dri/intel/intel_fbo.h
index 212dd9a..e9929b0 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.h
+++ b/src/mesa/drivers/dri/intel/intel_fbo.h
@@ -113,6 +113,11 @@ intel_renderbuffer_set_region(struct intel_context *intel,
struct intel_renderbuffer *irb,
struct intel_region *region);
+extern void
+intel_renderbuffer_set_hiz_region(struct intel_context *intel,
+ struct intel_renderbuffer *rb,
+ struct intel_region *region);
+
extern struct intel_renderbuffer *
intel_create_renderbuffer(gl_format format);
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] intel: Refactor intel_update_renderbuffers()
Extract the code that queries DRI2 to obtain the DRIdrawable's buffers
into intel_query_dri2_buffers_no_separate_stencil().
Extract the code that assigns the DRI buffer's DRM region to the
corresponding renderbuffer into
intel_process_dri2_buffer_no_separate_stencil().
Rationale
-
The next commit enables intel_update_renderbuffers() to query for separate
stencil and hiz buffers. Without separating the separate-stencil and
no-separate-stencil paths, intel_update_renderbuffers() degenerates into
an impenetrable labyrinth of if-trees.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c | 323 ++--
1 files changed, 212 insertions(+), 111 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 8091d4f..3af96f5 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -227,18 +227,27 @@ intel_bits_per_pixel(const struct intel_renderbuffer *rb)
return _mesa_get_format_bytes(rb->Base.Format) * 8;
}
+static void
+intel_query_dri2_buffers_no_separate_stencil(struct intel_context *intel,
+__DRIdrawable *drawable,
+__DRIbuffer **buffers,
+int *count);
+
+static void
+intel_process_dri2_buffer_no_separate_stencil(struct intel_context *intel,
+ __DRIdrawable *drawable,
+ __DRIbuffer *buffer,
+ struct intel_renderbuffer *rb,
+ const char *buffer_name);
+
void
intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
{
struct gl_framebuffer *fb = drawable->driverPrivate;
struct intel_renderbuffer *rb;
- struct intel_region *region, *depth_region;
struct intel_context *intel = context->driverPrivate;
- struct intel_renderbuffer *front_rb, *back_rb, *depth_rb, *stencil_rb;
__DRIbuffer *buffers = NULL;
- __DRIscreen *screen;
int i, count;
- unsigned int attachments[10];
const char *region_name;
/* If we're rendering to the fake front buffer, make sure all the
@@ -260,70 +269,12 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
if (unlikely(INTEL_DEBUG & DEBUG_DRI))
fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
- screen = intel->intelScreen->driScrnPriv;
-
- if (screen->dri2.loader
- && (screen->dri2.loader->base.version > 2)
- && (screen->dri2.loader->getBuffersWithFormat != NULL)) {
-
- front_rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
- back_rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
- depth_rb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
- stencil_rb = intel_get_renderbuffer(fb, BUFFER_STENCIL);
-
- i = 0;
- if ((intel->is_front_buffer_rendering ||
- intel->is_front_buffer_reading ||
- !back_rb) && front_rb) {
-attachments[i++] = __DRI_BUFFER_FRONT_LEFT;
-attachments[i++] = intel_bits_per_pixel(front_rb);
- }
-
- if (back_rb) {
-attachments[i++] = __DRI_BUFFER_BACK_LEFT;
-attachments[i++] = intel_bits_per_pixel(back_rb);
- }
-
- if ((depth_rb != NULL) && (stencil_rb != NULL)) {
-attachments[i++] = __DRI_BUFFER_DEPTH_STENCIL;
-attachments[i++] = intel_bits_per_pixel(depth_rb);
- } else if (depth_rb != NULL) {
-attachments[i++] = __DRI_BUFFER_DEPTH;
-attachments[i++] = intel_bits_per_pixel(depth_rb);
- } else if (stencil_rb != NULL) {
-attachments[i++] = __DRI_BUFFER_STENCIL;
-attachments[i++] = intel_bits_per_pixel(stencil_rb);
- }
-
- buffers =
-(*screen->dri2.loader->getBuffersWithFormat)(drawable,
- &drawable->w,
- &drawable->h,
- attachments, i / 2,
- &count,
- drawable->loaderPrivate);
- } else if (screen->dri2.loader) {
- i = 0;
- if (intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT))
-attachments[i++] = __DRI_BUFFER_FRONT_LEFT;
- if (intel_get_renderbuffer(fb, BUFFER_BACK_LEFT))
-attachments[i++] = __DRI_BUFFER_BACK_LEFT;
- if (intel_get_renderbuffer(fb, BUFFER_DEPTH))
-attachments[i++] = __DRI_BUFFER_DEPTH;
- if (intel_get_renderbuffer(fb, BUFFER_STENCIL))
-attachments[i++] = __DRI_BUFFER_STENCIL;
-
- buffers = (*screen->dri2.loader->getBuffers)(drawable,
- &drawable->w,
-
[Mesa-dev] [PATCH 09/10] intel: Add assertions to intelCreateBuffer()
Assert that the GLX config has an expected depth/stencil bit combination:
one of d24/s8, d16/s0, d0/s0. These are the only depth/stencil
configurations that we advertise.
Remove the check for software stencil, because given the assertions'
constraints the check always fails.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_screen.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 646b960..21dc8dc 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -364,8 +364,6 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
return GL_FALSE; /* not implemented */
}
else {
- GLboolean swStencil = (mesaVis->stencilBits > 0 &&
- mesaVis->depthBits != 24);
gl_format rgbFormat;
struct gl_framebuffer *fb = CALLOC_STRUCT(gl_framebuffer);
@@ -391,6 +389,11 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
_mesa_add_renderbuffer(fb, BUFFER_BACK_LEFT, &rb->Base);
}
+ /*
+ * Assert here that the gl_config has an expected depth/stencil bit
+ * combination: one of d24/s8, d16/s0, d0/s0. (See intelInitScreen2(),
+ * which constructs the advertised configs.)
+ */
if (mesaVis->depthBits == 24) {
assert(mesaVis->stencilBits == 8);
/* combined depth/stencil buffer */
@@ -401,17 +404,23 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
_mesa_add_renderbuffer(fb, BUFFER_STENCIL, &depthStencilRb->Base);
}
else if (mesaVis->depthBits == 16) {
+assert(mesaVis->stencilBits == 0);
/* just 16-bit depth buffer, no hw stencil */
struct intel_renderbuffer *depthRb
= intel_create_renderbuffer(MESA_FORMAT_Z16);
_mesa_add_renderbuffer(fb, BUFFER_DEPTH, &depthRb->Base);
}
+ else {
+assert(mesaVis->depthBits == 0);
+assert(mesaVis->stencilBits == 0);
+ }
/* now add any/all software-based renderbuffers we may need */
_mesa_add_soft_renderbuffers(fb,
GL_FALSE, /* never sw color */
GL_FALSE, /* never sw depth */
- swStencil, mesaVis->accumRedBits > 0,
+ GL_FALSE, /* never sw stencil */
+ mesaVis->accumRedBits > 0,
GL_FALSE, /* never sw alpha */
GL_FALSE /* never sw aux */ );
driDrawPriv->driverPrivate = fb;
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] intel: Request DRI2 buffers for separate stencil and hiz
When it is sensible to do so,
1) intelCreateBuffer() now attaches separate depth and stencil
buffers
to the framebuffer it creates.
2) intel_update_renderbuffers() requests for the framebuffer
a separate stencil buffer (DRI2BufferStencil).
The criteria for "sensible" is:
- The GLX config has nonzero depth and stencil bits.
- The hardware supports separate stencil.
- The X driver supports separate stencil, or its support has not yet
been determined.
If the hardware supports hiz too, then intel_update_renderbuffers()
also requests DRI2BufferHiz.
If after requesting DRI2BufferStencil we determine that X driver did not
actually support separate stencil, we clean up the mistake and never ask
for DRI2BufferStencil again.
CC: Eric Anholt
CC: Ian Romanick
CC: Kenneth Graunke
CC: Kristian Høgsberg
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c | 429 +++-
src/mesa/drivers/dri/intel/intel_screen.c | 28 ++-
src/mesa/drivers/dri/intel/intel_screen.h |2 -
3 files changed, 445 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 3af96f5..109a77b 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -33,6 +33,7 @@
#include "main/framebuffer.h"
#include "main/imports.h"
#include "main/points.h"
+#include "main/renderbuffer.h"
#include "swrast/swrast.h"
#include "swrast_setup/swrast_setup.h"
@@ -240,6 +241,26 @@ intel_process_dri2_buffer_no_separate_stencil(struct
intel_context *intel,
struct intel_renderbuffer *rb,
const char *buffer_name);
+static void
+intel_query_dri2_buffers_with_separate_stencil(struct intel_context *intel,
+ __DRIdrawable *drawable,
+ __DRIbuffer **buffers,
+ unsigned **attachments,
+ int *count);
+
+static void
+intel_process_dri2_buffer_with_separate_stencil(struct intel_context *intel,
+ __DRIdrawable *drawable,
+ __DRIbuffer *buffer,
+ struct intel_renderbuffer *rb,
+ const char *buffer_name);
+static void
+intel_verify_dri2_has_hiz(struct intel_context *intel,
+ __DRIdrawable *drawable,
+ __DRIbuffer **buffers,
+ unsigned **attachments,
+ int *count);
+
void
intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
{
@@ -247,9 +268,20 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
struct intel_renderbuffer *rb;
struct intel_context *intel = context->driverPrivate;
__DRIbuffer *buffers = NULL;
+ unsigned *attachments = NULL;
int i, count;
const char *region_name;
+ bool try_separate_stencil =
+ intel->has_separate_stencil &&
+ intel->intelScreen->dri2_has_hiz != INTEL_DRI2_HAS_HIZ_FALSE &&
+ intel->intelScreen->driScrnPriv->dri2.loader != NULL &&
+ intel->intelScreen->driScrnPriv->dri2.loader->base.version > 2 &&
+ intel->intelScreen->driScrnPriv->dri2.loader->getBuffersWithFormat !=
NULL;
+
+ if (intel->must_use_separate_stencil && !try_separate_stencil)
+ return;
+
/* If we're rendering to the fake front buffer, make sure all the
* pending drawing has landed on the real front buffer. Otherwise
* when we eventually get to DRI2GetBuffersWithFormat the stale
@@ -269,12 +301,17 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
if (unlikely(INTEL_DEBUG & DEBUG_DRI))
fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
+ if (try_separate_stencil) {
+ intel_query_dri2_buffers_with_separate_stencil(intel, drawable, &buffers,
+&attachments, &count);
+ } else {
+ intel_query_dri2_buffers_no_separate_stencil(intel, drawable, &buffers,
+ &count);
+ }
+
if (buffers == NULL)
return;
- intel_query_dri2_buffers_no_separate_stencil(intel, drawable, &buffers,
- &count);
-
drawable->x = 0;
drawable->y = 0;
drawable->backX = 0;
@@ -312,6 +349,12 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
region_name = "dri2 depth buffer";
break;
+ case __DRI_BUFFER_HIZ:
+ /* The hiz region resides in the depth renderbuffer. */
+ rb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
+
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
2011/6/4 Christian König : > Am Samstag, den 04.06.2011, 15:20 -0400 schrieb Matt Turner: >> Is there a reason that this can't be merged to master? > Since float buffer support was merged to master I can't see any more > obstacles. Just gone over the branch one more time and fixed some > problem created by merging. > >> It seems like the longer it remains as a branch, the more mess there >> is going to be from merging master into pipe-video over and over >> again. > Merging with master is actually quite simple most of the time, but I > haven't tried the other way around jet. I mean more of -- go ahead and merge it into master so that git history doesn't have so many unnecessary 'merge master into pipe-video' commits in it. >> It won't hurt anyone to have it in master, so I think you should just >> go ahead and merge it. > Ok, If nobody objects till tomorrow evening I going to push it to > master. > >> I also don't think it's too late to wipe out the "Merge >> remote-tracking branch 'mareko/r300g-draw-instanced' into pipe-video" >> and subsequent revert from git. No one is basing their work on your >> branch. > Already reverted it. I meant actually wiping these two commits out from git history with a forced push. A few people were talking about this on IRC today. As no one is basing work on your branch, it seems like it'd be alright to do this. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function
On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote: > Le 03/06/2011 06:09, Matt Turner a écrit : >> Also, if you want to check if the value is already a power-of-two, >> instead of a case statement for every POT (including 0), just do the >> standard is-power-of-two check: >> >> (x & (x - 1)) == 0 > > My own tests (on a Core2) shows that it's less efficient to do that, at > least with -O2 optimization enabled. With -O0, it's equal. For what input set? Powers of two? Doesn't really matter, since the function isn't a hot path or anything, but I'd suppose that the Linux kernel has its is_power_of_2() function for a reason--that it's pretty ugly to have lots of case statements like powers of two. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
I think we need to have a proper review round of the gallium interfaces, so
that we have an interface everybody feels that we can support going forward,
which did not happen last round.
That said, I don't think much attention has been given to this branch outside
from those working on it. So those with constructive feedback should say now,
or "forever hold your peace". Because one way or the other, it doesn't make
sense to have useful code on a branch.
Attached is the diff between pipe-video and master for src/gallium/include/*
I need to look more closely at this, but I can't help thinking that the new
interfaces are quite different from the rest of gallium's 3d interfaces.
Instead of being an extension to gallium 3D interfaces/objects, pipe-video
seems more like a completely parallel set of interfaces/objects.
- AFACIT all drivers implement pipe_video context using
vl_create_context(pipe_context *). If so then it makes no sense for this to be
a gallium interface. It should all be state tracker code.
At very least there are ovious things that need to be fixed:
- get_param / is_format_supported should not be duplicated from screen.
- #if 0 ... #endif code in the interface headers
I'd also would like to see how generic these interfaces are (e.g. could we use
this to implement DXVA DDI).
Jose
- Original Message -
> Am Samstag, den 04.06.2011, 15:20 -0400 schrieb Matt Turner:
> > Is there a reason that this can't be merged to master?
> Since float buffer support was merged to master I can't see any more
> obstacles. Just gone over the branch one more time and fixed some
> problem created by merging.
>
> > It seems like the longer it remains as a branch, the more mess
> > there
> > is going to be from merging master into pipe-video over and over
> > again.
> Merging with master is actually quite simple most of the time, but I
> haven't tried the other way around jet.
>
> > It won't hurt anyone to have it in master, so I think you should
> > just
> > go ahead and merge it.
> Ok, If nobody objects till tomorrow evening I going to push it to
> master.
>
> > I also don't think it's too late to wipe out the "Merge
> > remote-tracking branch 'mareko/r300g-draw-instanced' into
> > pipe-video"
> > and subsequent revert from git. No one is basing their work on your
> > branch.
> Already reverted it.
>
> Thanks,
> Christian.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
index c0c2a7c..6c66415 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -494,6 +494,39 @@ enum pipe_shader_cap
};
+enum pipe_video_codec
+{
+ PIPE_VIDEO_CODEC_UNKNOWN = 0,
+ PIPE_VIDEO_CODEC_MPEG12, /**< MPEG1, MPEG2 */
+ PIPE_VIDEO_CODEC_MPEG4,/**< DIVX, XVID */
+ PIPE_VIDEO_CODEC_VC1, /**< WMV */
+ PIPE_VIDEO_CODEC_MPEG4_AVC /**< H.264 */
+};
+
+enum pipe_video_profile
+{
+ PIPE_VIDEO_PROFILE_UNKNOWN,
+ PIPE_VIDEO_PROFILE_MPEG1,
+ PIPE_VIDEO_PROFILE_MPEG2_SIMPLE,
+ PIPE_VIDEO_PROFILE_MPEG2_MAIN,
+ PIPE_VIDEO_PROFILE_MPEG4_SIMPLE,
+ PIPE_VIDEO_PROFILE_MPEG4_ADVANCED_SIMPLE,
+ PIPE_VIDEO_PROFILE_VC1_SIMPLE,
+ PIPE_VIDEO_PROFILE_VC1_MAIN,
+ PIPE_VIDEO_PROFILE_VC1_ADVANCED,
+ PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE,
+ PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN,
+ PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH
+};
+
+enum pipe_video_entrypoint
+{
+ PIPE_VIDEO_ENTRYPOINT_UNKNOWN,
+ PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+ PIPE_VIDEO_ENTRYPOINT_IDCT,
+ PIPE_VIDEO_ENTRYPOINT_MC
+};
+
/**
* Composite query types
*/
@@ -508,6 +541,7 @@ struct pipe_query_data_timestamp_disjoint
boolean disjoint;
};
+
#ifdef __cplusplus
}
#endif
diff --git a/src/gallium/include/pipe/p_format.h b/src/gallium/include/pipe/p_format.h
index 690e934..c9f75c0 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -229,9 +229,27 @@ enum pipe_format {
PIPE_FORMAT_L32A32_FLOAT= 161,
PIPE_FORMAT_I32_FLOAT = 162,
+ PIPE_FORMAT_YV12= 163,
+ PIPE_FORMAT_YV16= 164,
+ PIPE_FORMAT_IYUV= 165, /**< aka I420 */
+ PIPE_FORMAT_NV12= 166,
+ PIPE_FORMAT_NV21= 167,
+ PIPE_FORMAT_AYUV= PIPE_FORMAT_A8R8G8B8_UNORM,
+ PIPE_FORMAT_VUYA= PIPE_FORMAT_B8G8R8A8_UNORM,
+ PIPE_FORMAT_XYUV= PIPE_FORMAT_X8R8G8B8_UNORM,
+ PIPE_FORMAT_VUYX= PIPE_FORMAT_B8G8R8X8_UNORM,
+ PIPE_FORMAT_IA44= 168,
+ PIPE_FORMAT_AI44= 169,
+
PIPE_FORMAT_COUNT
};
+enum pipe_video_chroma_format
+{
+ PIPE_VIDEO_CHROMA_FORMAT_420,
+ PIPE_VIDEO_CHROMA_FORMAT_422,
+ PIPE_VIDEO_CHROMA_FORMAT_444
Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function
Le 05/06/2011 03:05, Matt Turner a écrit :
> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote:
>> Le 03/06/2011 06:09, Matt Turner a écrit :
>>> Also, if you want to check if the value is already a power-of-two,
>>> instead of a case statement for every POT (including 0), just do the
>>> standard is-power-of-two check:
>>>
>>> (x & (x - 1)) == 0
>>
>> My own tests (on a Core2) shows that it's less efficient to do that, at
>> least with -O2 optimization enabled. With -O0, it's equal.
>
> For what input set? Powers of two?
Both, my test case loops with 29 POT and 6 NPOT.
I'm doing this because the OpenGL games that I have tested call the
function more often with "good" values.
>
> Doesn't really matter, since the function isn't a hot path or
> anything, but I'd suppose that the Linux kernel has its
> is_power_of_2() function for a reason--that it's pretty ugly to have
> lots of case statements like powers of two.
>
> Matt
Ok, so here is a v3 patch which replace the switch statement.
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..f37d9cc 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -493,17 +493,30 @@ util_logbase2(unsigned n)
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
+#if defined(PIPE_CC_GCC)
+ if (x == 0)
+ return 1;
+ else
+ return (1 << (32 - __builtin_clz(x - 1)));
+#else
+ unsigned val = x;
if (x == 0)
return 1;
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ /* check if x is already a power of two */
+ if ((x & (x - 1)) == 0)
+ return x;
+
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ val++;
+ return val;
+#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
2011/6/4 Jose Fonseca : > I think we need to have a proper review round of the gallium interfaces, so > that we have an interface everybody feels that we can support going forward, > which did not happen last round. > > That said, I don't think much attention has been given to this branch outside > from those working on it. So those with constructive feedback should say now, > or "forever hold your peace". Because one way or the other, it doesn't make > sense to have useful code on a branch. > > Attached is the diff between pipe-video and master for src/gallium/include/* > > I need to look more closely at this, but I can't help thinking that the new > interfaces are quite different from the rest of gallium's 3d interfaces. > Instead of being an extension to gallium 3D interfaces/objects, pipe-video > seems more like a completely parallel set of interfaces/objects. > > - AFACIT all drivers implement pipe_video context using > vl_create_context(pipe_context *). If so then it makes no sense for this to > be a gallium interface. It should all be state tracker code. This is deliberate. All current drivers implement their decoding in terms of 3D rendering but any driver wanting to implement decoding via dedicated hardware or other means will implement the interface directly. That was the motivation for the pipe_video interface, for drivers to have a suitable first-class interface that wasn't specific to any one decoding method and for drivers wanting to implement 3D decoding specifically to be able to share and reuse various modules that carry out parts of the decoding pipeline via pipe_context. > > At very least there are ovious things that need to be fixed: > > - get_param / is_format_supported should not be duplicated from screen. This is also deliberate. Params and surface formats may depend on the codec/profile/dimensions of the video stream the context was created to decode. There is not always enough info available in pipe_screen alone to determine if a particular cap or surface is supported. The current implementation largely wraps pipe_screen because again it's using the 3D pipeline and we don't have to deal with funny decoding hardware constraints. I haven't kept up with all of the changes Christian has made and I'm not going to claim the interface as I left it or as it is now is perfect, but as of now it works on Radeon and semi-works on Nouveau (for lack of a maintainer) and supports XvMC and VDPAU. The only thing missing is hardware decoding, which I'm sure will require some changes, but seeing as how both Radeon and Nvidia decoding hardware need to be reverse-engineered we can't predict what a perfectly suitable interface will look like. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
