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
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
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
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
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
__
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
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
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
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
__
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
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/
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_
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
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
---
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
---
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
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
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
+
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
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
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
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
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
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
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
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
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
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
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?
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
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/
In the title s/contant/constant/.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 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
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
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.
>
>
> 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
> 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
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
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: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 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 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 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 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 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 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 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 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
---
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
+++
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(
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/
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
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:
>
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: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
Good idea.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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: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
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 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/
> 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 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
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
:-)
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
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
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/
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
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: 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.
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
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
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
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
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
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
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
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
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/cubetexture9.c | 4
src/gallium/state_trackers/nine/texture9.c | 3 +++
src/gallium/state_trackers/nine/volumetexture9.c | 9 +
3 files changed, 16 insertions(+)
diff --git a/src/gallium/state_trackers/nine/cubetex
That part of the code was quite obscure.
This new implementation tries to make it clearer
by separating the differents parts, and commenting more.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/basetexture9.c | 221 ++---
1 file changed, 125 insertions(+), 96 de
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/basetexture9.c | 82
src/gallium/state_trackers/nine/basetexture9.h | 19 +++---
src/gallium/state_trackers/nine/cubetexture9.c | 2 +-
src/gallium/state_trackers/nine/device9.c| 2 +-
src/galliu
Remove the Surface9 code for dirty rects, used only for Managed
resources. Instead convey the information to the parent texture.
According to documentation, this seems to be the expected behaviour,
and if documentation is wrong there, that's not a problem since it can
only leads to more texture up
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/cubetexture9.c | 3 +++
src/gallium/state_trackers/nine/device9.c| 5 +
src/gallium/state_trackers/nine/indexbuffer9.c | 14 --
src/gallium/state_trackers/nine/texture9.c | 5 +
src/gallium/state
Some applications assume the memory for multilevel
textures is allocated per continuous blocks.
This patch implements that behaviour.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/cubetexture9.c | 42 --
src/gallium/state_trackers/nine/cubetexture9.h | 1 +
s
From: Patrick Rudolph
This adds an additional check to make sure the bound depth-buffer doesn't
exceed the rendertarget size when clearing depth and color buffer at once.
D3D9 clears only a rectangle with the same dimensions as the viewport, leaving
other parts of the depth-buffer intact.
This f
On Fri, Apr 24, 2015 at 12:59:53PM +0200, EdB wrote:
> Since clover should compile use -std=c++11,
> compat classes are no longer neccessary
>
Thank you for working on this, it is a nice improvement. I will try to
review/test these early next week.
Thanks,
Tom
> EdB (4):
> clover: remove com
Can you use the fe* class of functions for this? Not entirely sure
what this is setting, but you should be able to do it with
fegetenv/fesetenv, or the more specialized functions.
On Fri, Apr 24, 2015 at 4:09 PM, Axel Davy wrote:
> From: Tiziano Bacocco
>
> Signed-off-by: Tiziano Bacocco
> ---
One more comment, that I neglected to add: there are other checks for
_CurrentFragmentProgram to be non-NULL, indeed function
brw_upload_wm_abo_surface() [file brw_wm_surface_state.c], also
has a check for it being non-NULL. That function is the emit for
the atom brw_wm_abo_surfaces which is pre
On Fri, Apr 24, 2015 at 4:09 PM, Axel Davy wrote:
> 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_tra
Reviewed-by: Ilia Mirkin
On Fri, Apr 24, 2015 at 4:09 PM, Axel Davy wrote:
> 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
1 - 100 of 188 matches
Mail list logo
