On 01/07/15 01:41, Jason Ekstrand wrote:
> On Fri, Jun 26, 2015 at 1:07 AM, Eduardo Lima Mitev wrote:
>> From: Samuel Iglesias Gonsalvez
>>
>> Avoid copying an overwritten swizzle, use the original values.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89580
>> Signed-off-by: Samu
https://bugs.freedesktop.org/show_bug.cgi?id=91173
Bug ID: 91173
Summary: Oddworld: Stranger's Wrath HD: disfigured models in
wrong colors
Product: Mesa
Version: git
Hardware: Other
OS: All
Statu
https://bugs.freedesktop.org/show_bug.cgi?id=91169
--- Comment #1 from Ilia Mirkin ---
One thing to note is that the shaders don't *actually* use the functionality.
They all have the same copy & pasted adapter which makes glsl look more like
hlsl, and it includes some functions which call the var
On Jun 30, 2015 1:05 AM, "Iago Toral" wrote:
>
> Hi Jason,
>
> On Mon, 2015-06-29 at 16:22 -0700, Jason Ekstrand wrote:
> > On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev
wrote:
> > > From: Iago Toral Quiroga
> > >
> > > This is based on similar code existing in vec4_visitor. It builds the
https://bugs.freedesktop.org/show_bug.cgi?id=91169
Bug ID: 91169
Summary: The Chronicles of Riddick: Assault on Dark Athena
fails to start with nouveau
Product: Mesa
Version: git
Hardware: Other
OS: All
* Emil Velikov [150630 10:04]:
> Hi Liam,
>
> On 29/06/15 18:23, Liam R. Howlett wrote:
> > Hello,
> >
> > Since git 2.3, there have been a number of new fsck options added which
> > produce issues when I clone the repository
> > git://anongit.freedesktop.org/git/mesa/mesa
> >
> Can you be more
On 1 July 2015 at 00:52, Roland Scheidegger wrote:
> Am 30.06.2015 um 03:42 schrieb Dave Airlie:
>> On 30 June 2015 at 09:36, Roland Scheidegger wrote:
>>> Am 29.06.2015 um 22:18 schrieb Dave Airlie:
On 30 June 2015 at 00:58, Roland Scheidegger wrote:
> Don't worry about the AoS stuff.
>> LLVMValueRef base_ptr,
>> LLVMValueRef indexes,
>> - LLVMValueRef overflow_mask)
>> + LLVMValueRef overflow_mask, LLVMValueRef indexes2)
>> {
>> struct gallivm_state *gallivm = bld_base->base.gallivm;
>> LLVMBuilderRef builder = galliv
Now that we can create builders with a bigger width than their parent as
long as it's exec_all, we don't need to create the instruction manually.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i9
From: Francisco Jerez
This assertion was meant to catch code inadvertently escaping the
control flow jail determined by the group of channel enable signals
selected by some caller, however it seems useful to be able to
increase the default execution size as long as force_writemask_all is
enabled,
Ok, I think I've looked through more-or-less the whole thing. The
only thing I haven't looked at is the texturing stuff but I think I'd
like (and Ken agrees) to just refactor the old code to split the guts
into something re-usable and make a much shorter NIR function.
Most of it really looks pret
On Fri, Jun 26, 2015 at 1:07 AM, Eduardo Lima Mitev wrote:
> From: Samuel Iglesias Gonsalvez
>
> Avoid copying an overwritten swizzle, use the original values.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89580
> Signed-off-by: Samuel Iglesias Gonsalvez
> ---
> src/glsl/nir/nir_op
On Tue, Jun 30, 2015 at 4:15 PM, Nanley Chery wrote:
> From: Nanley Chery
>
> Define two-thirds of the 2D Intel ASTC surface formats (LDR-only). This allows
> a 1-to-1 mapping from the mesa format to the Intel format.
>
> ASTC textures will default to being processed in LDR mode. If there is
> ha
If we can avoid duplication in the texturing code, that would be
really nice. Could we do this as a refactor of the old code and then
a much smaller NIR function that calls some shared code? That's what
we did for FS and it worked ok. I looked at the layout of your code
and, after you finish rea
darwin: silence GLhandleARB convertions from and to GLuint
This patch and its description are inspired from Jose Fonseca
explanations and suggestions.
With this patch the following logic applies and only if __APPLE__:
When building mesa, GLhandleARB is defined as unsigned long and
at some point
On Fri, Jun 26, 2015 at 11:51 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Fri, Jun 26, 2015 at 8:52 AM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
1 file changed, 1
On Tue, Jun 30, 2015 at 9:16 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 42
>> src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
>> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
>> src/mesa/drivers/dri/i9
On Tue, Jun 30, 2015 at 7:19 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> Reviewed-by: Topi Pohjolainen
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/m
From: Nanley Chery
Define two-thirds of the 2D Intel ASTC surface formats (LDR-only). This allows
a 1-to-1 mapping from the mesa format to the Intel format.
ASTC textures will default to being processed in LDR mode. If there is
hardware support for HDR/Full mode and the texture is not sRGB, add
Ben Widawsky writes:
> On Wed, Jul 01, 2015 at 12:33:54AM +0300, Francisco Jerez wrote:
>> Ben Widawsky writes:
>>
>> > On Tue, Jun 30, 2015 at 11:25:42PM +0300, Francisco Jerez wrote:
>> >> Instead of relying on hardware defaults the i915 kernel driver is
>> >> going program custom MOCS tables
https://bugs.freedesktop.org/show_bug.cgi?id=91149
--- Comment #4 from Vinson Lee ---
attachment 116806 fixes the make check regression.
Tested-by: Vinson Lee
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
On Thursday, June 25, 2015 01:24:46 PM Jason Ekstrand wrote:
> Previously, we were allocating the payload with different sizes per gen and
> then figuring out the mlen in the generator based on gen. This meant,
> among other things, that the higher level passes knew nothing about it.
> ---
> src/
On Fri, Jun 26, 2015 at 1:07 AM, Eduardo Lima Mitev wrote:
> This is a helper method that returns a shader instruction opcode from the
> corresponding NIR texture opcode. It will be used to keep code in
> nir_emit_texture() clean.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89580
>
On Mon, Jun 22, 2015 at 4:02 PM, Nanley Chery wrote:
> From: Nanley Chery
>
> Intel surface formats default to LDR unless there is hardware
> support for HDR and the texture is able to be processed in HDR mode.
>
> v2: remove extra newlines.
> v3: follow existing coding style in translate_tex_for
On Mon, Jun 22, 2015 at 4:02 PM, Nanley Chery wrote:
> From: Nanley Chery
>
> v2: remove OES ASTC extension reference.
>
> Signed-off-by: Nanley Chery
> ---
> src/mesa/drivers/dri/i965/intel_extensions.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/int
This commit adds support for both compute and graphics global
performance counters which have been reverse engineered with
CUPTI (Linux) and PerfKit (Windows).
Currently, only one query type can be monitored at the same time because
the Gallium's HUD doesn't fit pretty well. This will be improved
This exposes a group of global performance counters that enables
GL_AMD_performance_monitor. All piglit tests are okay.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 35 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
src/ga
On Wed, Jul 01, 2015 at 12:33:54AM +0300, Francisco Jerez wrote:
> Ben Widawsky writes:
>
> > On Tue, Jun 30, 2015 at 11:25:42PM +0300, Francisco Jerez wrote:
> >> Instead of relying on hardware defaults the i915 kernel driver is
> >> going program custom MOCS tables system-wide on Gen9 hardware.
This notifier buffer object will be used to read back global performance
counters results written by the kernel.
For each domain, we will store the handle of the perfdom object, an
array of 4 counters and the number of cycles. Like the Gallium's HUD,
we keep a list of busy queries in a ring in ord
This commit implements the base interface for hardware performance
counters that will be shared between nv50 and nvc0 drivers.
TODO: Bump libdrm version of mesa when nvif will be merged.
Changes since v2:
- remove double-query thing for domains, signals and sources
Signed-off-by: Samuel Pitoiset
To write data at the right offset, the kernel has to know some
parameters of this ring buffer, like the number of domains and the
maximum number of queries.
Changes since v2:
- only configure the ring buffer if the notifier BO is allocated
- only use one BEGIN_NV04()
Signed-off-by: Samuel Pitoise
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 41 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.h | 3 ++
3 files changed, 45 insertions(+)
diff --git a/src/gallium/drivers/nou
This will allow to monitor global performance counters through the
command stream of the GPU instead of using ioctls.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 11 +++
src/gallium/drivers/nouveau/nv50/nv50_screen.h | 1 +
src/gallium/drivers/nou
Hello there,
This series exposes NVIDIA's global performance counters for Tesla through the
Gallium's HUD and the GL_AMD_performance_monitor extension.
This adds support for 24 hardware events which have been reverse engineered
with PerfKit (Windows) and CUPTI (Linux). These hardware events will
Ben Widawsky writes:
> On Tue, Jun 30, 2015 at 11:25:42PM +0300, Francisco Jerez wrote:
>> Instead of relying on hardware defaults the i915 kernel driver is
>> going program custom MOCS tables system-wide on Gen9 hardware. The
>> "WT" entry previously used for renderbuffers had a number of probl
On Mon, Jun 22, 2015 at 4:02 PM, Nanley Chery wrote:
> From: Nanley Chery
>
> An ASTC block takes up 16 bytes for all block width and height configurations.
> This size is not integrally divisible by all ASTC block widths. Therefore cpp
> is changed to mean bytes per block if the texture is compr
On Mon, Jun 22, 2015 at 4:02 PM, Nanley Chery wrote:
> From: Nanley Chery
>
> Remove redundant checks and comments by grouping our calculations for
> align_w and align_h wherever possible.
>
> v2: reintroduce brw.
> don't include functional changes.
> don't adjust function parameters or c
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> From: Antia Puentes
>
> For operations that have a predefined operand size > 0, defined in
> glsl/nir/nir_opcodes.c, NIR returns a swizzle containing zeros in the
> components from outside the source vector. However, the driver
> expect
First off, this needs a different commit message. "float-related
functions" isn't particularly descriptive. How about "various
rounding functions" because these really are all "rounding modes".
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> From: Antia Puentes
>
> Adds NIR ALU op
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #29 from Matt Whitlock ---
(In reply to Ilia Mirkin from comment #28)
> If you get the nouveau ddx from git, it should have DRI3 support.
I might look into that. Is there any compelling reason why I should care about
DRI3?
Also, for
On Tue, Jun 30, 2015 at 03:02:05PM +0100, Neil Roberts wrote:
> For centroid interpolation we can just directly use the values set up
> in the shader payload instead of querying the pixel interpolator. To
> do this we need to modify brw_compute_barycentric_interp_modes to
> detect when interpolateA
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #28 from Ilia Mirkin ---
(In reply to Matt Whitlock from comment #27)
> (In reply to Eero Tamminen from comment #26)
> > (In reply to Matt Whitlock from comment #15)
> > > (In reply to Furkan from comment #14)
> > > > For those of you
On Tue, Jun 30, 2015 at 11:25:42PM +0300, Francisco Jerez wrote:
> Instead of relying on hardware defaults the i915 kernel driver is
> going program custom MOCS tables system-wide on Gen9 hardware. The
> "WT" entry previously used for renderbuffers had a number of problems:
> It disabled caching o
Instead of relying on hardware defaults the i915 kernel driver is
going program custom MOCS tables system-wide on Gen9 hardware. The
"WT" entry previously used for renderbuffers had a number of problems:
It disabled caching on eLLC, it used a reserved L3 cacheability
setting, and it used to overri
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> For the indirect case we need to take the index delivered by
> NIR and compute the parent uniform that we are accessing (the one
> that we uploaded to a surface) and the constant offset into that
> surface.
I'm not sure what I think about adding an is_scalar flag vs. having
_scalar and _vec4 versions of each function. My feeling is that once
we tweak assign_var_locations as I mentioned for vec4 outputs, we'll
find that we want to have them separate. The big thing here is that
I'd rather have _vec4 a
On 30/06/15 15:39, Liam R. Howlett wrote:
> * Emil Velikov [150630 10:04]:
>> Hi Liam,
>>
>> On 29/06/15 18:23, Liam R. Howlett wrote:
>>> Hello,
>>>
>>> Since git 2.3, there have been a number of new fsck options added which
>>> produce issues when I clone the repository
>>> git://anongit.freedes
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> This patch makes public the is_scalar_shader_stage() method in brw_shader, and
> renames it to brw_compiler_is_scalar_shader_stage(). The plan is to later
> reuse it
> in brw_nir, to enable/disable optimization passes depending on the t
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> The index into the output_reg array where to store the destination register is
> fetched from the nir_outputs map built during nir_setup_outputs stage.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89580
> ---
> src/mesa/dr
On 29 June 2015 at 17:58, Matt Turner wrote:
> It couldn't have worked anyway. There were calls to undefined functions.
Reviewed-by: Emil Velikov
Nice one !
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mai
On 27 June 2015 at 09:46, Marek Olšák wrote:
> For the whole series:
>
> Reviewed-by: Marek Olšák
>
Fixed the typo spotted by Michel and pushed to master. Thank you Marek.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.free
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> The same we do in the FS NIR backend, only that here we need to consider
> the number of components in the condition and adjust the swizzle
> accordingly.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.
Another general comment: It seems like you may have copied+pasted a
bit much when it comes to handling arrays in the backend. In the FS
backend, we have to multiply lots of stuff by reg->num_components
because we need to scalarize it. In the vec4 backend, we don't need
to do this because reg->nu
v2: Use another sed pattern as per Ilia's suggestion.
Signed-off-by: Emil Velikov
---
Ilia's approach seems to be slightly faster than Chad's so I've went
ahead with it.
-Emil
bin/bugzilla_mesa.sh | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/bin/bugzilla
On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> From: Samuel Iglesias Gonsalvez
>
> These methods are essential for the implementation of the NIR->vec4 pass. They
> work similar to their fs_nir counter-parts.
>
> When processing instructions, these methods are invoked to resolve the
Jason Ekstrand writes:
> Soon we will start using the builder to explicitly set all the execution
> sizes. We could make a 32-wide builder, but the builder asserts that we
> never grow it which is usually a reasonable assumption. Sinc this one
> instruction is a bit of an odd-ball, we just set
Jason Ekstrand writes:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 42
> src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 58 +--
> src/mesa/drivers/dri/i
On 30 June 2015 at 16:06, Martin Peres wrote:
> On 30/06/15 18:09, Emil Velikov wrote:
>>
>> Render nodes have been around for quite some time. Removing support via
>> the master/primary node allows us to clean up the conditional
>> compilation and simplify the build greatly.
>>
>> For example cur
Am 30.06.2015 um 03:41 schrieb Dave Airlie:
> This adds support for ARB_gpu_shader_fp64 and ARB_vertex_attrib_64bit to
> llvmpipe.
>
> Two things that don't mix well are SoA and doubles, see
> emit_fetch_double, and emit_store_double_chan in this.
>
> I've also had to split emit_data.chan, to add
On 22 June 2015 at 23:19, Dave Airlie wrote:
> On 23 June 2015 at 08:16, Ian Romanick wrote:
>> On 06/22/2015 11:54 AM, Dave Airlie wrote:
As kindly hinted by Marek, currently we do have a wide selection of
supported dri <> loader combinations.
Although we like to think t
https://bugs.freedesktop.org/show_bug.cgi?id=84570
--- Comment #37 from Ian C. Bullard ---
Just so you're aware...
The glDrawRangeElements fix mentioned above should be live. I've checked our
depot's history and no rendering code changes have been made since January. If
there are changes on As
On 30/06/15 18:09, Emil Velikov wrote:
Render nodes have been around for quite some time. Removing support via
the master/primary node allows us to clean up the conditional
compilation and simplify the build greatly.
For example currently we the pipe-loader, with an explicit link against
The v
Signed-off-by: Emil Velikov
---
src/gallium/drivers/radeonsi/cik_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/cik_sdma.c
b/src/gallium/drivers/radeonsi/cik_sdma.c
index 86111cb..47b586f 100644
--- a/src/gallium/drivers/radeonsi/cik_sdma.
The former handles O_CLOEXEC (and the lack of it) appropriately.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/Makefile.am| 1 +
src/gallium/auxiliary/vl/vl_winsys_dri.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/Makefile.am
b/s
The former handles O_CLOEXEC (and the lack of it) appropriately.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
b/src/gallium/auxiliary/pi
Was only around as opencl's pipe-loader needed to link against xcb.
Cc: Rob Clark
Cc: Tom Stellard
Cc: Francisco Jerez
Signed-off-by: Emil Velikov
---
configure.ac | 11 ---
src/gallium/auxiliary/pipe-loader/Makefile.am | 42 ---
sr
Cc: Rob Clark
Signed-off-by: Emil Velikov
---
configure.ac | 1 -
src/gallium/auxiliary/pipe-loader/Makefile.am | 3 ---
src/gallium/targets/d3dadapter9/Makefile.am | 3 +--
src/gallium/targets/dri/Makefile.am | 3 +--
src/gallium/targets/omx/Makefile
It was only useful for st/egl, although I've never got to merging the
pipe-loader and inline-helpers before it was removed. There are no users
for it ATM.
Signed-off-by: Emil Velikov
---
configure.ac | 13 ++-
src/gallium/Automake.inc
No longer used by anyone, as of last commit.
Cc: Tom Stellard
Cc: Francisco Jerez
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader.h| 6 +-
.../auxiliary/pipe-loader/pipe_loader_drm.c| 83 +-
src/gallium/auxiliary/vl/vl_winsys_dri.c
Hello all,
As mentioned over IRC a few weeks back, here is a series that removes
support for non-render node devices.
The two main motivations being:
- Currently we force X/xcb onto everyone that wants to use OpenCL
(headless OpenCL systems/farms anyone ?)
- Nice overall cleanup - 43 insertion
Render nodes have been around for quite some time. Removing support via
the master/primary node allows us to clean up the conditional
compilation and simplify the build greatly.
For example currently we the pipe-loader, with an explicit link against
xcb and friends (for X auth). Although forcing X
Do not iterate and (attempt to) open the render device, if we're over
the requested number of devices.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-
Am 30.06.2015 um 03:42 schrieb Dave Airlie:
> On 30 June 2015 at 09:36, Roland Scheidegger wrote:
>> Am 29.06.2015 um 22:18 schrieb Dave Airlie:
>>> On 30 June 2015 at 00:58, Roland Scheidegger wrote:
Don't worry about the AoS stuff. Only meant to do simple things.
Looks good overa
Jason Ekstrand writes:
> Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index d1e253a..4f56865 100644
> -
Hi Liam,
On 29/06/15 18:23, Liam R. Howlett wrote:
> Hello,
>
> Since git 2.3, there have been a number of new fsck options added which
> produce issues when I clone the repository
> git://anongit.freedesktop.org/git/mesa/mesa
>
Can you be more specific about the fsck options and the messages th
For centroid interpolation we can just directly use the values set up
in the shader payload instead of querying the pixel interpolator. To
do this we need to modify brw_compute_barycentric_interp_modes to
detect when interpolateAtCentroid is called.
This fixes the interpolateAtCentroid tests on SK
This is required on non-coherent architectures to ensure the value of
the fence is correct at all times. Failure to do this results in the
display freezing for a few seconds every now and then on Tegra.
The NOUVEAU_BO_COHERENT is a no-op for coherent architectures, so behavior
on x86 should not be
Hi Jason,
On Mon, 2015-06-29 at 16:22 -0700, Jason Ekstrand wrote:
> On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
> > From: Iago Toral Quiroga
> >
> > This is based on similar code existing in vec4_visitor. It builds the
> > uniform register file iterating through each uniform vari
Hi Emil;
I got r-b now for all the patches considering this series. At least one
of these (i965: use EmitNoIndirectSampler for gen < 7) does not apply as
is to the 10.6 tree as it is due to other changes.
How does the process go, should I sent a separate patch for 10.6 tree
(there the change
On 30/06/15 01:34, Jason Ekstrand wrote:
> On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev wrote:
>> From: Alejandro Piñeiro
>>
>> Similar to other variable setups, system values will initialize the
>> corresponding register inside a 'nir_system_values' map, which will then
>> be queried la
On 29.06.2015 17:44, Iago Toral Quiroga wrote:
> These checks were in Mesa prior to commit fbba25bba, but they were
> not necessary for the purpose that Mesa intended (check if we could
> resolve ReadPixels via memcpy), so that commit took them away.
>
> Unfortunately, it seems that some Gallium d
81 matches
Mail list logo
