Re: [Mesa-dev] Adding support for sRGB framebuffers to EGL

2012-09-26 Thread John Kåre Alsaker 
The way this would interact with ARB_framebuffer_sRGB is that the
EGL's surface EGL_GAMMA attribute would be ignored. If a EGL config
has the EGL_GAMMA_SRGB_BIT, it is required to support sRGB for the
default OpenGL framebuffer.

On Tue, Sep 25, 2012 at 5:58 PM, John Kåre Alsaker
 wrote:
> Hello,
>
> I would like add support for sRGB framebuffers to EGL. Here are my
> proposed changes to EGL:
>
> A new EGL_SURFACE_TYPE bit:
> EGL_GAMMA_SRGB_BIT - This format supports sRGB framebuffers. This also
> means that ARB_framebuffer_sRGB is supported for this format.
>
> New values:
> EGL_GAMMA_LINEAR - The gamma is linear.
> EGL_GAMMA_SRGB - The gamma is as defined by the sRGB standard.
>
> New EGL surface attribute:
> EGL_GAMMA - The gamma of the surface's framebuffer. The default value
> is EGL_GAMMA_LINEAR.
>
> When the surface's EGL_GAMMA attribute's value is EGL_GAMMA_SRGB and
> this is supported by
> the format, reads from this framebuffer will be converted from sRGB
> gamma and writes will
> be converted to sRGB gamma. This may not apply to all functions in the
> client API.
>
> There may be something related to the ARB_framebuffer_sRGB extension
> in EGL already, in
> which case someone should link me to it.
>
> There's two assumptions behind this proposal. One is that you won't
> support sRGB only
> formats. The other is that linear gamma and sRGB gamma format support
> is the same.
> This means that window systems can't add a new linear gamma format
> without adding an sRGB
> format and the other way around.
>
> I'd like some comments on this proposal and tips on how it could be
> implemented in the
> mess that is DRI.
>
> Thanks,
> John Kåre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Adding support for sRGB framebuffers to EGL

2012-09-26 Thread John Kåre Alsaker 
EGL_GAMMA_SRGB_BIT should be changed to a boolean EGL config attribute
so it can be optionally sorted by eglChooseConfig. It should be sorted
after EGL_COLOR_BUFFER_TYPE and true values would be preferred. This
sorting should be optional and is done so compositing window managers
can sample the framebuffer as an sRGB texture. EGL_GAMMA_SRGB_BIT
could also optionally be disabled when the format is not supported as
an sRGB texture by the hardware.

On Wed, Sep 26, 2012 at 10:19 AM, John Kåre Alsaker
 wrote:
> The way this would interact with ARB_framebuffer_sRGB is that the
> EGL's surface EGL_GAMMA attribute would be ignored. If a EGL config
> has the EGL_GAMMA_SRGB_BIT, it is required to support sRGB for the
> default OpenGL framebuffer.
>
> On Tue, Sep 25, 2012 at 5:58 PM, John Kåre Alsaker
>  wrote:
>> Hello,
>>
>> I would like add support for sRGB framebuffers to EGL. Here are my
>> proposed changes to EGL:
>>
>> A new EGL_SURFACE_TYPE bit:
>> EGL_GAMMA_SRGB_BIT - This format supports sRGB framebuffers. This also
>> means that ARB_framebuffer_sRGB is supported for this format.
>>
>> New values:
>> EGL_GAMMA_LINEAR - The gamma is linear.
>> EGL_GAMMA_SRGB - The gamma is as defined by the sRGB standard.
>>
>> New EGL surface attribute:
>> EGL_GAMMA - The gamma of the surface's framebuffer. The default value
>> is EGL_GAMMA_LINEAR.
>>
>> When the surface's EGL_GAMMA attribute's value is EGL_GAMMA_SRGB and
>> this is supported by
>> the format, reads from this framebuffer will be converted from sRGB
>> gamma and writes will
>> be converted to sRGB gamma. This may not apply to all functions in the
>> client API.
>>
>> There may be something related to the ARB_framebuffer_sRGB extension
>> in EGL already, in
>> which case someone should link me to it.
>>
>> There's two assumptions behind this proposal. One is that you won't
>> support sRGB only
>> formats. The other is that linear gamma and sRGB gamma format support
>> is the same.
>> This means that window systems can't add a new linear gamma format
>> without adding an sRGB
>> format and the other way around.
>>
>> I'd like some comments on this proposal and tips on how it could be
>> implemented in the
>> mess that is DRI.
>>
>> Thanks,
>> John Kåre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 55352] New: new account request for freedesktop.org - abdiel janulgue

2012-09-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55352

  Priority: medium
Bug ID: 55352
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: new account request for freedesktop.org - abdiel
janulgue
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: xynop...@gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Other
   Product: Mesa

Created attachment 67714
  --> https://bugs.freedesktop.org/attachment.cgi?id=67714&action=edit
ssh public key

I just started working for Intel OTC visualization group and will be working on
the linux graphics stack. I would like to request a freedesktop account for
Mesa.

Real Name: Abdiel Janulgue
Email: abdiel.janul...@linux.intel.com

Cheers,
Abdiel

-- 
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

[Mesa-dev] [Bug 55352] new account request for freedesktop.org - abdiel janulgue

2012-09-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55352

--- Comment #1 from Abdiel Janulgue  ---
Created attachment 67715
  --> https://bugs.freedesktop.org/attachment.cgi?id=67715&action=edit
gpg public key

-- 
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

[Mesa-dev] [Bug 55352] new account request for freedesktop.org - abdiel janulgue

2012-09-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55352

--- Comment #2 from Abdiel Janulgue  ---
preferred account name: abj

-- 
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

[Mesa-dev] [Bug 55352] new account request for freedesktop.org - abdiel janulgue

2012-09-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55352

Brian Paul  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes
   |org |ktop.org
Product|Mesa|freedesktop.org
  Component|Other   |New Accounts

--- Comment #3 from Brian Paul  ---
Normally we look for some history of submitting (good) patches to the mesa-dev
list before giving a fd.o account.  But I'll assume you'll post your patches
for review before pushing.

Reassigning to admins...

-- 
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

[Mesa-dev] [Bug 40611] piglit 17000-consecutive-chars-identifier SIGSEGV

2012-09-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40611

Ian Romanick  changed:

   What|Removed |Added

 CC||jlp.b...@gmail.com

--- Comment #2 from Ian Romanick  ---
*** Bug 55219 has been marked as a duplicate of this bug. ***

-- 
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 06/19] glx: Unifdef some dri_interface.h defines.

2012-09-26 Thread Kristian Høgsberg 
On Tue, Sep 25, 2012 at 10:50 PM, Eric Anholt  wrote:
> dri_interface.h comes from our tree, so why litter our tree with ifdefs for
> older versions of it?

Yeah, lets get rid of those, it's a bad habit carried over form the aiglx code.

Reviewed-by: Kristian Høgsberg 

> I left in the DRI_TEX_BUFFER_VERSION ifdefs, which is broken and uncompiled
> (the version wasn't bumped from 2 to 3 when the patch was landed), but I don't
> know what should be done with it.
> ---
>  src/glx/dri2_glx.c |   15 +--
>  1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
> index f2fc187..ff5373c 100644
> --- a/src/glx/dri2_glx.c
> +++ b/src/glx/dri2_glx.c
> @@ -511,10 +511,8 @@ __dri2CopySubBuffer(__GLXDRIdrawable *pdraw, int x, int 
> y,
> xrect.width = width;
> xrect.height = height;
>
> -#ifdef __DRI2_FLUSH
> if (psc->f)
>(*psc->f->flush) (priv->driDrawable);
> -#endif
>
> dri2Throttle(psc, priv, reason);
>
> @@ -553,10 +551,8 @@ dri2_copy_drawable(struct dri2_drawable *priv, int dest, 
> int src)
> xrect.width = priv->width;
> xrect.height = priv->height;
>
> -#ifdef __DRI2_FLUSH
> if (psc->f)
>(*psc->f->flush) (priv->driDrawable);
> -#endif
>
> region = XFixesCreateRegion(psc->base.dpy, &xrect, 1);
> DRI2CopyRegion(psc->base.dpy, priv->base.xDrawable, region, dest, src);
> @@ -714,7 +710,6 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t 
> target_msc, int64_t divisor,
>__DRI2_THROTTLE_SWAPBUFFER);
>  } else {
>  #ifdef X_DRI2SwapBuffers
> -#ifdef __DRI2_FLUSH
>  if (psc->f) {
> struct glx_context *gc = __glXGetCurrentContext();
>
> @@ -722,7 +717,6 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t 
> target_msc, int64_t divisor,
>   (*psc->f->flush)(priv->driDrawable);
> }
>  }
> -#endif
>
> dri2Throttle(psc, priv, __DRI2_THROTTLE_SWAPBUFFER);
>
> @@ -844,11 +838,9 @@ static const __DRIdri2LoaderExtension 
> dri2LoaderExtension_old = {
> NULL,
>  };
>
> -#ifdef __DRI_USE_INVALIDATE
>  static const __DRIuseInvalidateExtension dri2UseInvalidate = {
> { __DRI_USE_INVALIDATE, __DRI_USE_INVALIDATE_VERSION }
>  };
> -#endif
>
>  _X_HIDDEN void
>  dri2InvalidateBuffers(Display *dpy, XID drawable)
> @@ -863,10 +855,8 @@ dri2InvalidateBuffers(Display *dpy, XID drawable)
>
> psc = (struct dri2_screen *) pdraw->psc;
>
> -#if __DRI2_FLUSH_VERSION >= 3
> if (pdraw && psc->f && psc->f->base.version >= 3 && psc->f->invalidate)
> psc->f->invalidate(pdp->driDrawable);
> -#endif
>  }
>
>  static void
> @@ -886,11 +876,9 @@ dri2_bind_tex_image(Display * dpy,
> if (pdraw != NULL) {
>psc = (struct dri2_screen *) base->psc;
>
> -#if __DRI2_FLUSH_VERSION >= 3
>if (!pdp->invalidateAvailable && psc->f &&
> psc->f->base.version >= 3 && psc->f->invalidate)
>  psc->f->invalidate(pdraw->driDrawable);
> -#endif
>
>if (psc->texBuffer->base.version >= 2 &&
>   psc->texBuffer->setTexBuffer2 != NULL) {
> @@ -1240,9 +1228,8 @@ dri2CreateDisplay(Display * dpy)
>
> pdp->loader_extensions[i++] = &systemTimeExtension.base;
>
> -#ifdef __DRI_USE_INVALIDATE
> pdp->loader_extensions[i++] = &dri2UseInvalidate.base;
> -#endif
> +
> pdp->loader_extensions[i++] = NULL;
>
> pdp->dri2Hash = __glxHashCreate();
> --
> 1.7.10.4
>
> ___
> 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] radeon/llvm: improve select_cc lowering to generate CND* more often

2012-09-26 Thread Tom Stellard 
On Tue, Sep 25, 2012 at 11:45:37PM +0200, Vincent Lejeune wrote:
> ---
>  src/gallium/drivers/radeon/R600ISelLowering.cpp| 90 
> +-
>  src/gallium/drivers/radeon/R600ISelLowering.h  |  3 +
>  src/gallium/drivers/radeon/R600Instructions.td | 38 +++--
>  .../drivers/radeon/radeon_setup_tgsi_llvm.c| 17 +++-
>  4 files changed, 104 insertions(+), 44 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeon/R600ISelLowering.cpp 
> b/src/gallium/drivers/radeon/R600ISelLowering.cpp
> index 379bd48..d52762b 100644
> --- a/src/gallium/drivers/radeon/R600ISelLowering.cpp
> +++ b/src/gallium/drivers/radeon/R600ISelLowering.cpp
> @@ -507,6 +507,17 @@ SDValue R600TargetLowering::LowerROTL(SDValue Op, 
> SelectionDAG &DAG) const
>   Op.getOperand(1)));
>  }
>  
> +bool R600TargetLowering::isZero(SDValue Op) const
> +{
> +  if(ConstantSDNode *Cst = dyn_cast(Op)) {
> +return !(Cst->getZExtValue());
> +  } else if(ConstantFPSDNode *CstFP = dyn_cast(Op)){
> +return CstFP->isExactlyValue(0.0f);
> +  } else {
> +return false;
> +  }
> +}
> +

You can simplify this function by using ConstantSDNode::isNullValue().

>  SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, SelectionDAG &DAG) 
> const
>  {
>DebugLoc DL = Op.getDebugLoc();
> @@ -517,7 +528,6 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, 
> SelectionDAG &DAG) const
>SDValue True = Op.getOperand(2);
>SDValue False = Op.getOperand(3);
>SDValue CC = Op.getOperand(4);
> -  ISD::CondCode CCOpcode = cast(CC)->get();
>SDValue Temp;
>  
>// LHS and RHS are guaranteed to be the same value type
> @@ -560,47 +570,58 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, 
> SelectionDAG &DAG) const
>if (isHWTrueValue(False) && isHWFalseValue(True)) {
>}
>  
> -  // XXX Check if we can lower this to a SELECT or if it is supported by a 
> native
> -  // operation. (The code below does this but we don't have the Instruction
> -  // selection patterns to do this yet.
> -#if 0
> +  // Check if we can lower this to a native operation.
> +  // CND* instructions requires all operands to have the same type, 
> +  // and RHS to be zero.
> +
>if (isZero(LHS) || isZero(RHS)) {
>  SDValue Cond = (isZero(LHS) ? RHS : LHS);
> -bool SwapTF = false;
> +SDValue Zero = (isZero(LHS) ? LHS : RHS);
> +ISD::CondCode CCOpcode = cast(CC)->get();
> +if (CompareVT != VT) {
> +  True = DAG.getNode(ISD::BITCAST, DL, CompareVT, True);
> +  False = DAG.getNode(ISD::BITCAST, DL, CompareVT, False);
> +}
> +if (isZero(LHS)) {
> +  CCOpcode = ISD::getSetCCSwappedOperands(CCOpcode);
> +}
> +
>  switch (CCOpcode) {
> -case ISD::SETOEQ:
 -case ISD::SETUEQ:
> -case ISD::SETEQ:
> -  SwapTF = true;
> -  // Fall through
>  case ISD::SETONE:
>  case ISD::SETUNE:
>  case ISD::SETNE:
> -  // We can lower to select
> -  if (SwapTF) {
> -Temp = True;
> -True = False;
> -False = Temp;
> -  }
> -  // CNDE
> -  return DAG.getNode(ISD::SELECT, DL, VT, Cond, True, False);
> +case ISD::SETULE:
> +case ISD::SETULT:
> +case ISD::SETOLE:
> +case ISD::SETOLT:
> +case ISD::SETLE:
> +case ISD::SETLT:
> +  CCOpcode = ISD::getSetCCInverse(CCOpcode, CompareVT == MVT::i32);
> +  Temp = True;
> +  True = False;
> +  False = Temp;
> +  break;
>  default:
> -  // Supported by a native operation (CNDGE, CNDGT)
> -  return DAG.getNode(ISD::SELECT_CC, DL, VT, LHS, RHS, True, False, CC);
> +  break;
>  }
> +SDValue SelectNode = DAG.getNode(ISD::SELECT_CC, DL, CompareVT,
> +Cond, Zero, 
> +True, False, 
> +DAG.getCondCode(CCOpcode));
> +return DAG.getNode(ISD::BITCAST, DL, VT, SelectNode);
>}
> -#endif
> +
>  
>// If we make it this for it means we have no native instructions to handle
>// this SELECT_CC, so we must lower it.
>SDValue HWTrue, HWFalse;
>  
> -  if (VT == MVT::f32) {
> -HWTrue = DAG.getConstantFP(1.0f, VT);
> -HWFalse = DAG.getConstantFP(0.0f, VT);
> -  } else if (VT == MVT::i32) {
> -HWTrue = DAG.getConstant(-1, VT);
> -HWFalse = DAG.getConstant(0, VT);
> +  if (CompareVT == MVT::f32) {
> +HWTrue = DAG.getConstantFP(1.0f, CompareVT);
> +HWFalse = DAG.getConstantFP(0.0f, CompareVT);
> +  } else if (CompareVT == MVT::i32) {
> +HWTrue = DAG.getConstant(-1, CompareVT);
> +HWFalse = DAG.getConstant(0, CompareVT);
>}
>else {
>  assert(!"Unhandled value type in LowerSELECT_CC");
> @@ -608,15 +629,12 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, 
> SelectionDAG &DAG) const
>  
>// Lower this unsupported SELECT_CC into a combination of two supported
>// SELECT_CC operations.
> -  SDValue Cond = DAG.getNode(ISD::SELECT_CC, DL, VT, LHS, RHS, HWTrue, 
> HWFalse, CC);
> -
> -  // Convert floating point condition

[Mesa-dev] [PATCH 1/2] i965: Don't leave dangling pointer to brw context on failure

2012-09-26 Thread Ian Romanick 
From: Ian Romanick 

Otherwise intelDestroyContext would try to dereference the pointer to
freed memory.

v2: Don't call intelDestroyContext if the context already freed due to
failure.

NOTE: This is a candidate for the 9.0 branch.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54301
---
 src/mesa/drivers/dri/i965/brw_context.c   | 1 +
 src/mesa/drivers/dri/intel/intel_screen.c | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 1083e28..60b6454 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -149,6 +149,7 @@ brwCreateContext(int api,
  sharedContextPrivate, &functions )) {
   printf("%s: failed to init intel context\n", __FUNCTION__);
   free(brw);
+  driContextPriv->driverPrivate = NULL;
   *error = __DRI_CTX_ERROR_NO_MEMORY;
   return false;
}
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index e3a442c..6ae78d2 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -821,7 +821,9 @@ intelCreateContext(gl_api api,
if (success)
   return true;
 
-   intelDestroyContext(driContextPriv);
+   if (driContextPriv->driverPrivate != NULL)
+  intelDestroyContext(driContextPriv);
+
return false;
 }
 
-- 
1.7.11.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] dri_util: Use calloc to allocate __DRIcontext

2012-09-26 Thread Ian Romanick 
From: Ian Romanick 

The __DRIcontext contains some pointers, and some drivers check for them to be
NULL in some failure paths.  Instead of sprinkling NULL assignments across the
various drivers, just zero out the whole thing.

NOTE: This is a candidate for the 9.0 branch.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54301
---
 src/mesa/drivers/dri/common/dri_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index 4276ad9..983bbea 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -272,7 +272,7 @@ dri2CreateContextAttribs(__DRIscreen *screen, int api,
return NULL;
 }
 
-context = malloc(sizeof *context);
+context = calloc(1, sizeof *context);
 if (!context) {
*error = __DRI_CTX_ERROR_NO_MEMORY;
return NULL;
-- 
1.7.11.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: Fix segfault in intel_texsubimage_tiled_memcpy

2012-09-26 Thread Chad Versace 
The function segfaulted when a game called glTexSubImage2D on a texture
with internalformat/format/type = GL_SLUMINANCE8/GL_BGRA/GL_UNSIGNED_BYTE.

The function only supports MESA_FORMAT_ARGB and returns early if it
detects an unsupported format. Clearly, its detection condition was
insufficient. This patch fixes it to explicity check for
MESA_FORMAT_ARGB.

CC: Kenneth Graunke 
Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_tex_subimage.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_tex_subimage.c 
b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
index d3a8736..aa6f237 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
@@ -199,8 +199,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 * varying the arithmetic loop below.
 */
if (!intel->has_llc ||
-   format != GL_BGRA ||
-   type != GL_UNSIGNED_BYTE ||
+   texImage->TexFormat != MESA_FORMAT_ARGB ||
texImage->TexObject->Target != GL_TEXTURE_2D ||
texImage->Level != 0 ||
pixels == NULL ||
-- 
1.7.12.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Eric Anholt 
Matt Turner  writes:

> On Tue, Sep 25, 2012 at 10:56 AM, Marcin Slusarz
>  wrote:
>> On Tue, Sep 25, 2012 at 10:38:31AM -0700, Matt Turner wrote:
>>> On Tue, Sep 25, 2012 at 10:31 AM, Marcin Slusarz
>>>  wrote:
>>> >> Installation is part of the testing procedure, after all.
>>> >
>>> > No. People test code, not build systems.
>>>
>>> I invite you to reread the subject of this email.
>>
>> So you do not intend to merge this branch to master? I'm fine with that ;)
>>
>> If you'll merge it, it will break testing for all of us, who used to
>> test mesa without installing.
>
> You can simply set LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH (like you
> were already doing before) to the directories where your libGL and
> driver are.

Except if you're doing libdricore/shared-glapi, in which case rpath
screws you if you've ever done make install.  A more thorough solution
if you really hate make install is probably to install links going back
to your build tree.


pgp26dLCsMZE5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/10] i965: Reduce maximum GL_ARB_fragment_program instruction count to 1024.

2012-09-26 Thread Ian Romanick 

On 09/24/2012 12:06 PM, Kenneth Graunke wrote:

On 09/22/2012 02:04 PM, Eric Anholt wrote:

I don't know of any programs that would need more than this.  The larger
programs I've seen have neared 100 instructions.  This prevent excessive
runtimes of automatic tests that attempt to test up to the exposed maximums
(like fp-long-alu).
---
  src/mesa/drivers/dri/i965/brw_context.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 1083e28..a7d61bd 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -250,10 +250,10 @@ brwCreateContext(int api,
MIN2(ctx->Const.VertexProgram.MaxNativeParameters,
   ctx->Const.VertexProgram.MaxEnvParams);

-   ctx->Const.FragmentProgram.MaxNativeInstructions = (16 * 1024);
-   ctx->Const.FragmentProgram.MaxNativeAluInstructions = (16 * 1024);
-   ctx->Const.FragmentProgram.MaxNativeTexInstructions = (16 * 1024);
-   ctx->Const.FragmentProgram.MaxNativeTexIndirections = (16 * 1024);
+   ctx->Const.FragmentProgram.MaxNativeInstructions = (1 * 1024);
+   ctx->Const.FragmentProgram.MaxNativeAluInstructions = (1 * 1024);
+   ctx->Const.FragmentProgram.MaxNativeTexInstructions = (1 * 1024);
+   ctx->Const.FragmentProgram.MaxNativeTexIndirections = (1 * 1024);
 ctx->Const.FragmentProgram.MaxNativeAttribs = 12;
 ctx->Const.FragmentProgram.MaxNativeTemps = 256;
 ctx->Const.FragmentProgram.MaxNativeAddressRegs = 0;


I've definitely seen 600 instruction shaders generated by Cg.  (Some
Crystal Space based games use shaders written in Cg, which translates to
stellar ARBfp code...)  I'm afraid there may be even bigger ones.


Maybe make it a driconf option?  That way if someone has an app that 
needs more, they can set it.  *shrug*


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Refactor texture swizzle generation into a helper.

2012-09-26 Thread Eric Anholt 
Kenneth Graunke  writes:
> It's going to be reused in a second place soon.

Series:

Reviewed-by: Eric Anholt 


pgp8q2xvgUdiK.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeon/llvm: improve select_cc lowering to generate CND* more often

2012-09-26 Thread Tom Stellard 
> > diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
> > b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> > index 04469e2..bb37154 100644
> > --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> > +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> > @@ -934,6 +934,20 @@ static void emit_u2f(
> > emit_data->args[0], bld_base->base.elem_type, "");
> >  }
> >  
> > +static void emit_cndlt(
> > +   const struct lp_build_tgsi_action * action,
> > +   struct lp_build_tgsi_context * bld_base,
> > +   struct lp_build_emit_data * emit_data)
> > +{
> > +   LLVMBuilderRef builder = bld_base->base.gallivm->builder;
> > +   LLVMValueRef float_zero = lp_build_const_float(
> > +   bld_base->base.gallivm, 0.0f);
> > +   LLVMValueRef cmp = LLVMBuildFCmp(
> > +   builder, LLVMRealULT, emit_data->args[0], float_zero, "");
> > +   emit_data->output[emit_data->chan] = LLVMBuildSelect(builder,
> > +   cmp, emit_data->args[1], emit_data->args[2], "");
> > +}
> > +
> >  static void emit_immediate(struct lp_build_tgsi_context * bld_base,
> > const struct tgsi_full_immediate *imm)
> >  {
> > @@ -1115,8 +1129,7 @@ void radeon_llvm_context_init(struct 
> > radeon_llvm_context * ctx)
> > bld_base->op_actions[TGSI_OPCODE_CONT].emit = cont_emit;
> > bld_base->op_actions[TGSI_OPCODE_CLAMP].emit = 
> > build_tgsi_intrinsic_nomem;
> > bld_base->op_actions[TGSI_OPCODE_CLAMP].intr_name = "llvm.AMDIL.clamp.";
> > -   bld_base->op_actions[TGSI_OPCODE_CMP].emit = build_tgsi_intrinsic_nomem;
> > -   bld_base->op_actions[TGSI_OPCODE_CMP].intr_name = "llvm.AMDGPU.cndlt";
> > +   bld_base->op_actions[TGSI_OPCODE_CMP].emit = emit_cndlt;
> > bld_base->op_actions[TGSI_OPCODE_COS].emit = build_tgsi_intrinsic_nomem;
> > bld_base->op_actions[TGSI_OPCODE_COS].intr_name = "llvm.AMDGPU.cos";
> > bld_base->op_actions[TGSI_OPCODE_DIV].emit = build_tgsi_intrinsic_nomem;
> 
> It would be nice if you could also remove the llvm.AMDGPU.cndlt
> intrinsic and also delete the SI pseudo instruction that uses it.  I can
> test on SI for you.
>

Unfortunately, removing this intrinsic from SI uncovers a bug that may
be difficult to solve, so for now just leave the intrinsic, so SI can
use it.

-Tom
> 
> > -- 
> > 1.7.11.4
> > 
> > ___
> > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Fix segfault in intel_texsubimage_tiled_memcpy

2012-09-26 Thread Paul Berry 
On 26 September 2012 11:22, Chad Versace wrote:

> The function segfaulted when a game called glTexSubImage2D on a texture
> with internalformat/format/type = GL_SLUMINANCE8/GL_BGRA/GL_UNSIGNED_BYTE.
>
> The function only supports MESA_FORMAT_ARGB and returns early if it
> detects an unsupported format. Clearly, its detection condition was
> insufficient. This patch fixes it to explicity check for
> MESA_FORMAT_ARGB.
>
> CC: Kenneth Graunke 
> Signed-off-by: Chad Versace 
> ---
>  src/mesa/drivers/dri/intel/intel_tex_subimage.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> index d3a8736..aa6f237 100644
> --- a/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> +++ b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> @@ -199,8 +199,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
>  * varying the arithmetic loop below.
>  */
> if (!intel->has_llc ||
> -   format != GL_BGRA ||
> -   type != GL_UNSIGNED_BYTE ||
> +   texImage->TexFormat != MESA_FORMAT_ARGB ||
> texImage->TexObject->Target != GL_TEXTURE_2D ||
> texImage->Level != 0 ||
> pixels == NULL ||
> --
> 1.7.12.1
>

I'm not terribly familiar with this corner of the codebase, but it sounds
reasonable to me.

Acked-by: Paul Berry 

Since this patch fixes a bug in 413c4914129cd26ca87960852d8c0264c0fb29e7
(which is a candidate for the 9.0 branch), I'd recommend including the text
"Note: This is a candidate for the 9.0 branch." in the commit message.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 1/1] intel: add support for ANGLE_texture_compression_dxt.

2012-09-26 Thread Oliver McFadden 
Signed-off-by: Oliver McFadden 
---
I believe this is approximately v3; after two iterations and the FEATURE_x
defines removal.  The patch becomes much smaller after that!  Hopefully I've
addressed everybody's comments but I expect to have missed something...

 src/glx/glxextensions.h   |3 ++-
 src/mapi/glapi/gen/es_EXT.xml |6 ++
 src/mesa/drivers/dri/intel/intel_extensions.c |1 +
 src/mesa/main/APIspec.xml |3 +++
 src/mesa/main/extensions.c|3 +++
 src/mesa/main/glformats.c |6 --
 src/mesa/main/glheader.h  |   11 +++
 src/mesa/main/mtypes.h|1 +
 src/mesa/main/texformat.c |9 ++---
 src/mesa/main/teximage.c  |   10 ++
 10 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 90c27a7..9e072e4 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -67,7 +67,8 @@ enum
 
 enum
 {
-   GL_ARB_depth_texture_bit = 0,
+   GL_ANGLE_texture_compression_dxt_bit = 0,
+   GL_ARB_depth_texture_bit,
GL_ARB_draw_buffers_bit,
GL_ARB_fragment_program_bit,
GL_ARB_fragment_program_shadow_bit,
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index fc2ec62..2698110 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -731,4 +731,10 @@
 
 
 
+
+
+
+
+
+
 
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c 
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 89f6c1e..758b2d3 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -181,6 +181,7 @@ intelInitExtensions(struct gl_context *ctx)
 ctx->Extensions.ARB_occlusion_query = true;
}
 
+   ctx->Extensions.ANGLE_texture_compression_dxt = true;
if (intel->ctx.Mesa_DXTn) {
   ctx->Extensions.EXT_texture_compression_s3tc = true;
   ctx->Extensions.S3_s3tc = true;
diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
index a65c5c5..c396952 100644
--- a/src/mesa/main/APIspec.xml
+++ b/src/mesa/main/APIspec.xml
@@ -2172,6 +2172,9 @@


 
+   
+   
+

 
 
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index bd7c7ba..5af1de0 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
{ "GL_EXT_texture3D",   o(EXT_texture3D),   
GLL,1996 },
{ "GL_EXT_texture_array",   o(EXT_texture_array),   
GL, 2006 },
{ "GL_EXT_texture_compression_dxt1",
o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
+   { "GL_ANGLE_texture_compression_dxt3",  
o(ANGLE_texture_compression_dxt),   ES2,2011 },
+   { "GL_ANGLE_texture_compression_dxt5",  
o(ANGLE_texture_compression_dxt),   ES2,2011 },
{ "GL_EXT_texture_compression_latc",
o(EXT_texture_compression_latc),GL, 2006 },
{ "GL_EXT_texture_compression_rgtc",
o(ARB_texture_compression_rgtc),GL, 2004 },
{ "GL_EXT_texture_compression_s3tc",
o(EXT_texture_compression_s3tc),GL, 2000 },
@@ -479,6 +481,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
ctx->Extensions.NV_fragment_program_option = GL_TRUE;
ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
_mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
+   ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
if (ctx->Mesa_DXTn) {
   _mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
   _mesa_enable_extension(ctx, "GL_S3_s3tc");
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 04029c0..ccdf56b 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx, GLenum 
format)
   return ctx->Extensions.EXT_texture_compression_s3tc;
case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
-  return _mesa_is_desktop_gl(ctx)
- && ctx->Extensions.EXT_texture_compression_s3tc;
+  return (_mesa_is_desktop_gl(ctx) &&
+ ctx->Extensions.EXT_texture_compression_s3tc) ||
+(ctx->API == API_OPENGLES2 &&
+ ctx->Extensions.ANGLE_texture_compression_dxt);
case GL_RGB_S3TC:
case GL_RGB4_S3TC:
case GL_RGBA_S3TC:
diff --git a/src/mesa/main/glheader.h b/src/mesa/main/glheader.h
index e93ca30..33cda02 100644
--- a/src/mesa/main/glheader.h
+++ b/src/mesa/main/glheader.h
@@ -59,6 +59,17 @@ extern "C" {
 #endif
 
 
+/* GL_ANGL

[Mesa-dev] [PATCH] radeon/llvm: improve select_cc lowering to generate CND* more often

2012-09-26 Thread Vincent Lejeune 
v2: - Simplify isZero()
- Remove a unused function prototype
- Clean whitespace trails
---
 src/gallium/drivers/r600/r600_llvm.c| 15 +
 src/gallium/drivers/radeon/R600ISelLowering.cpp | 89 +++--
 src/gallium/drivers/radeon/R600ISelLowering.h   |  2 +
 src/gallium/drivers/radeon/R600Instructions.td  | 38 +--
 4 files changed, 103 insertions(+), 41 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_llvm.c 
b/src/gallium/drivers/r600/r600_llvm.c
index bc2f46e..e935ee2 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -201,6 +201,20 @@ static void llvm_emit_tex(
emit_data->dst_type, args, c, 
LLVMReadNoneAttribute);
 }
 
+static void emit_cndlt(
+   const struct lp_build_tgsi_action * action,
+   struct lp_build_tgsi_context * bld_base,
+   struct lp_build_emit_data * emit_data)
+{
+   LLVMBuilderRef builder = bld_base->base.gallivm->builder;
+   LLVMValueRef float_zero = lp_build_const_float(
+   bld_base->base.gallivm, 0.0f);
+   LLVMValueRef cmp = LLVMBuildFCmp(
+   builder, LLVMRealULT, emit_data->args[0], float_zero, "");
+   emit_data->output[emit_data->chan] = LLVMBuildSelect(builder,
+   cmp, emit_data->args[1], emit_data->args[2], "");
+}
+
 static void dp_fetch_args(
struct lp_build_tgsi_context * bld_base,
struct lp_build_emit_data * emit_data)
@@ -277,6 +291,7 @@ LLVMModuleRef r600_tgsi_llvm(
bld_base->op_actions[TGSI_OPCODE_TXF].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXQ].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXP].emit = llvm_emit_tex;
+   bld_base->op_actions[TGSI_OPCODE_CMP].emit = emit_cndlt;
 
lp_build_tgsi_llvm(bld_base, tokens);
 
diff --git a/src/gallium/drivers/radeon/R600ISelLowering.cpp 
b/src/gallium/drivers/radeon/R600ISelLowering.cpp
index 2fc9c67..5dd2f53 100644
--- a/src/gallium/drivers/radeon/R600ISelLowering.cpp
+++ b/src/gallium/drivers/radeon/R600ISelLowering.cpp
@@ -516,6 +516,17 @@ SDValue R600TargetLowering::LowerROTL(SDValue Op, 
SelectionDAG &DAG) const
  Op.getOperand(1)));
 }
 
+bool R600TargetLowering::isZero(SDValue Op) const
+{
+  if(ConstantSDNode *Cst = dyn_cast(Op)) {
+return Cst->isNullValue();
+  } else if(ConstantFPSDNode *CstFP = dyn_cast(Op)){
+return CstFP->isZero();
+  } else {
+return false;
+  }
+}
+
 SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, SelectionDAG &DAG) const
 {
   DebugLoc DL = Op.getDebugLoc();
@@ -568,47 +579,58 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, 
SelectionDAG &DAG) const
   if (isHWTrueValue(False) && isHWFalseValue(True)) {
   }
 
-  // XXX Check if we can lower this to a SELECT or if it is supported by a 
native
-  // operation. (The code below does this but we don't have the Instruction
-  // selection patterns to do this yet.
-#if 0
+  // Check if we can lower this to a native operation.
+  // CND* instructions requires all operands to have the same type,
+  // and RHS to be zero.
+
   if (isZero(LHS) || isZero(RHS)) {
 SDValue Cond = (isZero(LHS) ? RHS : LHS);
-bool SwapTF = false;
+SDValue Zero = (isZero(LHS) ? LHS : RHS);
+ISD::CondCode CCOpcode = cast(CC)->get();
+if (CompareVT != VT) {
+  True = DAG.getNode(ISD::BITCAST, DL, CompareVT, True);
+  False = DAG.getNode(ISD::BITCAST, DL, CompareVT, False);
+}
+if (isZero(LHS)) {
+  CCOpcode = ISD::getSetCCSwappedOperands(CCOpcode);
+}
+
 switch (CCOpcode) {
-case ISD::SETOEQ:
-case ISD::SETUEQ:
-case ISD::SETEQ:
-  SwapTF = true;
-  // Fall through
 case ISD::SETONE:
 case ISD::SETUNE:
 case ISD::SETNE:
-  // We can lower to select
-  if (SwapTF) {
-Temp = True;
-True = False;
-False = Temp;
-  }
-  // CNDE
-  return DAG.getNode(ISD::SELECT, DL, VT, Cond, True, False);
+case ISD::SETULE:
+case ISD::SETULT:
+case ISD::SETOLE:
+case ISD::SETOLT:
+case ISD::SETLE:
+case ISD::SETLT:
+  CCOpcode = ISD::getSetCCInverse(CCOpcode, CompareVT == MVT::i32);
+  Temp = True;
+  True = False;
+  False = Temp;
+  break;
 default:
-  // Supported by a native operation (CNDGE, CNDGT)
-  return DAG.getNode(ISD::SELECT_CC, DL, VT, LHS, RHS, True, False, CC);
+  break;
 }
+SDValue SelectNode = DAG.getNode(ISD::SELECT_CC, DL, CompareVT,
+Cond, Zero,
+True, False,
+DAG.getCondCode(CCOpcode));
+return DAG.getNode(ISD::BITCAST, DL, VT, SelectNode);
   }
-#endif
+
 
   // If we make it this for it means we have no native instructions to handle
   // this SELECT_CC, so we must lower it.
   SDValue HWTrue, HWFalse;
 
-  if (VT == MVT::f32) {
-HWTrue = DAG.getConstantFP(1.0f, VT);
-HWFalse = DAG.getConstan

Re: [Mesa-dev] [PATCH] radeon/llvm: improve select_cc lowering to generate CND* more often

2012-09-26 Thread Tom Stellard 
On Wed, Sep 26, 2012 at 09:33:15PM +0200, Vincent Lejeune wrote:
> v2: - Simplify isZero()
> - Remove a unused function prototype
> - Clean whitespace trails
> ---
>  src/gallium/drivers/r600/r600_llvm.c| 15 +
>  src/gallium/drivers/radeon/R600ISelLowering.cpp | 89 
> +++--
>  src/gallium/drivers/radeon/R600ISelLowering.h   |  2 +
>  src/gallium/drivers/radeon/R600Instructions.td  | 38 +--
>  4 files changed, 103 insertions(+), 41 deletions(-)
>

This version should be safe for radeonsi.

Reviewed-by: Tom Stellard 

> diff --git a/src/gallium/drivers/r600/r600_llvm.c 
> b/src/gallium/drivers/r600/r600_llvm.c
> index bc2f46e..e935ee2 100644
> --- a/src/gallium/drivers/r600/r600_llvm.c
> +++ b/src/gallium/drivers/r600/r600_llvm.c
> @@ -201,6 +201,20 @@ static void llvm_emit_tex(
>   emit_data->dst_type, args, c, 
> LLVMReadNoneAttribute);
>  }
>  
> +static void emit_cndlt(
> + const struct lp_build_tgsi_action * action,
> + struct lp_build_tgsi_context * bld_base,
> + struct lp_build_emit_data * emit_data)
> +{
> + LLVMBuilderRef builder = bld_base->base.gallivm->builder;
> + LLVMValueRef float_zero = lp_build_const_float(
> + bld_base->base.gallivm, 0.0f);
> + LLVMValueRef cmp = LLVMBuildFCmp(
> + builder, LLVMRealULT, emit_data->args[0], float_zero, "");
> + emit_data->output[emit_data->chan] = LLVMBuildSelect(builder,
> + cmp, emit_data->args[1], emit_data->args[2], "");
> +}
> +
>  static void dp_fetch_args(
>   struct lp_build_tgsi_context * bld_base,
>   struct lp_build_emit_data * emit_data)
> @@ -277,6 +291,7 @@ LLVMModuleRef r600_tgsi_llvm(
>   bld_base->op_actions[TGSI_OPCODE_TXF].emit = llvm_emit_tex;
>   bld_base->op_actions[TGSI_OPCODE_TXQ].emit = llvm_emit_tex;
>   bld_base->op_actions[TGSI_OPCODE_TXP].emit = llvm_emit_tex;
> + bld_base->op_actions[TGSI_OPCODE_CMP].emit = emit_cndlt;
>  
>   lp_build_tgsi_llvm(bld_base, tokens);
>  
> diff --git a/src/gallium/drivers/radeon/R600ISelLowering.cpp 
> b/src/gallium/drivers/radeon/R600ISelLowering.cpp
> index 2fc9c67..5dd2f53 100644
> --- a/src/gallium/drivers/radeon/R600ISelLowering.cpp
> +++ b/src/gallium/drivers/radeon/R600ISelLowering.cpp
> @@ -516,6 +516,17 @@ SDValue R600TargetLowering::LowerROTL(SDValue Op, 
> SelectionDAG &DAG) const
>   Op.getOperand(1)));
>  }
>  
> +bool R600TargetLowering::isZero(SDValue Op) const
> +{
> +  if(ConstantSDNode *Cst = dyn_cast(Op)) {
> +return Cst->isNullValue();
> +  } else if(ConstantFPSDNode *CstFP = dyn_cast(Op)){
> +return CstFP->isZero();
> +  } else {
> +return false;
> +  }
> +}
> +
>  SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, SelectionDAG &DAG) 
> const
>  {
>DebugLoc DL = Op.getDebugLoc();
> @@ -568,47 +579,58 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op, 
> SelectionDAG &DAG) const
>if (isHWTrueValue(False) && isHWFalseValue(True)) {
>}
>  
> -  // XXX Check if we can lower this to a SELECT or if it is supported by a 
> native
> -  // operation. (The code below does this but we don't have the Instruction
> -  // selection patterns to do this yet.
> -#if 0
> +  // Check if we can lower this to a native operation.
> +  // CND* instructions requires all operands to have the same type,
> +  // and RHS to be zero.
> +
>if (isZero(LHS) || isZero(RHS)) {
>  SDValue Cond = (isZero(LHS) ? RHS : LHS);
> -bool SwapTF = false;
> +SDValue Zero = (isZero(LHS) ? LHS : RHS);
> +ISD::CondCode CCOpcode = cast(CC)->get();
> +if (CompareVT != VT) {
> +  True = DAG.getNode(ISD::BITCAST, DL, CompareVT, True);
> +  False = DAG.getNode(ISD::BITCAST, DL, CompareVT, False);
> +}
> +if (isZero(LHS)) {
> +  CCOpcode = ISD::getSetCCSwappedOperands(CCOpcode);
> +}
> +
>  switch (CCOpcode) {
> -case ISD::SETOEQ:
> -case ISD::SETUEQ:
> -case ISD::SETEQ:
> -  SwapTF = true;
> -  // Fall through
>  case ISD::SETONE:
>  case ISD::SETUNE:
>  case ISD::SETNE:
> -  // We can lower to select
> -  if (SwapTF) {
> -Temp = True;
> -True = False;
> -False = Temp;
> -  }
> -  // CNDE
> -  return DAG.getNode(ISD::SELECT, DL, VT, Cond, True, False);
> +case ISD::SETULE:
> +case ISD::SETULT:
> +case ISD::SETOLE:
> +case ISD::SETOLT:
> +case ISD::SETLE:
> +case ISD::SETLT:
> +  CCOpcode = ISD::getSetCCInverse(CCOpcode, CompareVT == MVT::i32);
> +  Temp = True;
> +  True = False;
> +  False = Temp;
> +  break;
>  default:
> -  // Supported by a native operation (CNDGE, CNDGT)
> -  return DAG.getNode(ISD::SELECT_CC, DL, VT, LHS, RHS, True, False, CC);
> +  break;
>  }
> +SDValue SelectNode = DAG.getNode(ISD::SELECT_CC, DL, CompareVT,
> +Cond, Zero,
> +True,

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Matt Turner 
On Mon, Sep 24, 2012 at 2:52 PM, Matt Turner  wrote:
> This series of 105 patches finishes the automake conversion.
>
> I don't think the series needs to be reviewed patch by patch, since
> large chunks are making nearly identical changes to different
> directories. Plus, incorrect changes in the build system should be
> detectable with testing. As such, I won't send the patches to the
> list.
>
> The first patches are some clean ups that may be applicable to 9.0
> depending on when it's actually going to be released. The middle of
> the series is mostly mindless conversion. And the last of the series
> is removing gobs and gobs of crap like makedepend, MESA_PIC_FLAGS,
> VAAPI, and dead makefiles.
>
> I've paid special attention to linking Gallium targets with gcc vs
> g++. Some drivers (like Nouveau) use C++ in the driver so always need
> to be linked with g++. Others (like r300) always require LLVM and need
> to be linked with g++. Others still, like softpipe, should be linked
> with g++ conditional on LLVM usage. I've tried to handle this, so
> testing with and without LLVM is important.
>
> Please help me find problems now before it goes into master. Here's a
> branch. It's easy to test. If you don't test and I commit this in a
> week and break your stuff, I'm sorry, but you didn't test.
>
> http://cgit.freedesktop.org/~mattst88/mesa/log/?h=automake-gallium

I've pushed an automake-gallium2 branch to my repo with a number of
fixes squashed-in.

git://people.freedesktop.org/~mattst88/mesa automake-gallium2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Török Edwin 
On 09/26/2012 11:59 PM, Matt Turner wrote:
> I've pushed an automake-gallium2 branch to my repo with a number of
> fixes squashed-in.
> 
> git://people.freedesktop.org/~mattst88/mesa automake-gallium2

Nice progress!

I was able to build it after reversing the 'if' below.

It doesn't load though:
libGL: OpenDriver: trying opt/xorg/lib/dri/r600_dri.so
libGL error: dlopen opt/xorg/lib/dri/r600_dri.so failed 
(opt/xorg/lib/dri/r600_dri.so: undefined symbol: 
_ZN4llvm13ParseAssemblyEPNS_12MemoryBufferEPNS_6ModuleERNS_12SMDiagnosticERNS_11LLVMContextE)


diff --git a/src/gallium/drivers/radeon/Makefile.am 
b/src/gallium/drivers/radeon/Makefile.am
index d0e0ec3..668ad5f 100644
--- a/src/gallium/drivers/radeon/Makefile.am
+++ b/src/gallium/drivers/radeon/Makefile.am
@@ -28,9 +28,9 @@ SIRegisterGetHWRegNum.inc: SIGenRegisterInfo.pl

 R600Intrinsics.td: R600IntrinsicsNoOpenCL.td R600IntrinsicsOpenCL.td
 if HAVE_R600_LLVM_INTRINSICS
-   cp $(srcdir)/R600IntrinsicsNoOpenCL.td R600Intrinsics.td
-else
cp $(srcdir)/R600IntrinsicsOpenCL.td R600Intrinsics.td
+else
+   cp $(srcdir)/R600IntrinsicsNoOpenCL.td R600Intrinsics.td
 endif

However it still seems to be missing a dependency as rerunning configure
doesn't cause the .td file to be copied, had to manually remove it.

Another issue is that the yacc-generated files are not removed by 'make clean',
but thats probably on purpose (do the generated files get shipped in the 
release tarball?),
I should've run 'make distclean'.

But 'make distclean' fails so I had to manually remove those generated files:
make[3]: Entering directory 
`/home/edwin/HDD/me/language/C++/xorg/mesa/src/gallium/winsys/sw/fbdev'
make[3]: *** No rule to make target `distclean'.  Stop.

Best regards,
--Edwin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Matt Turner 
On Wed, Sep 26, 2012 at 2:50 PM, Török Edwin
 wrote:
> On 09/26/2012 11:59 PM, Matt Turner wrote:
>> I've pushed an automake-gallium2 branch to my repo with a number of
>> fixes squashed-in.
>>
>> git://people.freedesktop.org/~mattst88/mesa automake-gallium2
>
> Nice progress!
>
> I was able to build it after reversing the 'if' below.

Weird. I don't have this problem.

> It doesn't load though:
> libGL: OpenDriver: trying opt/xorg/lib/dri/r600_dri.so
> libGL error: dlopen opt/xorg/lib/dri/r600_dri.so failed 
> (opt/xorg/lib/dri/r600_dri.so: undefined symbol: 
> _ZN4llvm13ParseAssemblyEPNS_12MemoryBufferEPNS_6ModuleERNS_12SMDiagnosticERNS_11LLVMContextE)

Tom, are there some extra LLVM libs that need to be linked in, or is
this a problem caused by switching the if statement? I'm not able to
reproduce this locally (with LLVM-3.1).

> diff --git a/src/gallium/drivers/radeon/Makefile.am 
> b/src/gallium/drivers/radeon/Makefile.am
> index d0e0ec3..668ad5f 100644
> --- a/src/gallium/drivers/radeon/Makefile.am
> +++ b/src/gallium/drivers/radeon/Makefile.am
> @@ -28,9 +28,9 @@ SIRegisterGetHWRegNum.inc: SIGenRegisterInfo.pl
>
>  R600Intrinsics.td: R600IntrinsicsNoOpenCL.td R600IntrinsicsOpenCL.td
>  if HAVE_R600_LLVM_INTRINSICS
> -   cp $(srcdir)/R600IntrinsicsNoOpenCL.td R600Intrinsics.td
> -else
> cp $(srcdir)/R600IntrinsicsOpenCL.td R600Intrinsics.td
> +else
> +   cp $(srcdir)/R600IntrinsicsNoOpenCL.td R600Intrinsics.td
>  endif
>
> However it still seems to be missing a dependency as rerunning configure
> doesn't cause the .td file to be copied, had to manually remove it.

Tom's area. Let's see what he thinks.

> Another issue is that the yacc-generated files are not removed by 'make 
> clean',
> but thats probably on purpose (do the generated files get shipped in the 
> release tarball?),
> I should've run 'make distclean'.

Specifically program_parse.c and program_lexer.c, right?

I'm not sure whether yacc- and lex-generated files should be removed
by make clean. I'm inconsistent about this -- I don't remove the
program files, but I do remove the glsl/glcpp files on make clean.

However, they should be shipped in the tarball.

> But 'make distclean' fails so I had to manually remove those generated files:
> make[3]: Entering directory 
> `/home/edwin/HDD/me/language/C++/xorg/mesa/src/gallium/winsys/sw/fbdev'
> make[3]: *** No rule to make target `distclean'.  Stop.

Interesting. I can reproduce this. It looks related to the way
configure.ac substitutes subdirs into the Makefile (which is wrong).
configure.ac appends sw/fbdev to GALLIUM_WINSYS_DIRS but also I add
fbdev to SUBDIRS in src/gallium/winsys/sw. I'll figure out how to fix
that.

Again, thanks for testing!
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Flag _NEW_VARYING_VP_INPUTS when there's no vertex program.

2012-09-26 Thread Ian Romanick 

On 09/18/2012 06:49 PM, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Thanks to your patch, I've got a theory.

i915 doesn't set _MaintainTnlProgram to TRUE, which causes core Mesa
to set both _TnlProgram and _Current to NULL, therefore
_mesa_set_varying_vp_inputs is a no-op. (If _MaintainTnlProgram were
TRUE, the shaders would be set properly in main/state.c:199). However,
the tnl module looks if there is any state change
(tnl/t_pipeline.c:128) and calls _tnl_UpdateFixedFunctionProgram,
which then updates both _TnlProgram and _Current in a similar way
main/state.c:199 would do.

Clearly, the tnl module does use the fixed-function program and core
Mesa doesn't know about it. That's why it never got
_NEW_VARYING_VP_INPUTS. Also I guess _tnl_UpdateFixedFunctionProgram
should not mess with core Mesa's state.


So... based on that, it seems like _mesa_set-varying_vp_inputs should 
actually check ctx->FragmentProgram._TexEnvProgram instead, right?


As an aside, 'varying VP inputs' is one of the worst names ever.  Vertex 
programs don't have varying inputs.  I had to dig around in the code for 
quite some time to figure out what it actually was.



Marek

On Sun, Sep 16, 2012 at 10:18 AM, Kenneth Graunke  wrote:

The idea here is to not flag _NEW_VARYING_VP_INPUTS when shaders (either
GLSL or ARB vp/fp) are in use.  Fixed function happens when either
a) there is no vertex program, or b) it's the current TNL program.

On Pineview, fixes 20 Piglit, 60 oglconforms, and 7 ES 1.1 conformance
tests, as well as missing textures in Xonotic.  These were all
regressions since commit fb4a34e60eb4c1bdc7b0fdcd98d1bf3038c354e8.

I have to confess I don't understand exactly why this fixes the problem,
but I figured it's better than reverting Marek's patch entirely.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49127
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54807
Signed-off-by: Kenneth Graunke 
---
  src/mesa/main/state.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 76946bd..5c9c5a5 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -627,7 +627,7 @@ _mesa_set_varying_vp_inputs( struct gl_context *ctx,
 *
 * It's okay to check the VP pointer here, because this is called after
 * _mesa_update_state in the vbo module. */
-  if (ctx->VertexProgram._TnlProgram) {
+  if (!ctx->VertexProgram._Current || ctx->VertexProgram._TnlProgram) {
   ctx->NewState |= _NEW_VARYING_VP_INPUTS;
}
/*printf("%s %x\n", __FUNCTION__, varying_inputs);*/
--
1.7.11.4

___
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



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i915: Don't leave dangling pointer to i915 context on failure

2012-09-26 Thread Ian Romanick 
From: Ian Romanick 

Otherwise intelDestroyContext would try to dereference the pointer to
freed memory.

NOTE: This is a candidate for the 9.0 branch.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53618
---
 src/mesa/drivers/dri/i915/i915_context.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_context.c 
b/src/mesa/drivers/dri/i915/i915_context.c
index 8ae1e58..82bd3e0 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -167,9 +167,8 @@ i915CreateContext(int api,
 
if (!intelInitContext(intel, api, mesaVis, driContextPriv,
  sharedContextPrivate, &functions)) {
-  free(i915);
   *error = __DRI_CTX_ERROR_NO_MEMORY;
-  return false;
+  goto error;
}
 
/* Now that the extension bits are known, filter against the requested API
@@ -184,8 +183,7 @@ i915CreateContext(int api,
 
   if (req_version > max_version) {
  *error = __DRI_CTX_ERROR_BAD_VERSION;
- free(i915);
- return false;
+ goto error;
   }
   break;
}
@@ -194,8 +192,7 @@ i915CreateContext(int api,
   break;
default:
   *error = __DRI_CTX_ERROR_BAD_API;
-  free(i915);
-  return false;
+  goto error;
}
 
intel_init_texture_formats(ctx);
@@ -299,4 +296,9 @@ i915CreateContext(int api,
_tnl_allow_pixel_fog(ctx, 1);
 
return true;
+
+error:
+   ralloc_free(i915);
+   driContextPriv->driverPrivate = NULL;
+   return false;
 }
-- 
1.7.11.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Flag _NEW_VARYING_VP_INPUTS when there's no vertex program.

2012-09-26 Thread Marek Olšák 
On Thu, Sep 27, 2012 at 1:53 AM, Ian Romanick  wrote:
> On 09/18/2012 06:49 PM, Marek Olšák wrote:
>>
>> Reviewed-by: Marek Olšák 
>>
>> Thanks to your patch, I've got a theory.
>>
>> i915 doesn't set _MaintainTnlProgram to TRUE, which causes core Mesa
>> to set both _TnlProgram and _Current to NULL, therefore
>> _mesa_set_varying_vp_inputs is a no-op. (If _MaintainTnlProgram were
>> TRUE, the shaders would be set properly in main/state.c:199). However,
>> the tnl module looks if there is any state change
>> (tnl/t_pipeline.c:128) and calls _tnl_UpdateFixedFunctionProgram,
>> which then updates both _TnlProgram and _Current in a similar way
>> main/state.c:199 would do.
>>
>> Clearly, the tnl module does use the fixed-function program and core
>> Mesa doesn't know about it. That's why it never got
>> _NEW_VARYING_VP_INPUTS. Also I guess _tnl_UpdateFixedFunctionProgram
>> should not mess with core Mesa's state.
>
>
> So... based on that, it seems like _mesa_set-varying_vp_inputs should
> actually check ctx->FragmentProgram._TexEnvProgram instead, right?

Not sure about that.

After some more code reading, my previous theory seems to be wrong and
I think Kenneth's patch is correct. The TexEnvProgram uses
varying_vp_inputs only when there isn't any user-supplied vertex
program/shader and the condition "!ctx->VertexProgram._Current ||
ctx->VertexProgram._TnlProgram" satisfies that, right?

>
> As an aside, 'varying VP inputs' is one of the worst names ever.  Vertex
> programs don't have varying inputs.  I had to dig around in the code for
> quite some time to figure out what it actually was.

We could rename it to "non-const VP inputs". At least that sounds better to me.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] svga: Remove wierd code which forces non-sRGB formats.

2012-09-26 Thread John Kåre Alsaker 
glean/readPixSanity is failing. Depth and stencil buffers are read
back wrong, while RGBA is fine.

On 9/25/12, Brian Paul  wrote:
> On 09/24/2012 11:09 PM, John Kåre Alsaker wrote:
>> On Mon, Sep 24, 2012 at 5:22 PM, Brian Paul > > wrote:
>>
>> On 09/23/2012 05:44 AM, John Kåre Alsaker wrote:
>>
>> ---
>>src/gallium/drivers/svga/svga_resource_texture.c | 8 
>>1 file changed, 8 deletions(-)
>>
>> diff --git a/src/gallium/drivers/svga/svga_resource_texture.c
>> b/src/gallium/drivers/svga/svga_resource_texture.c
>> index 9830e79..97ec7ee 100644
>> --- a/src/gallium/drivers/svga/svga_resource_texture.c
>> +++ b/src/gallium/drivers/svga/svga_resource_texture.c
>> @@ -540,14 +540,6 @@ svga_texture_from_handle(struct
>> pipe_screen *screen,
>>   pipe_reference_init(&tex->b.b.reference, 1);
>>   tex->b.b.screen = screen;
>>
>> -   if (format == SVGA3D_X8R8G8B8)
>> -  tex->b.b.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>> -   else if (format == SVGA3D_A8R8G8B8)
>> -  tex->b.b.format = PIPE_FORMAT_B8G8R8A8_UNORM;
>> -   else {
>> -  /* ?? */
>> -   }
>> -
>>   SVGA_DBG(DEBUG_DMA, "wrap surface sid %p\n", srf);
>>
>>   tex->key.cachable = 0;
>>
>>
>> Yeah, I don't know what that's all about either.  Have you done a
>> piglit run with this change to check for regressions?
>>
>> Piglit doesn't pass the sanity tests with Mesa master. Are there any
>> tests for shared handles in there?
>
> There's only two tests in sanity.tests (glean/readPixSanity and
> glean/basic) and they both pass for me with the VMware svga driver.
>
> What exactly is your command line and what's the output?
>
> In any case, the sanity.tests group isn't enough.  A full piglit run
> would be run with something like this:
>
> ./piglit_run.py tests.all.tests results
>
> I'll run the test here but you might want to do more investigation on
> your side to see why the sanity tests aren't passing.
>
> -Brian
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Kenneth Graunke 
On 09/26/2012 04:09 PM, Matt Turner wrote:
> On Wed, Sep 26, 2012 at 2:50 PM, Török Edwin wrote:
>> Another issue is that the yacc-generated files are not removed by 'make 
>> clean',
>> but thats probably on purpose (do the generated files get shipped in the 
>> release tarball?),
>> I should've run 'make distclean'.
> 
> Specifically program_parse.c and program_lexer.c, right?
> 
> I'm not sure whether yacc- and lex-generated files should be removed
> by make clean. I'm inconsistent about this -- I don't remove the
> program files, but I do remove the glsl/glcpp files on make clean.
> 
> However, they should be shipped in the tarball.

I would argue that 'make clean' should remove them.  In my mind, the
purpose of 'make clean' is to remove any files generated as part of the
build process (or at least the 'make' part of it), which includes
generated source code.

Including them in the tarballs seems sensible.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Matt Turner 
On Wed, Sep 26, 2012 at 10:47 PM, Kenneth Graunke  wrote:
> On 09/26/2012 04:09 PM, Matt Turner wrote:
>> On Wed, Sep 26, 2012 at 2:50 PM, Török Edwin wrote:
>>> Another issue is that the yacc-generated files are not removed by 'make 
>>> clean',
>>> but thats probably on purpose (do the generated files get shipped in the 
>>> release tarball?),
>>> I should've run 'make distclean'.
>>
>> Specifically program_parse.c and program_lexer.c, right?
>>
>> I'm not sure whether yacc- and lex-generated files should be removed
>> by make clean. I'm inconsistent about this -- I don't remove the
>> program files, but I do remove the glsl/glcpp files on make clean.
>>
>> However, they should be shipped in the tarball.
>
> I would argue that 'make clean' should remove them.  In my mind, the
> purpose of 'make clean' is to remove any files generated as part of the
> build process (or at least the 'make' part of it), which includes
> generated source code.
>
> Including them in the tarballs seems sensible.

Imagine unpacking the tarball (which has the generated code which
doesn't require flex and bison, at least it shouldn't), running make
clean (which removes the code) and then trying to rebuild. :)

I'm not sure it matters much, and there are multiple ways to avoid
this. I just haven't though about what is actually sensible.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Fix segfault in intel_texsubimage_tiled_memcpy

2012-09-26 Thread Kenneth Graunke 
On 09/26/2012 11:22 AM, Chad Versace wrote:
> The function segfaulted when a game called glTexSubImage2D on a texture
> with internalformat/format/type = GL_SLUMINANCE8/GL_BGRA/GL_UNSIGNED_BYTE.

Wait, is that what it was doing?  Specifying a four component format but
a single component (and sRGB, and deprecated) internal format?  That's
truly bizarre...wonder what on earth it's trying to do.

> The function only supports MESA_FORMAT_ARGB and returns early if it
> detects an unsupported format. Clearly, its detection condition was
> insufficient. This patch fixes it to explicity check for
> MESA_FORMAT_ARGB.
> 
> CC: Kenneth Graunke 
> Signed-off-by: Chad Versace 

Your patch seems reasonable and does fix the problem I was seeing.
Thanks for the prompt response!

Reviewed-and-tested-by: Kenneth Graunke 

> ---
>  src/mesa/drivers/dri/intel/intel_tex_subimage.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/intel/intel_tex_subimage.c 
> b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> index d3a8736..aa6f237 100644
> --- a/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> +++ b/src/mesa/drivers/dri/intel/intel_tex_subimage.c
> @@ -199,8 +199,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
>  * varying the arithmetic loop below.
>  */
> if (!intel->has_llc ||
> -   format != GL_BGRA ||
> -   type != GL_UNSIGNED_BYTE ||
> +   texImage->TexFormat != MESA_FORMAT_ARGB ||
> texImage->TexObject->Target != GL_TEXTURE_2D ||
> texImage->Level != 0 ||
> pixels == NULL ||
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Please test the automake-gallium branch

2012-09-26 Thread Kenneth Graunke 
On 09/26/2012 10:55 PM, Matt Turner wrote:
> On Wed, Sep 26, 2012 at 10:47 PM, Kenneth Graunke  
> wrote:
>> On 09/26/2012 04:09 PM, Matt Turner wrote:
>>> On Wed, Sep 26, 2012 at 2:50 PM, Török Edwin wrote:
 Another issue is that the yacc-generated files are not removed by 'make 
 clean',
 but thats probably on purpose (do the generated files get shipped in the 
 release tarball?),
 I should've run 'make distclean'.
>>>
>>> Specifically program_parse.c and program_lexer.c, right?
>>>
>>> I'm not sure whether yacc- and lex-generated files should be removed
>>> by make clean. I'm inconsistent about this -- I don't remove the
>>> program files, but I do remove the glsl/glcpp files on make clean.
>>>
>>> However, they should be shipped in the tarball.
>>
>> I would argue that 'make clean' should remove them.  In my mind, the
>> purpose of 'make clean' is to remove any files generated as part of the
>> build process (or at least the 'make' part of it), which includes
>> generated source code.
>>
>> Including them in the tarballs seems sensible.
> 
> Imagine unpacking the tarball (which has the generated code which
> doesn't require flex and bison, at least it shouldn't), running make
> clean (which removes the code) and then trying to rebuild. :)
> 
> I'm not sure it matters much, and there are multiple ways to avoid
> this. I just haven't though about what is actually sensible.

Yeah.  Honestly, putting generated code in the tarballs and making the
build system deal with both the tarball/non-tarball case has always
seemed like a pain.  I'd almost rather just see it be consistent...

It does avoid having to install bison and flex.  (It doesn't avoid
python 2.x.)  Developers have them already, and they're pretty common.
For most distros, it's probably just a matter of flagging the build
dependency in the package description and pointing tools at it.  Is this
really useful for anybody?

If it is, then sure, it's totally solvable.  If it's not, well...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev