[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=44618

Chi-Thanh Christopher Nguyen  changed:

   What|Removed |Added

   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=412931

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

[Mesa-dev] [Bug 48351] wine FurMark crashes after llvm_pipeline_generic

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48351

--- Comment #2 from José Fonseca  2012-04-25 09:33:52 PDT 
---
Created attachment 60583
  --> https://bugs.freedesktop.org/attachment.cgi?id=60583
Potential fix

Please try the attached change

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

[Mesa-dev] [Bug 48351] wine FurMark crashes after llvm_pipeline_generic

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48351

José Fonseca  changed:

   What|Removed |Added

 AssignedTo|mesa-dev@lists.freedesktop. |jfons...@vmware.com
   |org |
 CC||bri...@vmware.com,
   ||jfons...@vmware.com

-- 
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 0/7] intel: implement DRI image extension v4

[Eric Anholt]

On Tue, 24 Apr 2012 17:30:32 +0200, Gwenole Beauchesne  
wrote:
> Hi,
> 
> This patch series implements the proposed DRI image extension v4
> changes to Intel GenX. To be honest, I have not tested the picture
> structure patch, as I directly adapted it from the VA driver, where
> interlaced surfaces are correctly handled already.
> 
> I simplified the hashing stuff to the minimal useful set. i.e. store
> up to 3 intel_regions into an hash entry. No more variable array of
> regions.

So, I really don't like this idea.  Is there some requirement that your
3 planes actually be stored in a single BO?  It seems to me that if you
could have 3 separate BOs, making use of them on the GL side is way
easier.


pgpPpcgGpeynh.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 4/7] intel: image: add support for more formats.

[Eric Anholt]

On Tue, 24 Apr 2012 17:30:36 +0200, Gwenole Beauchesne  
wrote:
> Add mappings for:
> - DRI_IMAGE_FORMAT_R8
> - DRI_IMAGE_FORMAT_RG88
> - DRI_IMAGE_FORMAT_L8
> - DRI_IMAGE_FIRLAT_LA88

Do you need L and LA if you have R and RG?  We're trying to avoid adding
more deprecated LA usage, particularly given that it's not well
supported in hardware.


pgphFSYhiaQFt.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 1/2] i965: Fix mipmap offsets for HiZ and separate stencil buffers.

[Roland Scheidegger]

Am 24.04.2012 21:23, schrieb Paul Berry:
> When rendering to a miplevel other than 0 within a color, depth,
> stencil, or HiZ buffer, we need to tell the GPU to render to an offset
> within the buffer, so that the data is written into the correct
> miplevel.  We do this using a coarse offset (in pages), and a fine
> adjustment (the so-called "tile_x" and "tile_y" values, which are
> measured in pixels).

Just wondering, can't you get the gpu to do these offset calculations
for you? After all dx10 allows you to have multiple mip levels bound as
a render target at once, where the actual mip level being rendered to is
determined by a system value (GL 3.3 (?) can do the same with the
gl_Layer output of geometry shader). How do you handle that if you have
to adjust the offset manually?

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

Re: [Mesa-dev] [PATCH 1/2] i965: Fix mipmap offsets for HiZ and separate stencil buffers.

[Paul Berry]

On 25 April 2012 11:13, Roland Scheidegger  wrote:

> Am 24.04.2012 21:23, schrieb Paul Berry:
> > When rendering to a miplevel other than 0 within a color, depth,
> > stencil, or HiZ buffer, we need to tell the GPU to render to an offset
> > within the buffer, so that the data is written into the correct
> > miplevel.  We do this using a coarse offset (in pages), and a fine
> > adjustment (the so-called "tile_x" and "tile_y" values, which are
> > measured in pixels).
>
> Just wondering, can't you get the gpu to do these offset calculations
> for you?


In theory yes, but my understanding is that there are enough limitations
that we've elected not to.  The limitations I'm aware of are:

1. Gen6 HiZ buffers (and possibly also separate stencil buffers?) don't
respect the miplevel setting, so if we do this we'll have to do extra work
to get HiZ and separate stencil to work properly.
2. The LOD we're rendering to must match for depth, stencil, and all color
buffers.  AFAICT, GL doesn't require this (though it's possible we might be
able to work around it by reporting GL_FRAMEBUFFER_UNSUPPORTED, I'm not
sure).

The decision was made a long time before I joined the project, so I don't
know the full history.  I would like to do some experiments to try getting
the gpu to do the offset calculations, but I'm not sure when I'll have time
to do that :)


> After all dx10 allows you to have multiple mip levels bound as
> a render target at once, where the actual mip level being rendered to is
> determined by a system value (GL 3.3 (?) can do the same with the
> gl_Layer output of geometry shader). How do you handle that if you have
> to adjust the offset manually?
>

I'm not familiar with dx10, but the GL 3.3 feature you're talking about is
for rendering to multiple layers of 3D textures and texture arrays, and
multiple faces of cubemaps.  It doesn't have anything to do with
miplevels.  We implement gl_Layer yet (since we don't support geometry
shaders) but I just did a quick scan of the docs and it looks like we'll be
able to support it without a problem, since the offsets to get into a
different layer and the offsets to get into a different miplevel are
additive.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Fix mipmap offsets for HiZ and separate stencil buffers.

[Roland Scheidegger]

Am 25.04.2012 21:30, schrieb Paul Berry:
> 
> 
> On 25 April 2012 11:13, Roland Scheidegger  > wrote:
> 
> Am 24.04.2012 21 :23, schrieb Paul Berry:
> > When rendering to a miplevel other than 0 within a color, depth,
> > stencil, or HiZ buffer, we need to tell the GPU to render to an offset
> > within the buffer, so that the data is written into the correct
> > miplevel.  We do this using a coarse offset (in pages), and a fine
> > adjustment (the so-called "tile_x" and "tile_y" values, which are
> > measured in pixels).
> 
> Just wondering, can't you get the gpu to do these offset calculations
> for you?
> 
> 
> In theory yes, but my understanding is that there are enough limitations
> that we've elected not to.  The limitations I'm aware of are:
> 
> 1. Gen6 HiZ buffers (and possibly also separate stencil buffers?) don't
> respect the miplevel setting, so if we do this we'll have to do extra
> work to get HiZ and separate stencil to work properly.
> 2. The LOD we're rendering to must match for depth, stencil, and all
> color buffers.  AFAICT, GL doesn't require this (though it's possible we
> might be able to work around it by reporting GL_FRAMEBUFFER_UNSUPPORTED,
> I'm not sure).
> 
> The decision was made a long time before I joined the project, so I
> don't know the full history.  I would like to do some experiments to try
> getting the gpu to do the offset calculations, but I'm not sure when
> I'll have time to do that :)
>  
> 
> After all dx10 allows you to have multiple mip levels bound as
> a render target at once, where the actual mip level being rendered to is
> determined by a system value (GL 3.3 (?) can do the same with the
> gl_Layer output of geometry shader). How do you handle that if you have
> to adjust the offset manually?
> 
> 
> I'm not familiar with dx10, but the GL 3.3 feature you're talking about
> is for rendering to multiple layers of 3D textures and texture arrays,
> and multiple faces of cubemaps.  It doesn't have anything to do with
> miplevels.  We implement gl_Layer yet (since we don't support geometry
> shaders) but I just did a quick scan of the docs and it looks like we'll
> be able to support it without a problem, since the offsets to get into a
> different layer and the offsets to get into a different miplevel are
> additive.

Ah yes you're right. Both in GL and DX you can only select the layer
from arrays etc. but the mip slice is fixed - well I guess changing the
size of the render target in this way would be really fun :-). So
there's no need the gpu is able to do that on its own (with dx10 IIRC
the size of all render target views must match so you don't have the
problem 2) above which makes things easier).

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

[Mesa-dev] [PATCH 2/2] glsl: Always copy the index when cloning a variable.

[Eric Anholt]

The index is also used for GL_ARB_blend_func_extended.  Cloning in
i965 was dropping a non-ARB_explicit_attrib_location index.
---
 src/glsl/ir_clone.cpp |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index 5a7a71c..5046ac3 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -53,6 +53,7 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht) const
var->invariant = this->invariant;
var->interpolation = this->interpolation;
var->location = this->location;
+   var->index = this->index;
var->warn_extension = this->warn_extension;
var->origin_upper_left = this->origin_upper_left;
var->pixel_center_integer = this->pixel_center_integer;
@@ -72,12 +73,6 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht) 
const
 sizeof(this->state_slots[0]) * var->num_state_slots);
}
 
-   if (this->explicit_location)
-  var->location = this->location;
-
-   if (this->explicit_index)
-  var->index = this->index;
-
if (this->constant_value)
   var->constant_value = this->constant_value->clone(mem_ctx, ht);
 
-- 
1.7.10

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

Re: [Mesa-dev] [PATCH 4/7] intel: image: add support for more formats.

[Gwenole Beauchesne]

Hi,

2012/4/25 Eric Anholt :
> On Tue, 24 Apr 2012 17:30:36 +0200, Gwenole Beauchesne  
> wrote:
>> Add mappings for:
>> - DRI_IMAGE_FORMAT_R8
>> - DRI_IMAGE_FORMAT_RG88
>> - DRI_IMAGE_FORMAT_L8
>> - DRI_IMAGE_FIRLAT_LA88
>
> Do you need L and LA if you have R and RG?  We're trying to avoid adding
> more deprecated LA usage, particularly given that it's not well
> supported in hardware.

My initial tree did not contain L or L+A, I just added them back for
completeness. I don't mind and I actually prefer if we don't have to
support them, that's why I added EXT_texture_rg to ES2 in the first
place. :)

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

Re: [Mesa-dev] [PATCH 0/7] intel: implement DRI image extension v4

[Gwenole Beauchesne]

Hi,

2012/4/25 Eric Anholt :
> On Tue, 24 Apr 2012 17:30:32 +0200, Gwenole Beauchesne  
> wrote:
>>
>> This patch series implements the proposed DRI image extension v4
>> changes to Intel GenX. To be honest, I have not tested the picture
>> structure patch, as I directly adapted it from the VA driver, where
>> interlaced surfaces are correctly handled already.
>>
>> I simplified the hashing stuff to the minimal useful set. i.e. store
>> up to 3 intel_regions into an hash entry. No more variable array of
>> regions.
>
> So, I really don't like this idea.  Is there some requirement that your
> 3 planes actually be stored in a single BO?  It seems to me that if you
> could have 3 separate BOs, making use of them on the GL side is way
> easier.

Yes, the HW uses PLANAR_420 surfaces, with interleaved UV or not.

Is it be possible to create a fake BO, thus with a different name,
that could wrap some master BO at a specific offset?

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

[Mesa-dev] [PATCH] glsl: Remove unused member mem_ctx from ir_dead_functions_visitor.

[Vinson Lee]

Fix uninitialized pointer field defect reported by Coverity.

Signed-off-by: Vinson Lee 
---
 src/glsl/opt_structure_splitting.cpp |1 -
 1 file changed, 1 deletion(-)

diff --git a/src/glsl/opt_structure_splitting.cpp 
b/src/glsl/opt_structure_splitting.cpp
index 6dd228e..a21238d 100644
--- a/src/glsl/opt_structure_splitting.cpp
+++ b/src/glsl/opt_structure_splitting.cpp
@@ -201,7 +201,6 @@ public:
variable_entry2 *get_splitting_entry(ir_variable *var);
 
exec_list *variable_list;
-   void *mem_ctx;
 };
 
 variable_entry2 *
-- 
1.7.9.4

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