On 10/22/2015 09:41 AM, Timothy Arceri wrote:
On Thu, 2015-10-22 at 08:55 +0300, Tapani Pälli wrote:
On 10/22/2015 08:29 AM, Timothy Arceri wrote:
Location has never been able to be a negative value because it has
always been validated in the parser.
Also the linker doesn't check for negatives
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-10-21 at 12:30 -0700, Matt Turner wrote:
> We implement textureQueryLevels (which takes no arguments, save the
> sampler) using the resinfo message (which takes an argument of LOD).
> Without initializing it, we'd generate a MOV from the null register
On Tue, Oct 20, 2015 at 12:44 AM, Nanley Chery wrote:
> From: Nanley Chery
>
> Since the version numbers being compared are integral and we don't ever
> expect gl_context::Version to be equal to 0, subtract 1 from the rhs of
> the equation and perform the optimization of removing the equality che
On Thu, 2015-10-22 at 08:55 +0300, Tapani Pälli wrote:
> On 10/22/2015 08:29 AM, Timothy Arceri wrote:
> > Location has never been able to be a negative value because it has
> > always been validated in the parser.
> >
> > Also the linker doesn't check for negatives like the comment
> > claims.
>
On Wed, 2015-10-21 at 12:18 +0200, Samuel Iglesias Gonsalvez wrote:
> Commit f24e5e did not take into account arrays of named shader
> storage blocks.
>
> Fixes 20 dEQP-GLES31.functional.ssbo.* tests:
>
> dEQP
> -GLES31.functional.ssbo.layout.single_struct_array.per_block_buffer.s
> hared_instanc
On 2015-10-20 00:43:13, Iago Toral wrote:
> On Tue, 2015-10-20 at 00:12 -0700, Jordan Justen wrote:
> > An untyped surface read is volatile because it might be affected by a
> > write.
> >
> > In the ES31-CTS.compute_shader.resources-max test, two back to back
> > read/modify/writes of an SSBO var
On 10/22/2015 08:29 AM, Timothy Arceri wrote:
Location has never been able to be a negative value because it has
always been validated in the parser.
Also the linker doesn't check for negatives like the comment claims.
Neither does the parser, if one utilizes negative explicit location,
parse
Location has never been able to be a negative value because it has
always been validated in the parser.
Also the linker doesn't check for negatives like the comment claims.
---
No piglit regressions and an extra negative test sent for
ARB_explicit_uniform_location [1]
[1] http://patchwork.fre
On 22.10.2015 10:47, Vivek Kasireddy wrote:
> For certain platforms that support rotated scanout buffers, currently,
> there is no way to create them with the GBM DRI interface. This flag
> will tell the DRI driver to set Y-tiling while creating the rotated
> scanout buffer.
Please split up the GB
Oh and it probably should go to stable.
Roland
Am 21.10.2015 um 18:55 schrieb Roland Scheidegger:
> Thanks for fixing this up.
>
> Reviewed-by: Roland Scheidegger
>
> Am 21.10.2015 um 18:25 schrieb Jose Fonseca:
>> This should prevent disparity between features Mesa and LLVM
>> believe are sup
For certain platforms that support rotated scanout buffers, currently,
there is no way to create them with the GBM DRI interface. This flag
will tell the DRI driver to set Y-tiling while creating the rotated
scanout buffer.
Cc: Kristian Hogsberg
Signed-off-by: Vivek Kasireddy
---
include/GL/int
On Wednesday, October 21, 2015 03:58:09 PM Matt Turner wrote:
> We were leaving it undefined, even though we were writing a string to
> *str.
> ---
> src/util/ralloc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/util/ralloc.c b/src/util/ralloc.c
> index e07fce7..bb4cf96 100644
>
Ahhh legacy functionality from hell...
For the series:
Reviewed-by: Roland Scheidegger
I'm wondering if it would be possible to omit the rasterPos execution
completely, by incorporating it into drawPixels etc. at least in the
hopefully common case there's no state changes affecting the results i
Am 22.10.2015 um 00:41 schrieb Rowley, Timothy O:
>
>> On Oct 20, 2015, at 2:03 PM, Roland Scheidegger wrote:
>>
>> Certainly looks interesting...
>> From a high level point of view, seems quite similar to llvmpipe (both
>> tile based, using llvm for jitting shaders, ...). Of course llvmpipe
>> i
> On Oct 20, 2015, at 5:58 PM, Jose Fonseca wrote:
>
> Thanks for the explanations. It's closer now, but still a bit of gap:
>
> $ KNOB_MAX_THREADS_PER_CORE=0 ./gloss
> SWR create screen!
> This processor supports AVX2.
> --> numThreads = 3
> 1102 frames in 5.002 seconds = 220.312 FPS
> 1133 f
The real fix is in nouveau_drm_winsys.c by setting dev to 0.
Which means dev's ownership has been passed to previous call.
Other changes are there to be consistent with what the
screen_create functions already do on errors.
Encountered this crash because nvc0_screen_create sometimes fails with:
nv
On Wed, Oct 21, 2015 at 3:41 PM, Brian Paul wrote:
> Instead of calling memcpy() 'n' times, we can do it all at once since
> the source and dest regions are all contiguous.
> ---
> src/mesa/vbo/vbo_exec_api.c | 16 +++-
> src/mesa/vbo/vbo_save_api.c | 15 +++
> 2 files cha
A minor nit, please change "num_written_culldistance field was a multiple of
four" comment
in the commit message to "num_written_clipdistance field was a "
Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Wednesday, October 21, 2015 3:25 PM
To: m
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I'm not 100% sure if this actually matches the hardware. It's
possible that some of the issue time is used to determine interference
and do the thread switch in which case, there may be some overlap.
However, it's definitely better than what we had before since, before,
issue time would get comple
Sorry this patch should not have gone in the v2 since it has been already
reviewed by Emil. But thx for your review.
I experienced the crash when testing patch 5/7 of this patch series, around
"resource = pscreen->resource_from_handle" in the new vaCreateSurface2
function. Just passing a wrong fd.
On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
> Previously, we were using some heuristics to try and detect when a write
> was about to begin a live range, or when a read was about to end a live
> range. We never used the liveness analysis information used by the
> register allocator, thoug
Reviewed-by: Jason Ekstrand
On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
> We'll need this for the scheduler too, since it wants to know when the
> live ranges of payload registers end in order to model them in our
> register pressure calculations.
>
> Signed-off-by: Connor Abbott
> ---
On Fri, Oct 16, 2015 at 8:03 PM, Connor Abbott wrote:
> The heuristic we're using is rather lame, since it assumes everything is
> non-uniform and loops execute 10 times, but it should be enough for
> measuring improvements in the scheduler that don't result in a change in
> the number of instruct
It was being memset to 0 previously.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 2 +-
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i
---
src/mesa/drivers/dri/i965/brw_eu_validate.c | 257
1 file changed, 257 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c
b/src/mesa/drivers/dri/i965/brw_eu_validate.c
index 85d4c19..eb57962 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_valida
Add some instructions: illegal, movi, sends, sendsc.
Remove some instructions with reused opcodes: msave, mrestore, push,
pop, goto. I did have some gross code for disassembling opcodes
per-generation, but there's very little meaningful overlap so it's
probably not needed.
---
src/mesa/drivers/dr
Will allow annotations to contain error messages (indicating an
instruction violates a rule for instance) that are printed after the
disassembly of the block.
---
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 60
src/mesa/drivers/dri/i965/intel_asm_annotation.h | 7 +
Initially just checks that sources are non-NULL, which would have
alerted us to the problem fixed by commit 6c846dc5.
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_eu.h | 4 +
src/mesa/drivers/dri/i965/brw_eu_validate.c | 150 +
And why did IFF have a destination?
I suspect that once upon a time the disassembler used this information
to know which fields to find the jump targets in. The jump targets have
moved, so the disassembler has to know how to handle these
per-generation anyway.
---
src/mesa/drivers/dri/i965/brw_di
---
src/mesa/drivers/dri/i965/brw_eu_validate.c | 244
1 file changed, 244 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c
b/src/mesa/drivers/dri/i965/brw_eu_validate.c
index eb57962..3d16f90 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_valida
We were leaving it undefined, even though we were writing a string to
*str.
---
src/util/ralloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/util/ralloc.c b/src/util/ralloc.c
index e07fce7..bb4cf96 100644
--- a/src/util/ralloc.c
+++ b/src/util/ralloc.c
@@ -499,6 +499,7 @@ ralloc_vaspr
Often annotations are identical between sets of consecutive
instructions. We can perhaps avoid some memory allocations by reusing
the previous annotation.
---
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/s
Inspired by a bug this summer, I've written a basic assembly validation
pass. The series currently checks only three things:
- that instruction sources are not null (when they shouldn't be);
- that the Gen supports the instruction opcode; and
- that the various accumulator restrictions ar
Reviewed-by: Jason Ekstrand
Let's add the perf numbers and get this pushed.
On Sat, Oct 3, 2015 at 6:13 PM, Jason Ekstrand wrote:
> On Sat, Oct 3, 2015 at 11:13 AM, Jason Ekstrand wrote:
>> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
>>> Before, we would only do scheduling after regi
On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
> Although write-after-write dependencies have the same latency as
> read-after-write dependencies due to how the register scoreboard works,
> write-after-read dependencies aren't checked by the EU at all, so
> they're purely a constraint on how
---
src/mesa/main/lines.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/lines.c b/src/mesa/main/lines.c
index c020fb3..93b80af 100644
--- a/src/mesa/main/lines.c
+++ b/src/mesa/main/lines.c
@@ -45,6 +45,10 @@ _mesa_LineWidth( GLfloat width )
if (MESA_
We'll remove it from the tnl module next. By lifting this code into core
Mesa we can use it from the gallium state tracker.
---
src/mesa/main/rastpos.c | 441
src/mesa/main/rastpos.h | 3 +
2 files changed, 444 insertions(+)
diff --git a/src/mes
The st_RasterPos() function goes to great pains to implement the
rasterpos transformation. It basically uses gallium's draw module to
execute the vertex shader to draw a point, then capture that point's
attributes.
But glRasterPos isn't typically used with a vertex shader so we can
usually use th
---
src/mesa/drivers/common/driverfuncs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 3d1fccb..752aaf6 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/dri
---
src/mesa/Makefile.sources | 1 -
src/mesa/tnl/t_rasterpos.c | 478 -
2 files changed, 479 deletions(-)
delete mode 100644 src/mesa/tnl/t_rasterpos.c
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 34fb446..4bcaa62 100644
Instead of calling memcpy() 'n' times, we can do it all at once since
the source and dest regions are all contiguous.
---
src/mesa/vbo/vbo_exec_api.c | 16 +++-
src/mesa/vbo/vbo_save_api.c | 15 +++
2 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/src/mesa/v
> On Oct 20, 2015, at 2:03 PM, Roland Scheidegger wrote:
>
> Certainly looks interesting...
> From a high level point of view, seems quite similar to llvmpipe (both
> tile based, using llvm for jitting shaders, ...). Of course llvmpipe
> isn't well suited for these kind of workloads (the most im
Before the change "tgsi/scan: use properties for clip/cull distance
writemasks", the tgsi_shader_info::num_written_culldistance field
was a multiple of four, now it's an accurate count. In the svga
driver, we need a minor change to the loop test.
---
src/gallium/drivers/svga/svga_tgsi_vgpu10.c |
From: Nanley Chery
In OpenGL ES, the COMPRESSED_TEXTURE_FORMATS query returns the set of
supported specific compressed formats. Since ASTC formats fit within
that category, include them in the set and update the
NUM_COMPRESSED_TEXTURE_FORMATS query as well.
This enables GLES2-based ASTC dEQP tes
On Wed, Oct 21, 2015 at 2:16 PM, Emil Velikov wrote:
> On 21 October 2015 at 21:33, Kenneth Graunke wrote:
>> On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
>>> Ping on these two trivial patches ?
>>>
>>> -Emil
>>
>> Oh, sorry, I thought I'd sent R-bs for these...
>>
>> Both are
>> R
Gen9 adds the ability to write out a stencil value, so we need to expand the
virtual payload by one. Abstracting this now makes that change easier to read.
I was admittedly confused early on about some of the hardcoding. If people
believe the resulting code is inferior, I am not super attached to
On 21 October 2015 at 21:33, Kenneth Graunke wrote:
> On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
>> Ping on these two trivial patches ?
>>
>> -Emil
>
> Oh, sorry, I thought I'd sent R-bs for these...
>
> Both are
> Reviewed-by: Kenneth Graunke
Thanks Ken. I was wondering if peopl
On Oct 21, 2015 10:28 AM, "Jason Ekstrand" wrote:
>
> On Wed, Oct 21, 2015 at 1:29 AM, Kenneth Graunke
wrote:
> > On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
> >> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
> >> There are many kinds of flags for SIMD
On Wed, Oct 21, 2015 at 1:52 PM, Emil Velikov wrote:
> On 20 October 2015 at 05:08, Matt Turner wrote:
>> Otherwise we'd emit a MOV from the null register (which isn't allowed).
>>
> Would you say it's a good idea to push the check down to the MOV()
> implementation ? If not perhaps we should add
On 20 October 2015 at 05:08, Matt Turner wrote:
> Otherwise we'd emit a MOV from the null register (which isn't allowed).
>
Would you say it's a good idea to push the check down to the MOV()
implementation ? If not perhaps we should add an assert() to easily
catch cases like these in the future ?
https://bugs.freedesktop.org/show_bug.cgi?id=92570
--- Comment #2 from Andy Furniss ---
(In reply to Christian König from comment #1)
> Yeah, that's a known issue/unimplemented feature.
>
> On pre Tonga hardware UVD can actually decode 10 bit h264, but still outputs
> NV12.
So you mean it produ
On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
> The PIPE_BIND_SHARED flag should be added whenever
> the resource may be shared with another process.
>
> In particular if the resource is imported, or may
> be exported, the flag should be used.
This can't be enforced. EGL_MESA_image_dma_buf_e
On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
> Ping on these two trivial patches ?
>
> -Emil
Oh, sorry, I thought I'd sent R-bs for these...
Both are
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
On Wednesday, October 21, 2015 12:45:27 PM Jason Ekstrand wrote:
> Previously, we were pulling bits from GL data structures in order to set up
> the prog_data. However, in this brave new world of NIR, we want to be
> pulling it out of the NIR shader whenever possible. This way, we can move
> all
On Wednesday, October 21, 2015 12:44:31 PM Jason Ekstrand wrote:
> v2: Add a uses_streams boolean
>
> ---
> src/glsl/nir/glsl_to_nir.cpp | 4
> src/glsl/nir/nir.h | 12
> 2 files changed, 16 insertions(+)
>
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/g
Previously, we were pulling bits from GL data structures in order to set up
the prog_data. However, in this brave new world of NIR, we want to be
pulling it out of the NIR shader whenever possible. This way, we can move
all this setup code into brw_compile_gs without depending on the old GL
stuff
v2: Add a uses_streams boolean
---
src/glsl/nir/glsl_to_nir.cpp | 4
src/glsl/nir/nir.h | 12
2 files changed, 16 insertions(+)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index c9cdf35..9b50a93 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+
We implement textureQueryLevels (which takes no arguments, save the
sampler) using the resinfo message (which takes an argument of LOD).
Without initializing it, we'd generate a MOV from the null register to
load the LOD argument.
Essentially the same logic applies to texture. A vertex shader cann
On Wednesday, October 21, 2015 10:05:27 AM Matt Turner wrote:
> Not a functional difference, but register is loaded with a signed
> immediate (V) and added to a signed type (D) producing a signed result
> (D).
>
> Also change the type of g0 to allow for compaction.
> ---
> src/mesa/drivers/dri/i9
Ian Romanick writes:
>> To fix that this patch makes it use interpolateAtOffset in the blit
>> shader whenever 16x MSAA is used and the GL_ARB_gpu_shader5 extension
>> is available. This forces it to interpolate the texture coordinates at
>> the pixel center to avoid these problematic positions.
On Wed, Oct 21, 2015 at 1:29 AM, Kenneth Graunke wrote:
> On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
>> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
>> There are many kinds of flags for SIMD4x2 messages.
>>
>> However, there are really only two (per-s
On Tue, Oct 20, 2015 at 02:48:41PM -0700, Matt Turner wrote:
> On Tue, Oct 20, 2015 at 2:41 PM, Ben Widawsky wrote:
> > On Tue, Oct 20, 2015 at 11:56:15AM +0200, Neil Roberts wrote:
> >> In bfdae9149e0 I disabled the opt_sampler_eot optimisation for TG4
> >> message types because I found by experi
https://bugs.freedesktop.org/show_bug.cgi?id=92221
Nanley Chery changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Oct 21, 2015 at 1:29 AM, Kenneth Graunke wrote:
> On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
>> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
>> There are many kinds of flags for SIMD4x2 messages.
>>
>> However, there are really only two (per-s
On Wed, Oct 21, 2015 at 7:23 AM, Emil Velikov
wrote:
> On 9 October 2015 at 23:35, Nanley Chery wrote:
> > From: Nanley Chery
> >
> > The refactoring commit, c6bf1cd, accidentally reverted cd49b97
> > and 99b1f47. These changes caused more code to be added to the
> > function and removed the ex
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 9a5992e1..15d0430 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_g
Gen8+ lifted the register region restriction that an instruction whose
destination spans two registers must have sources that also span two
registers.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/br
Not a functional difference, but register is loaded with a signed
immediate (V) and added to a signed type (D) producing a signed result
(D).
Also change the type of g0 to allow for compaction.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs_generator
The AND and SHR produce a scalar value that we had been replicating
across $dispatch_width channels. The immediate MOV produces only four
useful channels of data.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/driv
Hello list,
The candidate for the Mesa 11.0.4 is now available. Currently we have:
- 36 queued
- 18 nominated (outstanding)
- and 0 rejected/obsolete patches
The current queue consists on various mesa, glsl and driver fixes, a few
build related patches and an omx bugfix.
Take a look at secti
Thanks for fixing this up.
Reviewed-by: Roland Scheidegger
Am 21.10.2015 um 18:25 schrieb Jose Fonseca:
> This should prevent disparity between features Mesa and LLVM
> believe are supported by the CPU.
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-October/thread.html#96990
>
> Teste
I am just a bystander, but I have one suggestion to this patch.
2015-10-21 18:25 GMT+02:00 Jose Fonseca :
> This should prevent disparity between features Mesa and LLVM
> believe are supported by the CPU.
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-October/thread.html#96990
>
> Tested
This should prevent disparity between features Mesa and LLVM
believe are supported by the CPU.
http://lists.freedesktop.org/archives/mesa-dev/2015-October/thread.html#96990
Tested on a i7-3720QM w/ LLVM 3.3 and 3.6.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 34 +
From: Emil Velikov
v2:
- Add a few const qualifiers for good measure.
- Drop unneeded retype()s (Matt)
- Convert timestamp to SIMD8/16, as fs_visitor::get_timestamp() returns
SIMD4 (Connor)
v3:
- Remove unneeded temporary + MOV (Connor)
Signed-off-by: Emil Velikov
Reviewed-by: Connor Abbot
From: Emil Velikov
We're about to reuse get_timestamp() for the nir_intrinsic_shader_clock.
In the latter the generalisation does not apply, so move the smear()
where needed. This also makes the function analogous to the vec4 one.
v2: Tweak the comment - The caller -> We (Matt, Connor).
v3: More
From: Emil Velikov
v2: Add flags and inline comment/description.
v3: None of the input/outputs are variables
v4: Drop clockARB reference, relate code motion barrier comment wrt
intrinsic flag.
v5: Drop the "thus we can eliminate..." comment (Connor)
Signed-off-by: Emil Velikov
Reviewed-by: Conn
On 20 October 2015 at 19:58, Connor Abbott wrote:
> On Tue, Oct 20, 2015 at 12:55 PM, Emil Velikov
> wrote:
[snip]
>> +/*
>> + * Shader clock intrinsic with semantics analogous to the clock2x32ARB()
>> + * GLSL intrinsic.
>> + * The latter can be used as code motion barrier, which is currently n
On 09/29/2015 07:57 AM, Neil Roberts wrote:
> Previously there was a problem in i965 where if 16x MSAA is used then
> some of the sample positions are exactly on the 0 x or y axis. When
> the MSAA copy blit shader interpolates the texture coordinates at
> these sample positions it was possible that
On 10/20/2015 01:03 PM, Ilia Mirkin wrote:
> On Tue, Oct 20, 2015 at 10:19 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> From OpenGL 4.4 specification, section 10.4 and
>> Open GL Es 3.1 section 10.5:
>> "An INVALID_VALUE error is generated if indirect is not a multiple
>> of the size
On 10/21/2015 07:32 AM, Lofstedt, Marta wrote:
>> -Original Message-
>> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
>> Behalf Of Tapani Pälli
>> Sent: Wednesday, October 21, 2015 1:25 PM
>> To: Marek Olšák
>> Cc: mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=92570
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
Severity|normal
On 10/20/2015 10:22 AM, Ilia Mirkin wrote:
> On Tue, Oct 20, 2015 at 10:19 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> From OpenGL ES 3.1 specification, section 10.5:
>> "DrawArraysIndirect requires that all data sourced for the
>> command, including the DrawArraysIndirectCommand
>>
https://bugs.freedesktop.org/show_bug.cgi?id=92570
Bug ID: 92570
Summary: 10 bit h264 OMX UVD decode outputs NV12
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: n
On 9 October 2015 at 23:35, Nanley Chery wrote:
> From: Nanley Chery
>
> The refactoring commit, c6bf1cd, accidentally reverted cd49b97
> and 99b1f47. These changes caused more code to be added to the
> function and removed the existing support for ASTC. This patch
> reverts those modifications.
On Wed, 2015-10-21 at 14:58 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2015-10-21 at 13:00 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > Hi Curro,
> >> >
> >> > On Tue, 2015-10-20 at 14:18 +0300, Francisco Jerez wrote:
> >> >> Iago Toral writes:
> >> >
You still have to check all enabled vertex attributes. If you don't want to
loop, use bitmasks. See u_vbuf.c as an example of how to avoid loops.
Marek
On Oct 21, 2015 2:33 PM, "Lofstedt, Marta" wrote:
> > -Original Message-
> > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.o
These helpers are ran for same case the same loop. Here joined
their operation so the loop is ran just once. Also fixed
out-of-memory condition here.
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/linker.cpp | 112 +---
1 file changed, 37 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=92437
Jose Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tapani Pälli
> Sent: Wednesday, October 21, 2015 1:25 PM
> To: Marek Olšák
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 2/4] mesa: Draw Indirect is not allowed
> whe
Iago Toral writes:
> On Wed, 2015-10-21 at 13:00 +0300, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > Hi Curro,
>> >
>> > On Tue, 2015-10-20 at 14:18 +0300, Francisco Jerez wrote:
>> >> Iago Toral writes:
>> >>
>> >> > On Tue, 2015-10-20 at 13:22 +0300, Francisco Jerez wrote:
>> >> >>
On 21/10/2015 13:36, Bas Nieuwenhuizen wrote:
My apologies, wrong term. I meant the front buffer of the X server in
the non-compositing case.
- Bas
I think only glamor uses mesa for X rendering.
Depending on the DDX, the front buffer will either be created with gbm,
or imported as an EGLIma
On Wed, 2015-10-21 at 13:00 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > Hi Curro,
> >
> > On Tue, 2015-10-20 at 14:18 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > On Tue, 2015-10-20 at 13:22 +0300, Francisco Jerez wrote:
> >> >> Iago Toral Quiroga writes:
> >>
Bump. Does anybody have some time to review this patch? I think it's the
only one holding up landing 16x MSAA support.
The following three only have an ack-by but I'm hoping it is reasonable
to just push the branch with that.
i965/meta: Support 16x MSAA in the meta stencil blit
http://patchwork.f
My apologies, wrong term. I meant the front buffer of the X server in
the non-compositing case.
- Bas
On Wed, Oct 21, 2015 at 1:26 PM, Axel Davy wrote:
> On 21/10/2015 13:16, Bas Nieuwenhuizen wrote:
>>
>> On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
>>>
>>> +/* This flag indicates that i
Ben Widawsky writes:
> Gen9 adds the ability to write out a stencil value, so we need to expand the
> virtual payload by one. Abstracting this now makes that change easier to read.
>
> I was admittedly confused early on about some of the hardcoding. If people
> believe the resulting code is infer
On 21/10/2015 13:16, Bas Nieuwenhuizen wrote:
On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
+/* This flag indicates that in addition to being shared, the resource won't be
+ * read by any external process before we call flush_resource. This allows
+ * things like compressing the buffer whe
On 10/21/2015 01:41 PM, Marek Olšák wrote:
On Wed, Oct 21, 2015 at 7:16 AM, Tapani Pälli wrote:
On 10/20/2015 08:54 PM, Marek Olšák wrote:
On Tue, Oct 20, 2015 at 4:19 PM, Marta Lofstedt
wrote:
From: Marta Lofstedt
OpenGL ES 3.1 spec. section 10.5:
"An INVALID_OPERATION error is generated
On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
> +/* This flag indicates that in addition to being shared, the resource won't
> be
> + * read by any external process before we call flush_resource. This allows
> + * things like compressing the buffer when drawing, while uncompressing on
> + *
Timothy Arceri writes:
> On Wed, 2015-10-21 at 13:06 +0300, Francisco Jerez wrote:
>> Timothy Arceri writes:
>>
>> > On Fri, 2015-10-16 at 10:28 +1100, Timothy Arceri wrote:
>> > > Cc: Francisco Jerez
>> >
>> > Hi Curro,
>> >
>> > Just pinging you on this patch and patch 5. These are the fin
1 - 100 of 124 matches
Mail list logo
