Maybe value.f[0] since it's an array and not a pointer? Other than that,
Reviewed-by: Connor Abbott
On Sat, Feb 7, 2015 at 12:16 AM, Eric Anholt wrote:
> We want the size of a float per component, not the size of a whole vec4.
>
> NIR instructions on i965:
> total instructions in shared program
On Sat, Feb 7, 2015 at 12:16 AM, Eric Anholt wrote:
> NIR instruction count results on i965:
> total instructions in shared programs: 1261954 -> 1261937 (-0.00%)
> instructions in affected programs: 455 -> 438 (-3.74%)
>
> One in yofrankie, two in tropics. Apparently i965 had also optimized a
Reviewed-by: Jason Ekstrand
On Feb 6, 2015 9:16 PM, "Eric Anholt" wrote:
> No change on shader-db on i965.
> ---
> src/glsl/nir/nir_opt_algebraic.py | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/glsl/nir/nir_opt_algebraic.py
> b/src/glsl/nir/nir_opt_algebraic.py
> index
Reviewed-by: Connor Abbott
On Sat, Feb 7, 2015 at 12:16 AM, Eric Anholt wrote:
> No change on shader-db on i965.
> ---
> src/glsl/nir/nir_opt_algebraic.py | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/glsl/nir/nir_opt_algebraic.py
> b/src/glsl/nir/nir_opt_algebraic.py
>
We want the size of a float per component, not the size of a whole vec4.
NIR instructions on i965:
total instructions in shared programs: 1261937 -> 1261929 (-0.00%)
instructions in affected programs: 114 -> 106 (-7.02%)
Looking at one of these examples (tesseract), it's from vec4 load_consts
No change on shader-db on i965.
---
src/glsl/nir/nir_opt_algebraic.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/nir/nir_opt_algebraic.py
b/src/glsl/nir/nir_opt_algebraic.py
index a5fe19a..0512a8f 100644
--- a/src/glsl/nir/nir_opt_algebraic.py
+++ b/src/glsl/nir/nir_opt
NIR instruction count results on i965:
total instructions in shared programs: 1261954 -> 1261937 (-0.00%)
instructions in affected programs: 455 -> 438 (-3.74%)
One in yofrankie, two in tropics. Apparently i965 had also optimized all
of these out anyway.
---
src/glsl/nir/nir_opt_cse.c | 43 +
Jason Ekstrand writes:
> Previously, the hash_table_insert function would bail early if it found a
> deleted slot that it could re-use. However, this is a problem if the key
> being inserted is already in the hash table but further down the list. If
> this happens, the element ends up getting i
Hi Eric,
Sorry for not responding to this in a while. I'm replying to this
comment instead of the new version because it has the relevant
discussion.
On Mon, Feb 2, 2015 at 7:30 PM, Eric Anholt wrote:
> Connor Abbott writes:
>
>> I mentioned this on IRC, but it would be good to add the ability
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 7 February 2015 at 00:10, Matt Turner wrote:
> On Fri, Feb 6, 2015 at 3:58 PM, Emil Velikov wrote:
>>> "util" is meant to be for shared utility across the entire code base -
>>> both Mesa and Gallium. It's been growing slowly as people move things
>>> there. It might make sense to move a lot
On Saturday, February 07, 2015 02:10:19 AM Francisco Jerez wrote:
> Matt Turner writes:
>
> > On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez
> > wrote:
> >> Scalar registers are required to have zero stride, fix the
> >> regs_written calculation not to assume that the instruction writes
> >> z
On Fri, Feb 6, 2015 at 7:22 PM, Jason Ekstrand wrote:
>
>
> On Fri, Feb 6, 2015 at 5:38 PM, Connor Abbott wrote:
>>
>> On Fri, Feb 6, 2015 at 5:12 PM, Jason Ekstrand
>> wrote:
>> > This is mostly thanks to Connor. The idea is to do a depth-first search
>> > that computes pre and post indices fo
On Saturday, February 07, 2015 03:03:44 AM Francisco Jerez wrote:
> Kenneth Graunke writes:
>
> > On Friday, February 06, 2015 07:23:16 PM Francisco Jerez wrote:
> >> Reviewed-by: Paul Berry
> >> ---
> >> src/mesa/drivers/dri/i965/brw_context.h | 5 +
> >> src/mesa/drivers/dri/i965/brw_sha
Kenneth Graunke writes:
> On Friday, February 06, 2015 07:23:16 PM Francisco Jerez wrote:
>> Reviewed-by: Paul Berry
>> ---
>> src/mesa/drivers/dri/i965/brw_context.h | 5 +
>> src/mesa/drivers/dri/i965/brw_shader.cpp | 7 +++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/sr
On Saturday, February 07, 2015 02:46:31 AM Francisco Jerez wrote:
> Kenneth Graunke writes:
>
> > On Friday, February 06, 2015 07:23:15 PM Francisco Jerez wrote:
> >> It doesn't really improve locality of texture fetches, quite the
> >> opposite it's a waste of memory bandwidth and space due to t
Mesa 10.4.4 has been released. Mesa 10.4.4 is a bug fix release
fixing bugs since the 10.4.3 release, (see below for a list of
changes).
The tag in the git repository for Mesa 10.4.4 is 'mesa-10.4.4'.
Mesa 10.4.4 is available for download at
ftp://freedesktop.org/pub/mesa/10.4.4/
SHA-256 checksu
Kenneth Graunke writes:
> On Friday, February 06, 2015 07:23:15 PM Francisco Jerez wrote:
>> It doesn't really improve locality of texture fetches, quite the
>> opposite it's a waste of memory bandwidth and space due to tile
>> alignment.
>> ---
>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c |
On Fri, 06 Feb 2015 17:08:46 +0100, Marek Olšák wrote:
Please bump the size of vgt_state for the SQ_VTX_BASE_VTX_LOC
register. It's set by r600_init_atom in r600_state.c and
evergreen_state.c
Please bump R600_MAX_DRAW_CS_DWORDS. It's an upper bound of how many
dwords draw_vbo can emit.
Than
On 02/06/2015 05:10 PM, Matt Turner wrote:
On Fri, Feb 6, 2015 at 3:58 PM, Emil Velikov wrote:
"util" is meant to be for shared utility across the entire code base -
both Mesa and Gallium. It's been growing slowly as people move things
there. It might make sense to move a lot of src/gallium/a
On Fri, Feb 6, 2015 at 5:38 PM, Connor Abbott wrote:
> On Fri, Feb 6, 2015 at 5:12 PM, Jason Ekstrand
> wrote:
> > This is mostly thanks to Connor. The idea is to do a depth-first search
> > that computes pre and post indices for all the blocks. We can then
> figure
> > out if one block domina
On Friday, February 06, 2015 11:58:52 PM Emil Velikov wrote:
[snip]
> If I can speculate - I would assume that bikeshedding is one of the
> reasons why things got copied over into gallium. People chose to have
> some form of explicit structure and naming scheme, that will be easier
> to follow as t
Matt Turner writes:
> On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
>> If the source type differs from the original type of the constant we
>> need to bit-cast it before propagating, otherwise the original type
>> information will be lost. If the constant was a vector float there
>> is
On Fri, Feb 6, 2015 at 5:34 PM, Connor Abbott wrote:
> I'd rather keep it the way it was, since that's how it's presented as
> pseudocode in the paper and someone reading this is more likely to be
> confused by a function with the exact same name as in the paper but a
> different implementation.
On Fri, Feb 6, 2015 at 3:58 PM, Emil Velikov wrote:
>> "util" is meant to be for shared utility across the entire code base -
>> both Mesa and Gallium. It's been growing slowly as people move things
>> there. It might make sense to move a lot of src/gallium/auxiliary/util
>> there, in fact - the
Matt Turner writes:
> On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
>> Scalar registers are required to have zero stride, fix the
>> regs_written calculation not to assume that the instruction writes
>> zero registers in that case.
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 ++-
Hey Matt,
Matt Turner writes:
> On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
>> MRFs cannot be read from anyway so they cannot possibly be a valid
>> source of LOAD_PAYLOAD.
>> ---
>
> The function only seems to test inst->dst.file == MRF. I don't see any
> code for handling MRF sourc
v2: Rebase on the nir_opcodes.h python code generation support.
v3: Use SSA values, and set an appropriate writemask on dot products.
v4: Make the arguments be SSA references as well. This lets you stack up
expressions in the arguments of other expressions, at the cost of
having to insert
Hi all,
Fwiw, I'm 100% behind Jose's arguments, let me try and justify why:
On 4 February 2015 at 20:18, Kenneth Graunke wrote:
> On Wednesday, February 04, 2015 02:04:38 PM Jose Fonseca wrote:
>> This change broke MinGW/MSVC builds because ffsll is not available there.
>>
>>
>> There is a ffsll
On Fri, Feb 06, 2015 at 08:11:51AM -0700, Brian Paul wrote:
> On 02/06/2015 04:38 AM, Jonathan Gray wrote:
> >OpenBSD has ffs in libc but does not have ffsll so use the compiler
> >builtin. PIPE_OS_BSD isn't suitable here as FreeBSD has ffsll in libc.
> >
> >Signed-off-by: Jonathan Gray
> >---
>
On Fri, Feb 6, 2015 at 6:43 AM, Francisco Jerez wrote:
> It's expanded to several instructions.
> ---
I was going to say that I suspect this needs to go before some of the
previous patches to avoid assertions in debug builds, but even in
master we're emitting multiple instructions on Gen8. I gues
On Fri, Feb 6, 2015 at 12:44 PM, Matt Turner wrote:
> Since there's no cover letter, I'll respond to this patch as I review
> things. Patches 1-7 are
>
> Reviewed-by: Matt Turner
8 - Sent a question
9 - Like mine better?
10 - Looks wrong to me
11-13 - Asked Jason to review
14 - Asked for an exam
Reviewed-by: Connor Abbott
On Fri, Feb 6, 2015 at 5:12 PM, Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir_from_ssa.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
> index 2e7add3..3625237 100644
> ---
On Fri, Feb 06 2015, Aaron Watry wrote:
> Ignore me if this is a stupid question, but should those both be
> sizeof(short)? I'd expect the first to be sizeof(char).
Not a stupid question. That was a copy-and-paste (kill-and-yank ?) bug
of mine.
Thanks for your attention to detail. I've fixed thi
On Fri, Feb 6, 2015 at 5:12 PM, Jason Ekstrand wrote:
> This is mostly thanks to Connor. The idea is to do a depth-first search
> that computes pre and post indices for all the blocks. We can then figure
> out if one block dominates another in constant time by two simple
> comparison operations.
I'd rather keep it the way it was, since that's how it's presented as
pseudocode in the paper and someone reading this is more likely to be
confused by a function with the exact same name as in the paper but a
different implementation.
On Fri, Feb 6, 2015 at 5:12 PM, Jason Ekstrand wrote:
> Befor
With the patches I just sent, we'll drop this from the series and use the
nir_dominance_lca function in GCM instead.
On Thu, Feb 5, 2015 at 3:42 PM, Connor Abbott wrote:
> Reviewed-by: Connor Abbott
>
> On Thu, Feb 5, 2015 at 5:29 PM, Jason Ekstrand
> wrote:
> > ---
> > src/glsl/nir/nir.h
---
src/glsl/nir/nir_from_ssa.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index 2e7add3..3625237 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -54,13 +54,8 @@ ssa_def_domina
This is mostly thanks to Connor. The idea is to do a depth-first search
that computes pre and post indices for all the blocks. We can then figure
out if one block dominates another in constant time by two simple
comparison operations.
---
src/glsl/nir/nir.h | 9 +
src/glsl/nir
Before the function involved three loops and three different branching
conditions. Now it involves one loop and one if statement. This is a
little simpler.
---
src/glsl/nir/nir.h | 2 ++
src/glsl/nir/nir_dominance.c | 16 ++--
2 files changed, 16 insertions(+), 2 deletions
On Fri, Feb 6, 2015 at 6:43 AM, Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_ir_vec4.h | 1 +
> src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 15 ++-
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 17
> +
> 3 f
On Fri, Feb 6, 2015 at 2:50 AM, Pohjolainen, Topi
wrote:
> On Fri, Feb 06, 2015 at 09:18:35AM +0200, Ian Romanick wrote:
>> On 02/06/2015 06:56 AM, Ilia Mirkin wrote:
>> > From: Dave Airlie
>> >
>> > This adds support for the new uniform interfaces
>> > from ARB_gpu_shader_fp64.
>> >
>> > v2:
>>
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> So regs_written gets initialized with a sensible value.
> ---
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.c
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index c3f68e6..aaa4873 100644
> ---
On Fri, Feb 6, 2015 at 9:23 AM, Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_program.c | 40
> +
> src/mesa/drivers/dri/i965/intel_reg.h | 1 +
> 2 files changed, 41 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> If the source type differs from the original type of the constant we
> need to bit-cast it before propagating, otherwise the original type
> information will be lost. If the constant was a vector float there
> isn't much we can do, because
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> Fixes rewrite by the register coalesce pass of references to
> individual halves of 16-wide coalesced registers.
> ---
> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
On Fri, Feb 6, 2015 at 9:42 AM, Francisco Jerez wrote:
> Right now virtual GRF book-keeping and allocation is performed in each
> visitor class separately (among other hundred different things),
> leading to duplicated logic in each visitor and preventing layering as
> it forces any code that mani
On Fri, 06 Feb 2015 20:53:21 +0100, Roland Scheidegger
wrote:
FWIW I'm wondering why you'd actually need them in a d3d9 state tracker,
as this is a feature first seen with d3d10. Unless you'd want to handle
d3d10 of course, but in this case there's probably not much hope for any
of the d3d9 c
On Fri, Feb 6, 2015 at 1:43 PM, Carl Worth wrote:
> This provides for atomic addition, which will be used by an upcoming
> shader-cache patch. A simple test is added to "make check" as well.
>
> Note: The various O/S functions differ on whether they return the
> original value or the value after
On Fri, Feb 6, 2015 at 12:53 PM, Matt Turner wrote:
> Patches 12 and 13 seem plausible, but I'd like Jason to review them.
> (And #11 pending my question about it)
Sorry, I meant 11-13 and #10 pending my question.
___
mesa-dev mailing list
mesa-dev@list
Patches 12 and 13 seem plausible, but I'd like Jason to review them.
(And #11 pending my question about it)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Looks good to me. We may need to tighten that up at some point but I
wouldn't know how yet.
Roland
Am 06.02.2015 um 20:08 schrieb Marek Olšák:
> The updated patch is attached. It allows both (0,0,0,0) and (0,0,0,1).
>
> Marek
>
> On Mon, Feb 2, 2015 at 5:19 PM, Roland Scheidegger wrote:
>> Act
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> MRFs cannot be read from anyway so they cannot possibly be a valid
> source of LOAD_PAYLOAD.
> ---
The function only seems to test inst->dst.file == MRF. I don't see any
code for handling MRF sources. What am I missing?
On Friday, February 06, 2015 07:23:27 PM Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_defines.h | 3 +++
> src/mesa/drivers/dri/i965/gen7_wm_state.c| 7 +++
> src/mesa/drivers/dri/i965/gen8_depth_state.c | 12
> src/mesa/drivers/dri/i965/gen8_ps_state.c
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> Scalar registers are required to have zero stride, fix the
> regs_written calculation not to assume that the instruction writes
> zero registers in that case.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 ++-
> 1 file changed, 2 inserti
Since there's no cover letter, I'll respond to this patch as I review
things. Patches 1-7 are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> Using 'ralloc*(this, ...)' is wrong if the object has automatic
> storage or was allocated through any other means. Use normal dynamic
> memory instead.
> ---
I don't see any places we were allocating an fs_inst via a mechanism
other than
On Friday, February 06, 2015 07:23:26 PM Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_defines.h | 3 +++
> src/mesa/drivers/dri/i965/gen7_gs_state.c | 4 +++-
> src/mesa/drivers/dri/i965/gen7_vs_state.c | 13 -
> src/mesa/drivers/dri/i965/gen7_wm_state.c | 3 +++
>
On Friday, February 06, 2015 07:23:28 PM Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_program.c | 40
> +
> src/mesa/drivers/dri/i965/intel_reg.h | 1 +
> 2 files changed, 41 insertions(+)
Reviewed-by: Kenneth Graunke
signature.asc
Descriptio
On Friday, February 06, 2015 07:23:25 PM Francisco Jerez wrote:
> Shaders with image uniforms may have side effects. Make sure that
> fragment shader threads are dispatched if the shader has any image
> uniforms.
> ---
> src/mesa/drivers/dri/i965/gen7_wm_state.c | 6 +-
> 1 file changed, 5 in
Am 06.02.2015 um 13:11 schrieb Iago Toral:
> Hi,
>
> Eduardo and I have been looking into a few dEQP test failures that deal
> with wide line rendering. There are a few of them that fail because of
> how clipping is implemented for this case.
>
> The problem in these cases seems to be that the hw
On Fri, Feb 6, 2015 at 11:43 AM, Carl Worth wrote:
> This provides for atomic addition, which will be used by an upcoming
> shader-cache patch. A simple test is added to "make check" as well.
>
> Note: The various O/S functions differ on whether they return the
> original value or the value after
On Fri, Feb 6, 2015 at 4:47 AM, Ian Romanick wrote:
> On 02/06/2015 02:32 PM, Kenneth Graunke wrote:
>> This should have no effect, but will make it easier to implement other
>> bug fixes.
>>
>> Signed-off-by: Kenneth Graunke
>> Cc: Chris Forbes
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>
On Friday, February 06, 2015 07:23:20 PM Francisco Jerez wrote:
> Null surfaces are going to be useful to have something to point
> unbound image units to, as the ARB_shader_image_load_store extension
> requires us to behave deterministically in cases where some shader
> tries to access an unbound
On Friday, February 06, 2015 07:23:16 PM Francisco Jerez wrote:
> Reviewed-by: Paul Berry
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 5 +
> src/mesa/drivers/dri/i965/brw_shader.cpp | 7 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context
On Friday, February 06, 2015 07:23:15 PM Francisco Jerez wrote:
> It doesn't really improve locality of texture fetches, quite the
> opposite it's a waste of memory bandwidth and space due to tile
> alignment.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4
> 1 file changed, 4 inse
On Fri, Feb 6, 2015 at 3:38 AM, Jonathan Gray wrote:
> OpenBSD has ffs in libc but does not have ffsll so use the compiler
> builtin. PIPE_OS_BSD isn't suitable here as FreeBSD has ffsll in libc.
>
> Signed-off-by: Jonathan Gray
> ---
> src/gallium/auxiliary/util/u_math.h | 2 ++
> 1 file chang
FWIW I'm wondering why you'd actually need them in a d3d9 state tracker,
as this is a feature first seen with d3d10. Unless you'd want to handle
d3d10 of course, but in this case there's probably not much hope for any
of the d3d9 capable hw drivers for lots of reasons...
Roland
Am 06.02.2015 um 1
This provides for atomic addition, which will be used by an upcoming
shader-cache patch. A simple test is added to "make check" as well.
Note: The various O/S functions differ on whether they return the
original value or the value after the addition, so I did not provide
an add_return() macro whic
The updated patch is attached. It allows both (0,0,0,0) and (0,0,0,1).
Marek
On Mon, Feb 2, 2015 at 5:19 PM, Roland Scheidegger wrote:
> Actually, since ARB_robust_buffer_access_behavior, GL requires some
> specfic values, but it's - odd...
> "In all the above cases, if the context was created w
I pushed both patches. Thanks.
Marek
On Sat, Jan 31, 2015 at 1:36 AM, Xavier B. wrote:
> r600g/sb: fix a bug in constants folding optimisation
> pass:
>
> ADD R6.y.1,R5.w.1, ~1|3f80
> ADD R6.y.2,|R6.y.1|, -0.0001|b8d1b717
>
> was wrongly being converted to
>
> AD
RadeonProgram page just removed.
2015-02-05 20:52 GMT+01:00 Alex Deucher :
> On Thu, Feb 5, 2015 at 2:47 PM, Benjamin Bellec
> wrote:
> > And what about removing the "RadeonProgram" page [1] ?
> >
> > From my point of view, this page depicts a wrong picture of the Radeon
> Mesa
> > driver. While
Looks good to me.
Reviewed-by: Chris Forbes
On Sat, Feb 7, 2015 at 1:32 AM, Kenneth Graunke wrote:
> +82 Piglits - 100% of border color tests now pass on Haswell.
>
> Signed-off-by: Kenneth Graunke
> Cc: Chris Forbes
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/drivers/dri/i965/b
On Fri, Feb 6, 2015 at 1:03 PM, Tiziano Bacocco wrote:
> Without this when an application issues that query,
> it would try to wait the result from the gpu, and since no query has
> been actually issued, it will wait for ever
>
> Signed-off-by: Tiziano Bacocco
Reviewed-by: Ilia Mirkin
Although
On Thu, Feb 5, 2015 at 7:36 PM, Ben Widawsky wrote:
> On Wed, Jan 14, 2015 at 10:34:52AM -0800, Jason Ekstrand wrote:
> > On Tue, Jan 13, 2015 at 11:37 PM, Ben Widawsky <
> benjamin.widaw...@intel.com>
> > wrote:
> >
> > > This patch will use a new calculation to determine if a surface can be
> >
You seem to be right about 2 things: Your implementation and the fact that
it's entirely INSANE! I checked and double-checked the bspec and this
looks correct. I trust you with the rest of the state bits.
Reviewed-by: Jason Ekstrand
On Fri, Feb 6, 2015 at 4:32 AM, Kenneth Graunke
wrote:
> +8
Without this when an application issues that query,
it would try to wait the result from the gpu, and since no query has
been actually issued, it will wait for ever
Signed-off-by: Tiziano Bacocco
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_quer
---
src/mesa/drivers/dri/i965/brw_defines.h | 3 +++
src/mesa/drivers/dri/i965/gen7_wm_state.c| 7 +++
src/mesa/drivers/dri/i965/gen8_depth_state.c | 12
src/mesa/drivers/dri/i965/gen8_ps_state.c| 13 +
4 files changed, 31 insertions(+), 4 deletions(-)
This moves most of the surface state set-up logic that can be shared
between textures and shader images to a separate function.
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 136 ++---
1 file changed, 77 insertions(+), 59 deletions(-)
diff --git a/src/mesa/drivers/dri/i
---
src/mesa/drivers/dri/i965/brw_defines.h | 3 +++
src/mesa/drivers/dri/i965/gen7_gs_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen7_vs_state.c | 13 -
src/mesa/drivers/dri/i965/gen7_wm_state.c | 3 +++
src/mesa/drivers/dri/i965/gen8_gs_state.c | 4 +++-
src/mesa/drivers/dri/i
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +
src/mesa/drivers/dri/i965/brw_surface_formats.c | 111 +++
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 77
3 files changed, 190 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cont
---
src/mesa/drivers/dri/i965/brw_tex_layout.c| 45 +--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 18 +++
2 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layou
Null surfaces are going to be useful to have something to point
unbound image units to, as the ARB_shader_image_load_store extension
requires us to behave deterministically in cases where some shader
tries to access an unbound image unit: Invalid stores and atomics are
supposed to be discarded and
---
src/mesa/drivers/dri/i965/brw_gs.c | 1 +
src/mesa/drivers/dri/i965/brw_vs.c | 4 ++--
src/mesa/drivers/dri/i965/brw_wm.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index ce3cba4..bfb64f3 1006
This moves most of the surface state set-up logic that can be shared
between textures and shader images to a separate function.
---
src/mesa/drivers/dri/i965/brw_context.h | 11 ++
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 124 +-
2 files changed, 83 insert
---
src/mesa/drivers/dri/i965/brw_context.h | 8 +++-
src/mesa/drivers/dri/i965/brw_gs_surface_state.c | 25
src/mesa/drivers/dri/i965/brw_state.h| 3 ++
src/mesa/drivers/dri/i965/brw_state_upload.c | 10 +
src/mesa/drivers/dri/i965/brw_vs_surface_state.
Shaders with image uniforms may have side effects. Make sure that
fragment shader threads are dispatched if the shader has any image
uniforms.
---
src/mesa/drivers/dri/i965/gen7_wm_state.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_s
Ok, I'll do.
About MAX_PREDS, maybe it's time to bring it out again :)
On 02/06/2015 06:16 PM, Marek Olšák wrote:
You can update MAX_PREDS in this patch.
I proposed removing predicates a long time ago, but some people disagreed.
Marek
On Fri, Feb 6, 2015 at 5:19 PM, David Heidelberg wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #24 from Grimdoll ---
1) This game works with option d3dx9 libs setted as native, with builtin it
would not work at all;
2) I don't know how to use stable mesa, I tried to revert to standard Ubuntu
drivers by:
$ sudo apt-get install p
---
src/mesa/drivers/dri/i965/brw_program.c | 40 +
src/mesa/drivers/dri/i965/intel_reg.h | 1 +
2 files changed, 41 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index d9a3f05..793d963 100644
--- a
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.h | 5 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 7 +++
2 files changed, 12 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index bebb0be..e28c65d 100644
--
This will be used to pass image meta-data to the shader when we cannot
use typed surface reads and writes. All entries except surface_idx
and size are otherwise unused and will get eliminated by the uniform
packing pass. size will be used for bounds checking with some image
formats and will be us
It doesn't really improve locality of texture fetches, quite the
opposite it's a waste of memory bandwidth and space due to tile
alignment.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src
You can update MAX_PREDS in this patch.
I proposed removing predicates a long time ago, but some people disagreed.
Marek
On Fri, Feb 6, 2015 at 5:19 PM, David Heidelberg wrote:
> Should I incorporate PIPE_SHADER_CAP_MAX_PREDS change in this patch or send
> another with idea of dropping PIPE_SHA
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #23 from Sven Arvidsson ---
So, a few things you could try:
The bug could be in Wine (different drivers can lead to different behaviour),
the game (Mesa sometimes follows the OpenGL spec better than other drivers and
exposes bugs in
On Fri, Feb 6, 2015 at 10:46 AM, Tiziano Bacocco wrote:
>
Please provide a commit log. Subject lines should be limited to 72
chars (as should commit log bodies).
> Signed-off-by: Tiziano Bacocco
> ---
> src/gallium/drivers/nouveau/nv50/nv50_query.c | 1 +
> src/gallium/drivers/nouveau/nvc0/nvc
Should I incorporate PIPE_SHADER_CAP_MAX_PREDS change in this patch or
send another with idea of dropping PIPE_SHADER_CAP_MAX_PREDS completly
from gallium, if there is no use?
David
On 02/06/2015 04:41 PM, Marek Olšák wrote:
This looks good with one exception: MAX_PREDS should be 0 for all
sh
Please bump the size of vgt_state for the SQ_VTX_BASE_VTX_LOC
register. It's set by r600_init_atom in r600_state.c and
evergreen_state.c
Please bump R600_MAX_DRAW_CS_DWORDS. It's an upper bound of how many
dwords draw_vbo can emit.
I don't understand what get_vfetch_type is good for. Could you pl
Michel is right. Nine shouldn't use the blend factors if the driver
doesn't support them.
The removal of the "XXX" comment is okay and can be moved to patch 2.
Marek
On Fri, Feb 6, 2015 at 3:46 AM, Michel Dänzer wrote:
> On 06.02.2015 09:14, David Heidelberg wrote:
>> these days all (r600+,nv50
1 - 100 of 177 matches
Mail list logo
