On Thu, May 28, 2015 at 10:21:32AM -0700, Ben Widawsky wrote:
This restriction was attempted in this commit:
commit 47053464630888f819ef8cc44278f1a1220159b9
Author: Anuj Phogat anuj.pho...@gmail.com
Date: Fri Feb 13 11:21:21 2015 -0800
i965/gen8: Use HALIGN_16 if MCS is enabled for
On Thu, May 28, 2015 at 10:21:33AM -0700, Ben Widawsky wrote:
Just like the previous patch, but for the GEN9 constraints.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +
1 file changed, 5 insertions(+)
diff --git
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 bordering on a bad idea. What sucks about the current
code is in
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 bordering on a bad idea. What sucks about the current
code is in several instances it's necessary to propagate these boolean
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
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
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 srol...@vmware.com
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
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
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 -
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: fixing
https://bugs.freedesktop.org/show_bug.cgi?id=30279
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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(-)
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
Reviewed-by: Brian Paul bri...@vmware.com
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.
---
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
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
For the series,
Reviewed-by: Brian Paul bri...@vmware.com
On 05/28/2015 05:57 PM, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
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 ---
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
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.
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
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 Fri, May 29, 2015 at 6:23 AM, Eero Tamminen
eero.t.tammi...@intel.com 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
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 chad.vers...@intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
_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
Reviewed-by: Matt Turner matts...@gmail.com
___
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 mar...@gmail.com 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
On Fri, May 29, 2015 at 6:16 AM, Timothy Arceri t_arc...@yahoo.com.au 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
+++
On Fri, May 29, 2015 at 10:38 AM, Brian Paul bri...@vmware.com 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
On Fri, May 29, 2015 at 6:53 AM, Neil Roberts n...@linux.intel.com 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
On Thu 28 May 2015, Marek Olšák wrote:
A new patch is attached. Please review.
Looks good to me.
Reviewed-by: Chad Versace chad.vers...@intel.com
Later, if and when some platform extension defines a pointer-sized
attribute, then we will need to invert the function order. That is,
The last two patches, 14-15, are
Reviewed-by: Chad Versace chad.vers...@intel.com
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
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
On Thu 28 May 2015, Ben Widawsky wrote:
This helped find the incorrect HALIGN values from the previous patches.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 4
1 file changed, 4 insertions(+)
diff --git
On Thu 28 May 2015, Ben Widawsky wrote:
This restriction was attempted in this commit:
commit 47053464630888f819ef8cc44278f1a1220159b9
Author: Anuj Phogat anuj.pho...@gmail.com
Date: Fri Feb 13 11:21:21 2015 -0800
i965/gen8: Use HALIGN_16 if MCS is enabled for non-MSRT
However, the
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 (as a
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
On Fri, May 29, 2015 at 3:17 PM, Liu, Ying2 ying2@intel.com 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
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-logical_height0 =
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_gs_surface_state.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
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 anuj.pho...@gmail.com
Date: Fri Feb 13 11:21:21 2015 -0800
i965/gen8: Use HALIGN_16
On Thu 28 May 2015, Ben Widawsky wrote:
Just like the previous patch, but for the GEN9 constraints.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +
1 file changed, 5 insertions(+)
diff --git
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 = depth0;
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 bordering on
This thing has been trouble since I wrote it. Nice to see it go.
Both patches are:
Reviewed-by: Chris Forbes chr...@ijw.co.nz
On May 30, 2015 6:28 AM, Matt Turner matts...@gmail.com wrote:
On Fri, May 29, 2015 at 6:53 AM, Neil Roberts n...@linux.intel.com
wrote:
Previously when generating
See the corresponding code in brw_vs_surface_state.c.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
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
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:
On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
benjamin.widaw...@intel.com 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
Yes, everything is reviewed.
Marek
On Fri, May 29, 2015 at 8:40 PM, Chad Versace chad.vers...@intel.com wrote:
The last two patches, 14-15, are
Reviewed-by: Chad Versace chad.vers...@intel.com
I think I've reviewed all the patches in this series. Please let me know
if I missed any.
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 it
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_MCS;
-
On Thu 28 May 2015, Marek Olšák wrote:
A new patch is attached. Please review.
LGTM.
Reviewed-by: Chad Versace chad.vers...@intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, May 27, 2015 at 10:16 PM, Ben Widawsky
benjamin.widaw...@intel.com 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
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 bri...@vmware.com 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
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
On Fri, May 29, 2015 at 6:53 AM, Neil Roberts n...@linux.intel.com 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
57 matches
Mail list logo
