Copying to/from a Managed texture is forbidden.
Rendering to a Managed texture is forbidden.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/surface9.c | 23 +--
src/gallium/state_trackers/nine/volume9.c | 19 +++
2 files changed, 8 insertions(+)
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/volume9.c| 3 ---
src/gallium/state_trackers/nine/volumetexture9.c | 14 +-
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/src/gallium/state_trackers/nine/volume9.c
b/src/gallium/state_trackers/nine
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c| 4 +++-
src/gallium/state_trackers/nine/device9.h| 4
src/gallium/state_trackers/nine/nine_state.c | 24
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 14 +-
src/gallium/state_trackers/nine/surface9.c | 2 +-
src/gallium/state_trackers/nine/surface9.h | 3 +++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/nine/dev
For D3DUSAGE_AUTOGENMIPMAP textures, applications can only
lock/copy from/get surface descriptor for/etc the first level.
Thus it makes sense to restrict the LOD to 0, and use only the first
level to generate the sublevels.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/basetexture
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_shader.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/gallium/state_trackers/nine/nine_shader.c
index 2ba625e..0fd3d37 100644
--- a/src
No major vendor advertises it, and we weren't supporting it.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/adapter9.c | 2 +-
src/gallium/state_trackers/nine/device9.c | 10 ++
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/nine
Here are 16 various fixes for Gallium Nine.
They should be independent from each other.
Next is a serie of 11 patches to rework the handling
of the MANAGED pool for textures. This is a pool for which
all textures have a ram backing, which is uploaded when needed
to gpu memory. They have several re
From: Xavier Bouchoux
render_condition_enable was uninitialized.
Reviewed-by: Axel Davy
Signed-off-by: Xavier Bouchoux
---
src/gallium/state_trackers/nine/device9.c| 2 ++
src/gallium/state_trackers/nine/swapchain9.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/gallium/state
Previous code was trying to optimise to call set_vertex_buffers on
big packets, and thus avoids as many calls as possible.
However in practice doing so won't be faster (drivers implement
set_vertex_buffers by a loop over the buffers we want to bind)
When we want to unbind a buffer, we were callin
From: Xavier Bouchoux
Avoid blocking when retrieving D3DQUERYTYPE_TIMESTAMP result with
NineQuery9_GetData(), when D3DGETDATA_FLUSH is not specified.
This mimics Win behaviour and gives slightly better performance
for some games.
Reviewed-by: Axel Davy
Signed-off-by: Xavier Bouchoux
---
src/g
From: Xavier Bouchoux
Was sometimes too large for PS.
Reviewed-by: Axel Davy
Signed-off-by: Xavier Bouchoux
---
src/gallium/state_trackers/nine/nine_shader.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/galliu
The sampler src index was wrong for texldl and texldd
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_shader.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/gallium/state_trackers/nine/nine_shade
From: Xavier Bouchoux
D3DQUERYTYPE_TIMESTAMPFREQ is supposed to give the frequency
at which the clock of D3DQUERYTYPE_TIMESTAMP runs.
PIPE_QUERY_TIMESTAMP returns a value in ns, thus the corresponding
frequency is 10.
PIPE_QUERY_TIMESTAMP_DISJOINT returns the frequency at which
PIPE_QUER
Previously binding an unitialized managed texture
was causing a crash, and a workaround was added to
prevent the crash.
This patch removes this workaround and instead set the initial
state of managed textures as dirty, so that when the texture is bound
for the first time, it is always initialized.
It wasn't uploading the texture when the lod
had changed.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/basetexture9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/basetexture9.c
b/src/gallium/state_trackers/nine/basetexture9
From: Xavier Bouchoux
This behaviour matches windows drivers.
Reviewed-by: Axel Davy
Signed-off-by: Xavier Bouchoux
---
src/gallium/state_trackers/nine/adapter9.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/adapter9.c
b/src/gallium/st
From: Tiziano Bacocco
Signed-off-by: Tiziano Bacocco
---
src/gallium/state_trackers/nine/device9.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index 1a776a7..4ef02bb 100644
--- a/src/
This code was supposed to be removed, but a rebase seems to have
made it stay.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_state.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_state.c
b/src/gallium/state_trackers/nine/nine_stat
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_state.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nine_state.c
b/src/gallium/state_trackers/nine/nine_state.c
index 6c7eab3..27800c6 100644
--- a/src/gallium/state_tra
util_gen_mipmap uses pipe->blit, and thus doesn't need
we restore all states after using it.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/basetexture9.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/state_trackers/nine/basetexture9.c
b/src/gallium/state_tracke
I want to add one more comment on why to replace with the _mesa_geometry_
functions, which I had thought was so obvious I neglected to mention it:
With this series the meaning of gl_framebuffer::Width, Height, and so on have a
different meaning. They give the intersection of the backing stores o
On 23/04/15 12:15, Francisco Jerez wrote:
> Emil Velikov writes:
>
>> Humble ping.
>>
> This patch is obsolete. IIRC Tom sent a v2 to which I replied with some
> (mostly trivial) suggestions. There's no v3 yet AFAIK.
>
I noticed the other email, although I got v1 and v2 swapped in my queue
:-)
On Tuesday, March 31, 2015 01:56:32 PM Alex Deucher wrote:
> I would prefer to keep support for AMD_performance_monitor in mesa.
> We may implement more extensive support for this extension in our
> radeon open source drivers and it would be nice to be compatible with
> our closed source drivers on
> Checking brw->ctx.Shader._CurrentFragmentProgram != NULL is unnecessary.
> There is always a valid pixel shader. (If the application is using
> fixed-function, we supply a fragment shader for them.) Please drop that
> check.
Without this check(in the Gen7 function/code), about 30 crashes a
On Friday, April 24, 2015 11:28:03 AM Matt Turner wrote:
> This reverts commit 9f5e5bd34d8ba48c851b442fb88f742b1ba6a571.
>
> I have no idea what made me believe these didn't apply to Gen > 7. They
> do, and without them we generate bad code that causes failures on Gen 8.
> ---
> src/mesa/drivers/
Kenneth Graunke writes:
> On Friday, April 24, 2015 09:59:09 AM kevin.rogo...@intel.com wrote:
>> From: Kevin Rogovin
>>
>> Ensure that the GPU spawns the fragment shader thread for those
>> fragment shaders with atomic buffer access.
>>
>> ---
>> src/mesa/drivers/dri/i965/gen7_wm_state.c |
On Fri, Apr 17, 2015 at 04:51:37PM -0700, Anuj Phogat wrote:
> Currently, that's the only path that supports reading data from these buffers.
>
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/dri/i965/intel_pixel_read.c | 22 --
> src/mesa/drivers/dri/i965/intel_tex_ima
https://bugs.freedesktop.org/show_bug.cgi?id=89599
--- Comment #3 from yunl...@chromium.org ---
Can we land this?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
me
On Fri, Apr 17, 2015 at 04:51:36PM -0700, Anuj Phogat wrote:
> No other path currently supports uploading data to these surfaces.
>
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/dri/i965/intel_tex_image.c| 24 ++--
> src/mesa/drivers/dri/i965/intel_tex_subimage.c
Good idea.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Apr 23, 2015 at 04:49:56PM -0700, Ben Widawsky wrote:
> While trying to debug Skylake fast color clears, I noticed that the surface
> state generated by our decoder was woefully inadequate. Much of the dumped
> state
> was so stale as to be useless.
>
> Just to be clear, the code is not a
Give the user some idea about the size of the texture which caused
the GL_OUT_OF_MEMORY error.
---
src/mesa/main/teximage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d07263c..7bc1da7 100644
--- a/src/mesa/main/t
On Thu, Apr 23, 2015 at 04:50:04PM -0700, Ben Widawsky wrote:
> OLD:
> 0x7340: 0x0080:BLEND:
> 0x7344: 0x84202100:BLEND:
>
> NEW:
> 0x7340: 0x0080:BLEND: Alpha blend/test
> 0x7344: 0x000b84202100: BLEND_ENTRY00:
>
We have to use W/UW type for src1 of the multiply in the MUL/MACH macro,
but in order to read the low 16-bits of each 32-bit integer, we need to
set the appropriate stride.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i
Copy over from brw_fs_visitor.cpp.
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 9564764..523e56d 100644
--- a/src/
This reverts commit 9f5e5bd34d8ba48c851b442fb88f742b1ba6a571.
I have no idea what made me believe these didn't apply to Gen > 7. They
do, and without them we generate bad code that causes failures on Gen 8.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++---
1 file changed, 3 insertions(
---
docs/relnotes/10.6.0.html| 1 +
src/mesa/drivers/dri/i965/intel_extensions.c | 8 ++--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/docs/relnotes/10.6.0.html b/docs/relnotes/10.6.0.html
index 48f76f9..dbf1229 100644
--- a/docs/relnotes/10.6.0.html
+++
On Thu, Apr 23, 2015 at 04:50:02PM -0700, Ben Widawsky wrote:
> Gen9 surface state is very similar to the previous generation. The important
> changes here are aux mode, and the way clear colors work.
>
> NOTE: There are some things intentionally left out of this decoding.
>
> Signed-off-by: Ben
On Thu, Apr 23, 2015 at 4:38 PM, Pohjolainen, Topi
wrote:
> On Fri, Apr 17, 2015 at 04:51:23PM -0700, Anuj Phogat wrote:
>> This refactoring is required by later patches in this series.
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/drivers/dri/i965/brw_tex_layout.c| 19 +++-
On Thursday, April 23, 2015 04:49:57 PM Ben Widawsky wrote:
> It's true that not all surfaces apply for every gen, but for the most part
> this
> is what we want. (The unfortunate case is when we use an valid surface, but
> not
> for the specific GEN).
>
> This was automated with a vim macro.
>
On Fri, Apr 24, 2015 at 08:47:41PM +0300, Pohjolainen, Topi wrote:
> On Thu, Apr 23, 2015 at 04:50:00PM -0700, Ben Widawsky wrote:
> > AFAICT, none of the old data was wrong (the gen7 decoder), but it wa
> > smissing a
> > bunch of stuff.
> >
> > Adds a tick (') to denote the beginning of the sur
On Thu, Apr 23, 2015 at 04:50:00PM -0700, Ben Widawsky wrote:
> AFAICT, none of the old data was wrong (the gen7 decoder), but it wa smissing
> a
> bunch of stuff.
>
> Adds a tick (') to denote the beginning of the surface state for easier
> reading.
> This will be replaced later with some bette
On Friday, April 24, 2015 09:59:09 AM kevin.rogo...@intel.com wrote:
> From: Kevin Rogovin
>
> Ensure that the GPU spawns the fragment shader thread for those
> fragment shaders with atomic buffer access.
>
> ---
> src/mesa/drivers/dri/i965/gen7_wm_state.c | 7 +++
> src/mesa/drivers/dri/i
On Fri, Apr 24, 2015 at 08:20:49PM +0300, Pohjolainen, Topi wrote:
> On Thu, Apr 23, 2015 at 04:49:59PM -0700, Ben Widawsky wrote:
> > OLD:
> > 0x7e00: 0x1000: WM SAMP0: filtering
> > 0x7e04: 0x000d: WM SAMP0: wrapping, lod
> > 0x7e08: 0x: WM SAMP0: defaul
On Friday, April 24, 2015 08:02:58 AM Neil Roberts wrote:
> If a send message is emitted with a message length that is less than
> required for the message then the remaining parameters default to
> zero. We can take advantage of this to save a register when a shader
> passes constant zeroes as the
On Thu, Apr 23, 2015 at 04:49:59PM -0700, Ben Widawsky wrote:
> OLD:
> 0x7e00: 0x1000: WM SAMP0: filtering
> 0x7e04: 0x000d: WM SAMP0: wrapping, lod
> 0x7e08: 0x: WM SAMP0: default color pointer
> 0x7e0c: 0x0090: WM SAMP0: chroma key, aniso
>
On Thu, Apr 23, 2015 at 11:38 AM, Pohjolainen, Topi
wrote:
> On Fri, Apr 17, 2015 at 04:51:24PM -0700, Anuj Phogat wrote:
>> Patch continues code refactoring.
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/drivers/dri/i965/brw_tex_layout.c| 105
>> ++
>> src/mes
On Thu, Apr 23, 2015 at 04:49:58PM -0700, Ben Widawsky wrote:
> 0x7da0: 0xc1da740e: SF_CLIP VP: guardband xmin = -27.306667
> 0x7da4: 0x41da740e: SF_CLIP VP: guardband xmax = 27.306667
> 0x7da4: 0x41da740e: SF_CLIP VP: guardband ymin = -23.405714
> 0x7da8: 0xc1bb
> I'll check with Jordan and others. I have a faint recollection that compute
> shaders have similar
> needs. I think your change is fine though, I just want to understand the
> bigger picture first.
I do not think compute shaders have similar needs. These flags are for making
sure the
rast
> My point specifically was that you are also updating atoms that _are not_
> re-used.
> And as those changes are not really needed, I wouldn't take the risk of
> changing
> something in vain. I would introduce them only when you have patches to
> really enable older generations.
My take is
On Fri, Apr 24, 2015 at 07:02:18PM +0300, Rogovin, Kevin wrote:
>
> > Actually I realized that you add quite a bit of support to gen4-6 logic
> > that
> > _isn't_ used for gen7 and higher. In the last patch of the series you claim
> > to enable this only for gen7 and higher - I'm confused.
>
>
On Fri, Apr 24, 2015 at 09:59:09AM +0300, kevin.rogo...@intel.com wrote:
> From: Kevin Rogovin
>
> Ensure that the GPU spawns the fragment shader thread for those
> fragment shaders with atomic buffer access.
>
> ---
> src/mesa/drivers/dri/i965/gen7_wm_state.c | 7 +++
> src/mesa/drivers/d
> Actually I realized that you add quite a bit of support to gen4-6 logic that
> _isn't_ used for gen7 and higher. In the last patch of the series you claim
> to enable this only for gen7 and higher - I'm confused.
There are two reasons:
1. Because atoms get reused all the time across generatio
In the title s/contant/constant/.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Apr 24, 2015 at 04:19:17PM +0300, Pohjolainen, Topi wrote:
> On Fri, Apr 24, 2015 at 09:59:08AM +0300, kevin.rogo...@intel.com wrote:
> > From: Kevin Rogovin
> >
> > To prepare for i965 to support ARB_framebuffer_no_attachment, use
> > the convenience functions mesa_geometry_width/height/
On Fri, Apr 24, 2015 at 8:02 AM, Neil Roberts wrote:
> If a send message is emitted with a message length that is less than
> required for the message then the remaining parameters default to
> zero. We can take advantage of this to save a register when a shader
> passes constant zeroes as the fin
H that's surprising.
src/mesa/main/tests/dispatch_sanity.cpp:// {
"glFramebufferParameteri", 43, -1 }, // XXX: Add to xml
I thought it should detect that there's a new API and complain loudly.
At least that's how I remembered it working, but that doesn't seem to
be the case?
Hi,
I agree with the comments about the code (and when the last element of the
series is reviewed I will submit the series with review comments taken into
use), but when I applied just Patch 1 and Patch 2, and ran
src/mesa/main/tests/main-test (after a git clean -dfx and all that cleaning)
al
If a send message is emitted with a message length that is less than
required for the message then the remaining parameters default to
zero. We can take advantage of this to save a register when a shader
passes constant zeroes as the final coordinates to the sample
function.
I think this might be
This change will make the dispatch_sanity test fail.
On Fri, Apr 24, 2015 at 3:05 AM, Matt Turner wrote:
> The subject should be prefixed with "mesa:"
>
> On Thu, Apr 23, 2015 at 11:59 PM, wrote:
>> From: Kevin Rogovin
>>
>> Define enumerations, functions and associated glGet's for
>> extensio
Yes, as long as it's core-only, dummy_true is fine.
Marek
On Fri, Apr 24, 2015 at 3:14 PM, Ilia Mirkin wrote:
> The extension is currently marked as GLC, so that equates to dummy_true right?
>
> On Fri, Apr 24, 2015 at 9:00 AM, Brian Paul wrote:
>> Yes, I second that.
>>
>> -Brian
>>
>>
>> On 0
On Fri, Apr 24, 2015 at 09:59:08AM +0300, kevin.rogo...@intel.com wrote:
> From: Kevin Rogovin
>
> To prepare for i965 to support ARB_framebuffer_no_attachment, use
> the convenience functions mesa_geometry_width/height/layers/samples
> to specify the geometry of the render target surfaces to the
The extension is currently marked as GLC, so that equates to dummy_true right?
On Fri, Apr 24, 2015 at 9:00 AM, Brian Paul wrote:
> Yes, I second that.
>
> -Brian
>
>
> On 04/24/2015 04:29 AM, Marek Olšák wrote:
>>
>> I'd enable this if at least GLSL 1.30 was supported. I think drivers
>> like r3
Normally we have brief title on the subject line followed by more elaborate
description of the changes. You had:
Subject: [Mesa-dev] [PATCH 3/7] Complete implementation for
ARB_framebuffer_no_attachment in Mesa core: implement
GetFramebufferParameteriv, FramebufferParameteri and c
Yes, I second that.
-Brian
On 04/24/2015 04:29 AM, Marek Olšák wrote:
I'd enable this if at least GLSL 1.30 was supported. I think drivers
like r300, nv30, i915, and svga shouldn't get this.
Marek
On Fri, Apr 24, 2015 at 3:42 AM, Dave Airlie wrote:
From: Dave Airlie
I'm not sure if we sho
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #1 from Martina Kollarova ---
Created attachment 115303
--> https://bugs.freedesktop.org/attachment.cgi?id=115303&action=edit
glxinfo.output
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=90162
Bug ID: 90162
Summary: glGetFramebufferAttachmentParameteriv failing if
certain FB attributes are zero
Product: Mesa
Version: 10.1
Hardware: Other
OS: Linux
Hi Alex,
For the core driver patch:
+config DRM_AMDGPU
+ tristate "AMD GPU"
+ depends on DRM && PCI
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FW_LOADER
+select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+
Ping for the non-OpenCL stuff.
Thanks,
Marek
On Wed, Apr 15, 2015 at 12:19 AM, Marek Olšák wrote:
> Hi,
>
> This patch series implements:
> - EGL_KHR_fence_sync
> - EGL_KHR_wait_sync
> - EGL_KHR_cl_event2
>
> These extensions are required by EGL 1.5.
>
> EGL_KHR_fence_sync has piglit tests. The
---
src/gallium/state_trackers/clover/Makefile.sources | 1 -
src/gallium/state_trackers/clover/api/program.cpp | 2 +-
.../state_trackers/clover/core/compiler.hpp| 2 +-
src/gallium/state_trackers/clover/core/error.hpp | 6 ++--
src/gallium/state_trackers/clover/util/compat.cpp |
Since clover should compile use -std=c++11,
compat classes are no longer neccessary
EdB (4):
clover: remove compat class that matche std one
clover: remove compat::string
clover: make module::symbol::name a string
clover: remove util/compat
src/gallium/state_trackers/clover/Makefile.sour
---
src/gallium/state_trackers/clover/api/program.cpp | 3 +--
src/gallium/state_trackers/clover/core/module.cpp | 21 +
src/gallium/state_trackers/clover/core/module.hpp | 4 ++--
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/clov
---
src/gallium/state_trackers/clover/api/program.cpp | 2 +-
.../state_trackers/clover/core/compiler.hpp| 14 +--
src/gallium/state_trackers/clover/core/error.hpp | 4 +-
src/gallium/state_trackers/clover/core/program.cpp | 2 +-
.../state_trackers/clover/llvm/invocation.cpp
Functionally correct, style nitpicks below, with those fixed;
Reviewed-by: Tapani Pälli
On 04/24/2015 09:59 AM, kevin.rogo...@intel.com wrote:
From: Kevin Rogovin
To assist drivers to implement ARB_framebuffer_no_attachment, provide
a set of convenience functions that check for gl_framebuffe
I'd enable this if at least GLSL 1.30 was supported. I think drivers
like r300, nv30, i915, and svga shouldn't get this.
Marek
On Fri, Apr 24, 2015 at 3:42 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> I'm not sure if we shouldn't enable this everywhere
> and rip out the API checks,
>
> discus
On Fri, Apr 24, 2015 at 9:43 AM, Zhou, Jammy wrote:
> Hi Alex,
>
> For the core driver patch:
>
> +config DRM_AMDGPU
> + tristate "AMD GPU"
> + depends on DRM && PCI
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + select FW_
Reviewed-by: Tapani Pälli
On 04/24/2015 09:59 AM, kevin.rogo...@intel.com wrote:
From: Kevin Rogovin
Ensure that the GPU spawns the fragment shader thread for those
fragment shaders with atomic buffer access.
---
src/mesa/drivers/dri/i965/gen7_wm_state.c | 7 +++
src/mesa/drivers/dri/
Functionally everything looks correct to me, as a coding style fix,
don't exceed 80 characters per line, there are few lines that do this.
With that fixed;
Reviewed-by: Tapani Pälli
On 04/24/2015 09:59 AM, kevin.rogo...@intel.com wrote:
From: Kevin Rogovin
Complete the implementation of ARB
On 04/23/2015 07:28 PM, Ilia Mirkin wrote:
Add the 4.0/4.1/4.2 extensions lists to compute_version. A coule of
extensions aren't in mesa yet, so those are marked with 0 until they
become supported.
Signed-off-by: Ilia Mirkin
coule -> couple.
--
Petri Latvala
__
On 04/24/2015 09:59 AM, kevin.rogo...@intel.com wrote:
From: Kevin Rogovin
Define enumerations, functions and associated glGet's for
extension ARB_framebuffer_no_attachment.
---
.../glapi/gen/ARB_framebuffer_no_attachments.xml | 33 ++
src/mapi/glapi/gen/Makefile.am
There's trailing white space errors in quite a few lines. I noticed that
patch 4 corrects some of these but you should really fix them in this
commit, patch 4 should not touch them.
On 04/24/2015 09:59 AM, kevin.rogo...@intel.com wrote:
From: Kevin Rogovin
Add extension flag and constant va
The subject should be prefixed with "mesa:"
On Thu, Apr 23, 2015 at 11:59 PM, wrote:
> From: Kevin Rogovin
>
> Define enumerations, functions and associated glGet's for
> extension ARB_framebuffer_no_attachment.
>
> ---
> .../glapi/gen/ARB_framebuffer_no_attachments.xml | 33
Please ignore posting: [PATCH] i965:Fix intel_mipmap_copy_teximage for
GL_TEXTURE_1D_ARRAY.
Sighs. I had put the wrong directory when git send-email. My big apologies for
the idiot-noise.
However, please do NOT ignore the patch series for
ARB_framebuffer_no_attachment.
Best Regards,
-Kevin
__
From: Kevin Rogovin
To assist drivers to implement ARB_framebuffer_no_attachment, provide
a set of convenience functions that check for gl_framebuffer::_HasAttachments
that return the geometry of the gl_framebuffer.
---
src/mesa/main/framebuffer.c | 49 ++
From: Kevin Rogovin
Enable extension GL_ARB_framebuffer_no_attachment in i965 for Gen7
and higher. Lower gens are left disabled because those generations
do not support fragment shaders with side effects.
---
src/mesa/drivers/dri/i965/brw_context.c | 6 ++
src/mesa/drivers/dri/i965/in
From: Kevin Rogovin
Complete the implementation of ARB_framebuffer_no_attachment in Mesa core:
1. Implement _mesa_GetFramebufferParameteriv() and
_mesa_FramebufferParameteri()
2. Additions to _mesa_test_framebuffer_completeness()
---
src/mesa/main/fbobject.c | 153
From: Kevin Rogovin
To prepare for i965 to support ARB_framebuffer_no_attachment, use
the convenience functions mesa_geometry_width/height/layers/samples
to specify the geometry of the render target surfaces to the GPU.
---
src/mesa/drivers/dri/i965/brw_clip_state.c | 9 -
src/mes
101 - 188 of 188 matches
Mail list logo