Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
index 8bd150a..4bc3be7 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4
Here we create a new output_generic_reg array with the ability to
store the dst_reg for each component of user defined varyings.
This is needed as the previous code only stored the dst_reg based
on the varying location which meant packed varyings would overwrite
each other.
---
src/mesa/drivers/dr
This will be used to swizzle components to the beginning or end
of the vector based on the component layout qualifier and whether
we are doing a load or store.
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/
This makes sure we give the correct driver location
for doubles when using component packing.
---
src/compiler/nir/nir_lower_io.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index e480264..7a72e69 100644
--
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index c557137..ec89094 100644
--- a/src/mesa/drivers/dri/i965/intel_ext
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 38 +++-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 395594f..e75e7f7 100644
--- a/src/mesa/drivers/dri/i965/brw_
Reviewed-by: Edward O'Callaghan
---
docs/GL3.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 1335397..ebaf4bf 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -193,11 +193,11 @@ GL 4.4, GLSL 4.40:
GL_MAX_VERTEX_ATTRIB_STRIDE
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
index 9ebfb27..16d2410 100644
--- a/src/mesa/drivers/dri/i965/brw_
---
src/mesa/drivers/dri/i965/brw_vec4_tes.cpp | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
index 6639c86..8266a9d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 8 ++--
src/mesa/drivers/dri/i965/brw_vec4_tcs.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
in
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 17 +
src/mesa/drivers/dri/i965/brw_vec4_tcs.h | 1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
b/src/mesa/drivers/dri/i965/brw_vec
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index f3b4528..33ad852 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.
We will use this for output varyings. To make component
packing simpler we will just treat all varyings as vec4s.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/
Rather than trying to work out the total number of components
used at a location we simply treat all outputs as vec4s.
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 -
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 22 ++
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1
V5:
- rebase on Ken's interpolation clean-ups [1]
V4:
- add vec4 backend support and enable for Gen6+
V3:
- Rewrite patch 9 (add support for packing arrays) to not add
hacks to the type_size() functions.
- Add packing support for the load_output intrinsics (patch 12)
- Add glsl_dvec_type()
For example where n=3 first_component=1 this will give us
0xE (WRITEMASK_YZW).
Reviewed-by: Edward O'Callaghan
---
src/mesa/drivers/dri/i965/brw_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_reg.h
b/src/mesa/drivers/dri/i965/brw_reg.h
index 7eab7b
On Monday, July 18, 2016 10:58:31 PM PDT Ben Widawsky wrote:
> On Mon, Jul 18, 2016 at 07:08:46PM -0700, Kenneth Graunke wrote:
> > Fixes a 10-20% performance regression in OglCSDof caused by commit
> > 5a8c89038abab0184ea72664ab390ec6ca58b4d6, which made images (in the
> > image load/store sense)
On Mon, Jul 18, 2016 at 07:08:46PM -0700, Kenneth Graunke wrote:
> Fixes a 10-20% performance regression in OglCSDof caused by commit
> 5a8c89038abab0184ea72664ab390ec6ca58b4d6, which made images (in the
> image load/store sense) use BDW_MOCS_PTE instead of BDW_MOCS_WB.
>
> This seems sketchy, as
On Mon, Jul 18, 2016 at 10:16:53PM -0700, Jason Ekstrand wrote:
> From the Sky Lake PRM:
>
>"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
>Surfaces, the range of this field is [0,340], indicating the number of
>cube array elements (equal to the number of underlyi
On Jul 18, 2016 10:11 PM, "Chris Forbes" wrote:
>
> I remember arguing about this when it got added -- tradeoff was payload
size/register pressure vs needing to call out to this unit, if centroid
barycentric coords weren't required for anything else? It does seem fairly
pointless, though.
>
> For
Oh dear, hacks on both sides. Sorry for this nonsense.
Series is:-
Reviewed-by: Chris Forbes
On Tue, Jul 19, 2016 at 5:16 PM, Jason Ekstrand
wrote:
> From the Sky Lake PRM:
>
>"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
>Surfaces, the range of this field is [0
This matches what we do for cube maps where logical_depth0 is in number of
face-layers rather than number of cubes. This does mean that we will
temporarily be setting the surface bounds too loose for cube map textures
but we are already setting them too loose for cube arrays and we will be
fixing
From the Sky Lake PRM:
"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
Surfaces, the range of this field is [0,340], indicating the number of
cube array elements (equal to the number of underlying 2D array elements
divided by 6). For other surfaces, this field must
From the Sky Lake PRM:
"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
Surfaces, the range of this field is [0,340], indicating the number of
cube array elements (equal to the number of underlying 2D array elements
divided by 6). For other surfaces, this field must
The intel_get_image_dims helper function handles some image dimension
sanitization for us for things such as 1-D array textures. We should
probably be using it here.
Signed-off-by: Jason Ekstrand
Cc: "12.0 11.2 11.1"
---
src/mesa/drivers/dri/i965/intel_tex.c | 2 ++
1 file changed, 2 insertion
From the Sky Lake PRM:
"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
Surfaces, the range of this field is [0,340], indicating the number of
cube array elements (equal to the number of underlying 2D array elements
divided by 6). For other surfaces, this field must
https://bugs.freedesktop.org/show_bug.cgi?id=96950
--- Comment #5 from Mathias Fröhlich ---
Or Can you provide an apitrace?
I have no such system to reproduce at hands.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._
I remember arguing about this when it got added -- tradeoff was payload
size/register pressure vs needing to call out to this unit, if centroid
barycentric coords weren't required for anything else? It does seem fairly
pointless, though.
For the series:-
Reviewed-by: Chris Forbes
On Tue, Jul 19
Seems a little unfortunate to add a random bool to this interface which is
otherwise fairly descriptive, but OK.
On Tue, Jul 19, 2016 at 8:26 AM, Kenneth Graunke
wrote:
> While my intention is that the new intrinsics should be usable by all
> drivers, we need to make them optional until all driv
On Tue, Jul 19, 2016 at 8:26 AM, Kenneth Graunke
wrote:
> + default:
> + assert(!"invalid intrinsic");
>
unreachable() ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jul 19, 2016 at 12:35 PM, Rob Herring wrote:
> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa wrote:
>> Hi,
>>
>> This series is a collection of various fixes and extensions we came up
>> with during our attempt to use Mesa for Android.
>>
>> Fixes included in this series:
>> - added manda
On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa wrote:
> Hi,
>
> This series is a collection of various fixes and extensions we came up
> with during our attempt to use Mesa for Android.
>
> Fixes included in this series:
> - added mandatory EGL_MAX_PBUFFER_WIDTH and _HEIGHT attributes to EGL
>c
On Tue, Jul 19, 2016 at 2:35 AM, Emil Velikov wrote:
> On 18 July 2016 at 16:38, Tomasz Figa wrote:
>> On Mon, Jul 18, 2016 at 11:58 PM, Emil Velikov
>> wrote:
>>> On 18 July 2016 at 13:02, Tomasz Figa wrote:
On Mon, Jul 18, 2016 at 7:28 PM, Emil Velikov
wrote:
> Hi Tomasz,
>>>
On Monday, July 18, 2016 10:58:25 PM PDT Pali Rohár wrote:
> Any conclusion or fix for this issue?
Dylan suggested you use pip --user to install a newer version of Mako.
Is that a workable solution to your problem?
I'm having a hard time getting excited about making upstream support
building agai
July 18 2016 1:10 PM, "Emil Velikov" wrote:
> On 18 July 2016 at 16:28, Alexander von Gluck IV
> wrote:
>
>> July 18 2016 9:20 AM, "Emil Velikov" wrote:
>>> On 18 July 2016 at 14:39, Alexander von Gluck IV
>>> wrote:
>>>
July 18 2016 3:29 AM, "Nicolai Hähnle" wrote:
> A comment fu
Fixes a 10-20% performance regression in OglCSDof caused by commit
5a8c89038abab0184ea72664ab390ec6ca58b4d6, which made images (in the
image load/store sense) use BDW_MOCS_PTE instead of BDW_MOCS_WB.
This seems sketchy, as the default PTE value is supposed to be
WB LLC eLLC, which is the same as o
Also, feel free to cc the while lot to stable since it really is a gen7
fix. I guess you could leave 6-7 off stable if you want but Meh.
On Jul 18, 2016 6:33 PM, "Jason Ekstrand" wrote:
> Series is
>
> Reviewed-by: Jason Ekstrand
>
> Thanks for cleaning this up. The more we can share code the
Series is
Reviewed-by: Jason Ekstrand
Thanks for cleaning this up. The more we can share code the better I say.
On Jul 18, 2016 6:06 PM, "Kenneth Graunke" wrote:
> This should fix MOCS values. Caught by Coverity.
>
> CID: 1364155
>
> Signed-off-by: Kenneth Graunke
> ---
> src/intel/vulkan/
Any conclusion or fix for this issue?
On Saturday 16 July 2016 02:52:50 Jason Ekstrand wrote:
> Adding Dylan
>
> On Jul 14, 2016 10:24 PM, "Samuel Iglesias Gonsálvez"
>
>
> wrote:
> > On 14/07/16 18:34, Eric Engestrom wrote:
> > > On Thu, Jul 14, 2016 at 04:01:13PM +0100, Eric Engestrom wrote:
I am interested in this project idea.I want some help regarding it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This should fix MOCS values. Caught by Coverity.
CID: 1364155
Signed-off-by: Kenneth Graunke
---
src/intel/vulkan/anv_cmd_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_cmd_buffer.c
b/src/intel/vulkan/anv_cmd_buffer.c
index 6256df8..380260a 1
The bulk of this is the same. There are just a couple fields that only
exist on one generation or another, and we can easily handle those with
an #ifdef.
Signed-off-by: Kenneth Graunke
---
src/intel/vulkan/gen7_pipeline.c | 23 ++
src/intel/vulkan/gen8_pipeline.c |
Signed-off-by: Kenneth Graunke
---
src/intel/genxml/gen6.xml| 1 +
src/intel/genxml/gen7.xml| 1 +
src/intel/genxml/gen75.xml | 1 +
src/intel/genxml/gen8.xml| 3 ++-
src/intel/genxml/gen9.xml| 3 ++-
src/intel/vulkan/gen8_pipeline.c | 2 +-
6 files changed,
See commit b0629e6894513a2c49a018bc3342a4e55435a236, where we discovered
that the SOL stage's "Rendering Disable" feature is a lot faster at
throwing away all geometry than the clipper's "reject all" mode.
Signed-off-by: Kenneth Graunke
---
src/intel/vulkan/gen7_pipeline.c | 1 +
src/intel
Gen6-7.5 use CLIPMODE_REJECT_ALL, while Gen8+ just used REJECT_ALL.
Being consistent will let me unify code, and I prefer having the prefix.
Signed-off-by: Kenneth Graunke
---
src/intel/genxml/gen8.xml| 6 +++---
src/intel/genxml/gen9.xml| 6 +++---
src/intel/vulkan/gen8_pipeline
We set the cull mode, but forgot the enable bit. Gen8 uses this.
Signed-off-by: Kenneth Graunke
---
src/intel/vulkan/gen7_pipeline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index a50d9c7..a9f5e0b 100644
--- a/src/in
The Gen7/7.5 clip code used APIMODE_OGL, while the Gen8+ clip code used
APIMODE_D3D. The meaning hasn't changed, so one of these must be wrong.
It appears that the hardware documentation is completely wrong. It
claims that the "API Mode" bit means:
0hAPIMODE_OGLNEAR_VP boundary == 0.
Gen7/7.5 call it "Rendering Disable" while Gen8/9 prefix it with "API".
Pick one for consistency, and so we can share code between generations.
Signed-off-by: Kenneth Graunke
---
src/intel/genxml/gen8.xml | 2 +-
src/intel/genxml/gen9.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On Mon, 2016-07-18 at 15:49 -0700, Kenneth Graunke wrote:
So this fixes a bug with indirects right? Is there a piglit test for
this?
With the typo Ilia pointed out fixed, both are:
Reviewed-by: Timothy Arceri
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp
On Mon, 2016-07-18 at 15:49 -0700, Kenneth Graunke wrote:
So this fixes a bug with indirects right? Is there a piglit test for
this?
With the typo Ilia pointed out fixed.
Reviewed-by: Timothy Arceri
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 15 +
Zhang, Boyuan wrote:
Hi Andy,
I just submitted another patch set, most of the issues you reported are solved,
please see the information below:
- Giving different frame rate should result different output size. The final
result from my side is very close to the CBR I set. Please give a try wi
possibly.. although sprinkling queue_barrier() calls (which is at
least useful for debugging, although I think I won't use it in the end
after debugging) hasn't found the issue yet. I did at least find an
issue w/ fence handling (I was grabbing the fence # potentially before
the batch was flushed)
On Mon, Jul 18, 2016 at 9:50 AM, Jordan Justen
wrote:
> On 2016-07-18 09:14:48, Jason Ekstrand wrote:
> > Thanks to rebase fail, recent surface state changes effectively reverted
>
> This happened in 09b5a71517fadd6c20b72e7ad9ea1f7539c93a42, right?
> Should we mention that commit?
>
Done
> Rev
I think your issue is that you have self-releasing jobs with the
cleanup callback and you automatically lose fences that way, so there
is no way to wait for completion.
Since you have only 1 thread with N jobs at most, I suggest you keep
N+1 fences around (a ring of fences) that you reuse for new
https://bugs.freedesktop.org/show_bug.cgi?id=96979
--- Comment #3 from Ilia Mirkin ---
(In reply to Kenneth Graunke from comment #2)
> This isn't something we want to support.
>
> We should probably use fprintf rather than _mesa_problem so it doesn't print
> "Mesa: implementation error" as it i
Hi Andy,
I just submitted another patch set, most of the issues you reported are solved,
please see the information below:
- Giving different frame rate should result different output size. The final
result from my side is very close to the CBR I set. Please give a try with
different frame rat
On Mon, Jul 18, 2016 at 6:49 PM, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i
Commit 52e75dcb8c04c0dde989970c4c587cbe8313f7cf made nir_lower_io
start using nir_intrinsic_set_base instead of writing const_index[0]
directly. However, those intrinsics apparently don't /have/ a base,
so this caused assert failures.
However, the old code was happily setting non-existent const_i
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 6265dc6..a39c37e 100644
--- a/src/mesa/driver
Add some hardcoded values hardware needs mainly for rate control purpose. With
previously hardcoded values for OMX, the rate control result is not correct.
This change fixed the rate control result by setting correct values for Vaapi.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/
Enable H.264 VAAPI encoding through config. Currently only H.264 baseline is
supported.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/config.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/va/con
Add environmental variable to disable interlace mode. At VAAPI decoding stage,
driver can not distinguish b/w pure decoding case and transcoding case. And
since interlace encoding is not supported, we have to disable interlace for
transcoding case. The temporary solution is to use enviromental v
Rate control method is passed from app to driver through config attrib list.
That is why we need to store this rate control method to config. And later on,
we will pass this value to context->desc.h264enc.rate_ctrl.rate_ctrl_method.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call.
We need this function in VaPutImage call where copying from yv12 image to nv12
surface for encoding. Existing function can't be used because it only work for
copying from yv12 surface to nv12 image in Vaapi.
Signed-of
Add necessary functions/changes for VAAPI encoding to buffer and picture. These
changes will allow driver to handle all Vaapi encode related operations. This
patch doesn't change the Vaapi decode behaviour.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/buffer.c | 6 +
src
For putimage call, if image format is yv12 (or IYUV with U V field swap) and
surface format is nv12, then we need to convert yv12 to nv12 and then copy the
converted data from image to surface. We can't use the existing logic where
surface is destroyed and re-created with yv12 format.
Signed-of
VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We
will save this encode entry point in config. config_id was used as profile
previously. Now, config has both profile and entrypoint field, and config_id is
used to get the config object. Later on, we pass this entrypoi
Add entrypoint to distinguish H.264 decode and encode. For example, in patch
5/11 when is calling "VaCreateContext", "pps" and "sps" shouldn't be allocated
for H.264 encoding. So we need to use the entry_point to determine this is
H.264 decode or H.264 encode. We can use config to determine the
https://bugs.freedesktop.org/show_bug.cgi?id=96979
--- Comment #2 from Kenneth Graunke ---
This isn't something we want to support.
We should probably use fprintf rather than _mesa_problem so it doesn't print
"Mesa: implementation error" as it isn't an implementation issue -
it's a warning to t
On 07/18/2016 11:13 PM, Ilia Mirkin wrote:
On Mon, Jul 18, 2016 at 4:55 PM, Samuel Pitoiset
wrote:
On Maxwell, images binding is slightly different (and much better)
regarding Fermi and Kepler because a texture view needs to be uploaded
for each image and this is going to simplify the thing a
On Fri, Jun 17, 2016 at 5:25 PM, Rob Herring wrote:
> Exported dmabufs can get imported by the same process, but the handle was
> not getting added to the hash table on export. Add the handle to the hash
> table on export.
Ping. Dave, can you please apply.
Rob
>
> Cc: Dave Airlie
> Signed-off-
On 07/18/2016 11:16 PM, Ilia Mirkin wrote:
Karol tested it on Kepler1, so we should be good.
Reviewed-by: Samuel Pitoiset
On Mon, Jul 18, 2016 at 5:15 PM, Samuel Pitoiset
wrote:
Works fine on Fermi, but still need to test on Kepler1.
On 07/16/2016 09:09 PM, Ilia Mirkin wrote:
This i
Karol tested it on Kepler1, so we should be good.
On Mon, Jul 18, 2016 at 5:15 PM, Samuel Pitoiset
wrote:
> Works fine on Fermi, but still need to test on Kepler1.
>
>
> On 07/16/2016 09:09 PM, Ilia Mirkin wrote:
>>
>> This is useful for pbo downloads, which are now accelerated with images.
>> BG
Works fine on Fermi, but still need to test on Kepler1.
On 07/16/2016 09:09 PM, Ilia Mirkin wrote:
This is useful for pbo downloads, which are now accelerated with images.
BGRA8 is a moderately common format to do that in.
Signed-off-by: Ilia Mirkin
---
This needs testing on SM20 and SM30. I'
On Mon, Jul 18, 2016 at 4:55 PM, Samuel Pitoiset
wrote:
> On Maxwell, images binding is slightly different (and much better)
> regarding Fermi and Kepler because a texture view needs to be uploaded
> for each image and this is going to simplify the thing a lot.
>
> Signed-off-by: Samuel Pitoiset
Well, I have a basic review on this from Eric Engestrom, who is not a
mesa expert (yet?) but has been giving out a lot of good review
comments lately, and nobody else has piped up saying they hate this,
so I'm going to push this in the next few days unless I hear any
objections. IMHO this is a nice
On Mon, Jul 18, 2016 at 1:41 PM, Kenneth Graunke wrote:
> Both branches are identical. Fixes a Coverity warning.
>
> CID: 1364155
>
> Signed-off-by: Kenneth Graunke
> ---
> src/intel/vulkan/anv_cmd_buffer.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/intel/v
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 50 ++
1 file changed, 50 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 871ffd2.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index ae0dd78..22f2f5d 100644
--- a/src/galli
MS images have to be handled explicitly and I don't plan to implement
them for now.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/n
On Maxwell, images binding is slightly different (and much better)
regarding Fermi and Kepler because a texture view needs to be uploaded
for each image and this is going to simplify the thing a lot.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 5 +-
src
Signed-off-by: Samuel Pitoiset
---
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 76 +-
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 2 +
2 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cp
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 25 --
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 63fe9c0.
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 105 +
1 file changed, 105 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index f1ba27a
Currently, we can store 32 tex handles of 32-bits integer each and
that fits perfectly with the underlying hardware except on GM107+
which requires to upload a texture view for each images.
This patch increases the number of storable texture handles in the
driver constant buffer from 32 to 40 beca
Hi folks,
This series adds support for ARB_shader_image_load_store (GL 4.2) and
ARB_shader_image_size (GL 4.3) on Maxwell GPUs.
Maxwell family is slightly different regarding Fermi and Kepler because it
requires to use a texture view for each images. But this is actually quite
fine because the un
On Mon, Jul 11, 2016 at 10:49 AM, Matt Turner wrote:
> According to https://llvm.org/bugs/show_bug.cgi?id=19778#c3 this code
> was violating the spec, resulting in it failing to compile.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Co-authored-by: Tomasz Paweł Gajc
> Bugzilla: https://bugs.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=89599
--- Comment #11 from Matt Turner ---
I sent a modified version of Tomasz's patch last week to mesa-dev.
Would anyone like to test it?
[PATCH] mapi: Massage code to allow clang to compile.
--
You are receiving this mail because:
You are the as
On Mon, Jul 18, 2016 at 4:34 PM, Nicolai Hähnle wrote:
> On 18.07.2016 22:25, Rob Clark wrote:
>>
>> Helper to block until all previous jobs are complete.
>> ---
>> So I think this might end up being useful to me in some cases.. but
>> the implementation only works for a single threaded queue (whi
Both branches are identical. Fixes a Coverity warning.
CID: 1364155
Signed-off-by: Kenneth Graunke
---
src/intel/vulkan/anv_cmd_buffer.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/intel/vulkan/anv_cmd_buffer.c
b/src/intel/vulkan/anv_cmd_buffer.c
index 6256df8.
On 18.07.2016 22:25, Rob Clark wrote:
Helper to block until all previous jobs are complete.
---
So I think this might end up being useful to me in some cases.. but
the implementation only works for a single threaded queue (which is
all I need). I could also just put a helper in my driver code.
We no longer use this message. As far as I can tell, it's fairly
useless - the equivalent information is provided in the payload.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h| 1 -
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 --
src/mesa/drivers/dri/
Currently, i965 interpolates all FS inputs at the top of the program.
This has advantages and disadvantages, but I'd like to keep that policy
while reworking this code. We can consider changing it independently.
The next patch will make the compiler generate PLN instructions "on the
fly", when it
When working with a non-multisampled render target, asking for "sample"
interpolation locations doesn't make sense. We demote them to centroid.
In a couple of patches, brw_compute_barycentric_modes will begin looking
at these intrinsics to determine the barycentric modes. fs_visitor also
will us
Now nir_lower_io can optionally produce load_interpolated_input
and load_barycentric_* intrinsics for fragment shader inputs.
flat inputs continue using regular load_input.
Signed-off-by: Kenneth Graunke
---
src/compiler/nir/nir_lower_io.c | 94 ++---
1 file
This eliminates the need to walk the list of input variables, recurse
into their types (via logic largely redundant with nir_lower_io), and
interpolate all possible inputs up front. The backend no longer has
to care about variables at all, which eliminates complications from
trying to pack multipl
While my intention is that the new intrinsics should be usable by all
drivers, we need to make them optional until all drivers switch.
This doesn't do anything yet, but I added it as a separate patch to
keep the interface churn separate for easier review.
Signed-off-by: Kenneth Graunke
---
src/
Backends can normally handle shader inputs solely by looking at
load_input intrinsics, and ignore the nir_variables in nir->inputs.
One exception is fragment shader inputs. load_input doesn't capture
the necessary interpolation information - flat, smooth, noperspective
mode, and centroid, sample,
Helper to block until all previous jobs are complete.
---
So I think this might end up being useful to me in some cases.. but
the implementation only works for a single threaded queue (which is
all I need). I could also just put a helper in my driver code.
Opinions?
src/gallium/auxiliary/util/u
HIGH_QUALITY_SCALING_L2 to HIGH_QUALTIY_SCALING_L9
uses lanczos filter with number representing the size
of the sinc window.
Signed-off-by: Nayan Deshmukh
---
src/gallium/state_trackers/vdpau/mixer.c | 116 ---
src/gallium/state_trackers/vdpau/query.c | 8 ++
1 - 100 of 193 matches
Mail list logo
