On Fri 29 May 2015, Kenneth Graunke wrote:
> On Friday, May 29, 2015 12:33:10 PM Chad Versace wrote:
> > On Fri 29 May 2015, Matt Turner wrote:
> > > On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
> > > > @@ -286,7 +284,7 @@ intel_miptree_create_layout(struct brw_context *brw,
> > > > mt->logic
On Thu 28 May 2015, Ben Widawsky wrote:
> This helped find the incorrect HALIGN values from the previous patches.
>
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/gen8_surface_state.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/gen8_su
On Friday, May 29, 2015 12:33:10 PM Chad Versace wrote:
> On Fri 29 May 2015, Matt Turner wrote:
> > On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
> > > @@ -286,7 +284,7 @@ intel_miptree_create_layout(struct brw_context *brw,
> > > mt->logical_height0 = height0;
> > > mt->logical_depth0 =
On Fri 29 May 2015, Chad Versace wrote:
> On Thu 28 May 2015, Ben Widawsky wrote:
> > This restriction was attempted in this commit:
> > commit 47053464630888f819ef8cc44278f1a1220159b9
> > Author: Anuj Phogat
> > Date: Fri Feb 13 11:21:21 2015 -0800
> >
> >i965/gen8: Use HALIGN_16 if MCS is
On Thu 28 May 2015, Ben Widawsky wrote:
> Just like the previous patch, but for the GEN9 constraints.
>
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
On Thu 28 May 2015, Ben Widawsky wrote:
> This restriction was attempted in this commit:
> commit 47053464630888f819ef8cc44278f1a1220159b9
> Author: Anuj Phogat
> Date: Fri Feb 13 11:21:21 2015 -0800
>
>i965/gen8: Use HALIGN_16 if MCS is enabled for non-MSRT
>
> However, the commit itself
On Fri, May 29, 2015 at 3:17 PM, Liu, Ying2 wrote:
> When we tried to enable EGL on our project, we found that there was no
> pbuffer support for drm platform. I got some help from Alan and Kristian.
> Thank you so much! I studied platform_drm.c and compared it to other
> platforms’ code. Finally
On Fri, May 29, 2015 at 12:26:40PM -0700, Kenneth Graunke wrote:
> See the corresponding code in brw_vs_surface_state.c.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_gs_surface_state.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git
On Fri, May 29, 2015 at 12:26:39PM -0700, Kenneth Graunke wrote:
> We used to store the GS dispatch mode in brw_gs_prog_data while
> separately storing the VS dispatch mode in brw_vue_prog_data::simd8.
>
> This patch introduces an enum to represent all possible dispatch modes,
> and stores it in b
When we tried to enable EGL on our project, we found that there was no pbuffer
support for drm platform. I got some help from Alan and Kristian. Thank you so
much! I studied platform_drm.c and compared it to other platforms' code.
Finally I was able to create this patch to enable pbuffer for drm
On Fri, May 29, 2015 at 12:26:38PM -0700, Kenneth Graunke wrote:
> The documentation makes it pretty clear that we shouldn't use this:
>
>"Under normal conditions SW shall specify DMask, as the GS stage
> will provide a Dispatch Mask appropriate to SIMD4x2 or SIMD8 thread
> execution (
On Fri, May 29, 2015 at 6:53 AM, Neil Roberts wrote:
> Previously when generating the send instruction for a sample
> instruction with an indirect sampler it would use the destination
> register as a temporary store. This breaks when used in combination
> with the opt_sampler_eot optimisation beca
On Fri, May 29, 2015 at 02:53:35PM +0100, Neil Roberts wrote:
> When calculating the binding table index for non-constant sampler
> array indexing it needs to add the base binding table index which is a
> constant within the generated code. Often this base is zero so we can
> avoid a redundant inst
On Fri 29 May 2015, Matt Turner wrote:
> On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
> > @@ -286,7 +284,7 @@ intel_miptree_create_layout(struct brw_context *brw,
> > mt->logical_height0 = height0;
> > mt->logical_depth0 = depth0;
> > mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_NO_M
On Thu 28 May 2015, Ben Widawsky wrote:
> There are several constraints when determining if one can fast clear a
> surface.
> Some of these are alignment, pixel density, tiling formats, and others that
> vary
> by generation. The helper function which exists today does a suitable job,
> however i
The documentation makes it pretty clear that we shouldn't use this:
"Under normal conditions SW shall specify DMask, as the GS stage
will provide a Dispatch Mask appropriate to SIMD4x2 or SIMD8 thread
execution (as a function of dispatch mode). E.g., for SIMD4x2
execution, the GS s
See the corresponding code in brw_vs_surface_state.c.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_gs_surface_state.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_gs_surface_state.c
b/src/mesa/drivers/dri/i965/b
We used to store the GS dispatch mode in brw_gs_prog_data while
separately storing the VS dispatch mode in brw_vue_prog_data::simd8.
This patch introduces an enum to represent all possible dispatch modes,
and stores it in brw_vue_prog_data::dispatch_mode, unifying the two.
Based on a suggestion b
Yes, everything is reviewed.
Marek
On Fri, May 29, 2015 at 8:40 PM, Chad Versace wrote:
> The last two patches, 14-15, are
> Reviewed-by: Chad Versace
>
> I think I've reviewed all the patches in this series. Please let me know
> if I missed any.
___
On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
wrote:
> I think pretty much everyone agrees that having more than a single bool as a
> function argument is bordering on a bad idea. What sucks about the current
> code is in several instances it's necessary to propagate these boolean
> selections do
On Thu 28 May 2015, Ben Widawsky wrote:
> For GEN9, much of the logic to use X-Tiled buffers has been stripped out. It
> is
> still supported in some places, but it's never desirable. Unfortunately we
> don't
> yet have the ability to have Y-Tiled scanout (see:
> http://patchwork.freedesktop.org/
This thing has been trouble since I wrote it. Nice to see it go.
Both patches are:
Reviewed-by: Chris Forbes
On May 30, 2015 6:28 AM, "Matt Turner" wrote:
> On Fri, May 29, 2015 at 6:53 AM, Neil Roberts
> wrote:
> > Previously when generating the send instruction for a sample
> > instruction
On Fri 29 May 2015, Pohjolainen, Topi wrote:
> On Fri, May 29, 2015 at 09:32:53AM +0300, Pohjolainen, Topi wrote:
> > On Thu, May 28, 2015 at 10:21:29AM -0700, Ben Widawsky wrote:
> > > I think pretty much everyone agrees that having more than a single bool
> > > as a
> > > function argument is bo
On Fri, May 29, 2015 at 6:16 AM, Timothy Arceri wrote:
> ---
> src/mesa/main/uniforms.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/src/mesa/main/uniforms.h b/src/mesa/main/uniforms.h
> index 55fa235..bd7b05e 100644
> --- a/src/mesa/main/uniforms.h
> +++ b/src/mesa/main/uniforms.h
On Wed, May 27, 2015 at 10:16 PM, Ben Widawsky
wrote:
> AFAICT, there is no real way to make sure a send message with EOT is properly
> ignored from compact, nor can I see a way to actually encode EOT while
> compacting. Before the single send optimization we'd always bail because we
> hit
> the
The last two patches, 14-15, are
Reviewed-by: Chad Versace
I think I've reviewed all the patches in this series. Please let me know
if I missed any.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/m
On Thu 28 May 2015, Marek Olšák wrote:
> A new patch is attached. Please review.
>
Looks good to me.
Reviewed-by: Chad Versace
Later, if and when some platform extension defines a pointer-sized
attribute, then we will need to invert the function order. That is,
eglGetPlatformDisplayEXT will the
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, May 29, 2015 at 6:53 AM, Neil Roberts wrote:
> Previously when generating the send instruction for a sample
> instruction with an indirect sampler it would use the destination
> register as a temporary store. This breaks when used in combination
> with the opt_sampler_eot optimisation beca
On Thu 28 May 2015, Marek Olšák wrote:
> A new patch is attached. Please review.
LGTM.
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu 28 May 2015, Eirik Byrkjeflot Anonsen wrote:
> Marek Olšák writes:
>
> > I don't understand. Using size_t should prevent the integer overflow.
> > Is there anything else wrong other than no fail path for malloc? I
> > also don't understand how calloc can help here.
> >
> > Marek
>
> "size
On Fri, May 29, 2015 at 10:38 AM, Brian Paul wrote:
> _mesa_override_gl_version_contextless() takes an unsigned version
> parameter.
> ---
> 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/
_mesa_override_gl_version_contextless() takes an unsigned version
parameter.
---
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 2d847ef..66f9eaa 100644
On Thu 28 May 2015, Marek Olšák wrote:
> Hi Chad,
>
> A new patch is attached.
Thanks for the changes. This patch is
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-d
On Fri, May 29, 2015 at 6:23 AM, Eero Tamminen
wrote:
> Hi,
>
> On 05/28/2015 10:19 PM, Thomas Helland wrote:
>>
>> One more thing;
>> Is there a limit where the loop body gets so large that we
>> want to decide that "gah, this sucks, no point in unrolling this"?
>> I imagine as the loops get larg
Sometimes, having to translate from one to the other seems like
unnecessary annoyance.
Marek
On Fri, May 29, 2015 at 3:59 PM, Brian Paul wrote:
> On 05/28/2015 05:36 PM, Marek Olšák wrote:
>>
>> Hi,
>>
>> Would people be okay with removing the TGSI_PROCESSOR_ enums and
>> replacing all usages wi
Please ignore the first two patches turns out the name generation is
used for structs (although there seems to be no piglit tests for this)
like:
struct S {
sampler2D tex[2];
};
uniform S i[3];
Where name would become: i[2].tex
On Fri, 2015-05-29 at 23:16 +1000, Timothy Arceri wrote:
> The
On 05/28/2015 05:36 PM, Marek Olšák wrote:
Hi,
Would people be okay with removing the TGSI_PROCESSOR_ enums and
replacing all usages with PIPE_SHADER_*?
It's kind of nice that the TGSI shader stuff is self-contained with no
real dependency on gallium. This would change that in a tiny way.
When calculating the binding table index for non-constant sampler
array indexing it needs to add the base binding table index which is a
constant within the generated code. Often this base is zero so we can
avoid a redundant instruction in that case.
It looks like nothing in shader-db is doing non
Previously when generating the send instruction for a sample
instruction with an indirect sampler it would use the destination
register as a temporary store. This breaks when used in combination
with the opt_sampler_eot optimisation because that forces the
destination to be null. This patch fixes t
For the series,
Reviewed-by: Brian Paul
On 05/28/2015 05:57 PM, Marek Olšák wrote:
From: Marek Olšák
These states are for GS assembly shaders only. We don't support those.
---
src/mesa/main/context.c| 1 -
src/mesa/main/mtypes.h | 7 ---
src/mesa/main/shared.c | 1 -
src
Reviewed-by: Brian Paul
On 05/29/2015 05:10 AM, Jose Fonseca wrote:
Rendering from multiple processes into the same X window is not
something that works in practice anymore.
Nowadays interprocess rendering is better done with GLX/EGL extensions
for that effect.
https://bugs.freedesktop.org/s
It's incompletete -- it wasn't filling ReferenceType so it was causing
garbagge on the disassembly. Furthermore it seems impossible to get the
jump information through this interface.
The solution for function size problem is to effectively book-keep the
machine code start and end address while J
This logic was recreated based on the old glsl ir code.
The name was only generated for arrays of arrays in which
case this just breaks the Uniform hash lookup.
---
src/glsl/nir/nir_lower_samplers.cpp | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/glsl/nir/nir
---
src/mesa/main/uniforms.h | 4
1 file changed, 4 deletions(-)
diff --git a/src/mesa/main/uniforms.h b/src/mesa/main/uniforms.h
index 55fa235..bd7b05e 100644
--- a/src/mesa/main/uniforms.h
+++ b/src/mesa/main/uniforms.h
@@ -343,10 +343,6 @@ void GLAPIENTRY
_mesa_ProgramUniformMatrix4x3dv(
The warning is now handled earlier in the ast to hir code,
and the name was only generated for arrays of arrays in which
case this just breaks the Uniform hash lookup.
---
src/mesa/program/sampler.cpp | 38 +-
1 file changed, 13 insertions(+), 25 deletions(-)
d
On 28/05/15 19:26, Roland Scheidegger wrote:
Looks ok, it's massively simpler and shouldn't break as often.
Reviewed-by: Roland Scheidegger
Am 28.05.2015 um 17:57 schrieb Jose Fonseca:
It doesn't do everything we want. In particular it doesn't allow to
detect jumps or return opcodes. Curren
Rendering from multiple processes into the same X window is not
something that works in practice anymore.
Nowadays interprocess rendering is better done with GLX/EGL extensions
for that effect.
https://bugs.freedesktop.org/show_bug.cgi?id=30279
---
src/xdemos/.gitignore | 1 -
src/xdemos/C
Sorry , it is v1 not v5 ( for Pineview platform :
http://ark.intel.com/products/codename/32201/Pineview)
> -Original Message-
> From: Predut, Marius
> Sent: Friday, May 29, 2015 2:51 PM
> To: mesa-dev@lists.freedesktop.org
> Cc: Predut, Marius
> Subject: [Mesa-dev][PATCH v5] i915/aa: fixi
On PNV platform, for 1 pixel line thickness or less,
the general anti-aliasing algorithm gives up, and a garbage line is generated.
Setting a Line Width of 0.0 specifies the rasterization
of the "thinnest" (one-pixel-wide), non-antialiased lines.
Lines rendered with zero Line Width are rasterized u
Hi,
On 05/28/2015 10:19 PM, Thomas Helland wrote:
One more thing;
Is there a limit where the loop body gets so large that we
want to decide that "gah, this sucks, no point in unrolling this"?
I imagine as the loops get large there will be a case of
diminishing returns from the unrolling?
I thi
https://bugs.freedesktop.org/show_bug.cgi?id=30279
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hi Ian,
On 29.05.2015 09:00, i...@kemper.freedesktop.org (Ian Romanick) wrote:
> Module: Mesa
> Branch: master
> Commit: 9b5e92f4ccc6ee1cb9caea947f6efaad2b391cf1
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9b5e92f4ccc6ee1cb9caea947f6efaad2b391cf1
>
> Author: Ian Romanick
> Da
53 matches
Mail list logo
