On 09/30/2013 10:54 PM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> Consider only the top-left and top-right pixels to approximate DDX in a 2x2
> subspan, unless the application requests a more accurate approximation via
> GL_FRAGMENT_SHADER_DERIVATIVE_HINT or this optimization is disabled from the
>
On Tue, Oct 1, 2013 at 12:16 PM, Kenneth Graunke wrote:
> On 09/30/2013 07:16 PM, Ian Romanick wrote:
>> On 09/11/2013 10:00 PM, Chia-I Wu wrote:
>>> From: Chia-I Wu
>>>
>>> Replicate the gradient of the top-left pixel to the other three pixels in
>>> the
>>> subspan, as how DDY is implemented.
From: Chia-I Wu
Consider only the top-left and top-right pixels to approximate DDX in a 2x2
subspan, unless the application requests a more accurate approximation via
GL_FRAGMENT_SHADER_DERIVATIVE_HINT or this optimization is disabled from the
new driconf option disable_derivative_optimization.
On 09/27/2013 06:24 PM, Emil Velikov wrote:
> On 28/09/13 00:45, Kenneth Graunke wrote:
>> This series combines brw_context.[ch] and intel_context.[ch],
>> and cleans up our context creation code quite a bit. A bunch of
>> functionality was awkwardly split between the two sets of files;
>> now it'
On 09/30/2013 05:16 PM, Ian Romanick wrote:
> On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
>> Signed-off-by: Kenneth Graunke
>> ---
>> src/mesa/drivers/dri/i965/brw_context.c | 10 +++---
>> src/mesa/drivers/dri/i965/brw_device_info.c | 9 -
>> src/mesa/drivers/dri/i965/brw_dev
On Mon, Sep 30, 2013 at 07:22:54PM -0700, Ian Romanick wrote:
> On 09/30/2013 05:45 PM, Ben Widawsky wrote:
> > After the last patch, we can replace the region allocated in the miptree
> > creation with a more straightforward (and hopefully smaller resulting)
> > buffer based on the bspec's allocat
On Mon, Sep 30, 2013 at 07:24:08PM -0700, Ian Romanick wrote:
> On 09/30/2013 12:35 PM, Ben Widawsky wrote:
> > Starting with Ivybridge, the hierarchical had relaxed requirements for
> > its allocation. Following a "simple" formula in the bspec was all you
> > needed to satisfy the requirement.
> >
On 09/30/2013 07:16 PM, Ian Romanick wrote:
> On 09/11/2013 10:00 PM, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> Replicate the gradient of the top-left pixel to the other three pixels in the
>> subspan, as how DDY is implemented. Before, different graidents were used
>> for
>> pixels in the top r
On 09/30/2013 05:11 PM, Ian Romanick wrote:
> On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
>> Now that there isn't an intel_context structure, the split between
>> brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary.
>> Removing intel_context.[ch] seems desirable, but not ever
On 09/30/2013 12:35 PM, Ben Widawsky wrote:
> Starting with Ivybridge, the hierarchical had relaxed requirements for
> its allocation. Following a "simple" formula in the bspec was all you
> needed to satisfy the requirement.
>
> To prepare the code for this, extract all places where the miptree w
On 09/30/2013 05:45 PM, Ben Widawsky wrote:
> After the last patch, we can replace the region allocated in the miptree
> creation with a more straightforward (and hopefully smaller resulting)
> buffer based on the bspec's allocation formula.
>
> Since I am relatively new to this part of the bspec,
On 09/11/2013 10:00 PM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> Replicate the gradient of the top-left pixel to the other three pixels in the
> subspan, as how DDY is implemented. Before, different graidents were used for
> pixels in the top row and pixels in the bottom row.
>
> This change resu
On Tue, Oct 1, 2013 at 3:43 AM, Ian Romanick wrote:
> On 09/30/2013 05:47 PM, Roland Mainz wrote:
>> On Tue, Oct 1, 2013 at 2:27 AM, Ian Romanick wrote:
>>> On 09/27/2013 04:46 PM, Kenneth Graunke wrote:
This was only used for uploading batchbuffer data, and only on 32-bit
systems. If
On 09/30/2013 05:47 PM, Roland Mainz wrote:
> On Tue, Oct 1, 2013 at 2:27 AM, Ian Romanick wrote:
>> On 09/27/2013 04:46 PM, Kenneth Graunke wrote:
>>> This was only used for uploading batchbuffer data, and only on 32-bit
>>> systems. If this is actually useful, we might want to use it more
>>> w
On Mon, Sep 30, 2013 at 11:46:26PM +0200, Vincent Lejeune wrote:
Could you go through and wrap some on the long lines that you are adding
in the other patches.
With that fix, the entire series is:
Reviewed-by: Tom Stellard
> ---
> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 3 ++-
>
On Mon, Sep 30, 2013 at 11:46:25PM +0200, Vincent Lejeune wrote:
> ---
> lib/Target/R600/R600ISelLowering.cpp | 6 +-
> lib/Target/R600/R600Instructions.td | 4
> lib/Target/R600/R600Intrinsics.td| 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Target/R
On 09/30/2013 12:08 PM, Kenneth Graunke wrote:
> On 09/30/2013 11:03 AM, Ian Romanick wrote:
>> On 09/30/2013 03:08 AM, Chris Forbes wrote:
>>> From: Maxence Le Dore
>>>
>>> V2 [Chris Forbes]:
>>>- Add new pattern, fixup parameter reading.
>>>
>>> V3: Rebase onto new builtins machinery
>>>
>>>
On 09/15/2013 02:58 AM, Chris Forbes wrote:
> From: Maxence Le Dore
>
> Reviewed-by: Kenneth Graunke
> ---
> src/mapi/glapi/gen/ARB_texture_gather.xml | 14 ++
> src/mapi/glapi/gen/gl_API.xml | 2 +-
> src/mesa/main/context.c | 4
> src/mesa/main
On 09/15/2013 02:58 AM, Chris Forbes wrote:
> From: Maxence Le Dore
>
> V2 [Chris Forbes]:
>- Add new pattern, fixup parameter reading.
>
> V3: Rebase onto new builtins machinery
>
> Reviewed-by: Kenneth Graunke
> ---
> src/glsl/builtin_functions.cpp | 35
On 09/27/2013 06:24 PM, Emil Velikov wrote:
> On 28/09/13 00:45, Kenneth Graunke wrote:
>> This series combines brw_context.[ch] and intel_context.[ch],
>> and cleans up our context creation code quite a bit. A bunch of
>> functionality was awkwardly split between the two sets of files;
>> now it'
On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
> Now that there isn't an intel_context structure, the split between
> brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary.
> Removing intel_context.[ch] seems desirable, but not everything really
> belongs in brw_context.[ch], eith
On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 10 +++---
> src/mesa/drivers/dri/i965/brw_device_info.c | 9 -
> src/mesa/drivers/dri/i965/brw_device_info.h | 16
> 3 files changed
On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
> It actually just wants generation checking, and brw->gen is the usual
> way of doing that. In the future, we'll also want to check brw->hw_ctx,
> which isn't available from the screen.
>
> While we're changing the function signature, convert from s
On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
> This was always set to false, and is only used for debugging.
> To enable it, simply change the if (0) block and recompile.
So, the difference is that you could change emit_state_always in GDB,
but I'm not sure that matters.
> Signed-off-by: Kennet
On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
> "error" is a very generic name. dri_ctx_error is the name used in
> intelInitContext(), which is more specific.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 de
On Tue, Oct 1, 2013 at 2:27 AM, Ian Romanick wrote:
> On 09/27/2013 04:46 PM, Kenneth Graunke wrote:
>> This was only used for uploading batchbuffer data, and only on 32-bit
>> systems. If this is actually useful, we might want to use it more
>> widely. But more than likely, it isn't.
>
> This p
On 09/30/2013 03:08 AM, Chris Forbes wrote:
> This series adds support for ARB_texture_gather in core mesa and in i965 for
> Gen7+.
> Notable changes from V3:
>
> - Only emit extra surface state, recompiles, etc if the shader actually uses
> gather4.
> - Use SCS to accomplish the workaround on H
After the last patch, we can replace the region allocated in the miptree
creation with a more straightforward (and hopefully smaller resulting)
buffer based on the bspec's allocation formula.
Since I am relatively new to this part of the bspec, I would very much
appreciate scrutiny during review o
On 09/27/2013 04:45 PM, Kenneth Graunke wrote:
> This series combines brw_context.[ch] and intel_context.[ch],
> and cleans up our context creation code quite a bit. A bunch of
> functionality was awkwardly split between the two sets of files;
> now it's all in one place.
>
> While this series is
On 09/27/2013 04:46 PM, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 95 +++-
> src/mesa/drivers/dri/i965/intel_context.h | 142
> --
> 2 files changed, 93 insertions(+), 144 deletions(-)
On 09/27/2013 04:46 PM, Kenneth Graunke wrote:
> This was only used for uploading batchbuffer data, and only on 32-bit
> systems. If this is actually useful, we might want to use it more
> widely. But more than likely, it isn't.
This probably is still useful, alas. The glibc memcpy wants to do
Eric Anholt writes:
> Could you print which thing is trying to get resolved early? I see a
> few egl* calls within main/egl*.c (eglQueryAPI(), eglGetDisplay(),
> eglWaitClient()), and I'm wondering if not having Bsymbolic on them is
> causing an RTLD_NOW (perhaps by the glaze-find-libgl.c?) to tr
On 09/27/2013 09:42 PM, Paul Berry wrote:
In commit 247f90c77e8f3894e963d796628246ba0bde27b5 (i965/gs: Set
control data header size/format appropriately for EndPrimitive()), I
incorrectly numbered the DWORDs in the 3DSTATE_GS command starting
from 1 instead of starting from 0. This caused the co
Am 30.09.2013 17:14, schrieb Brian Paul:
> u_rect.h was including u_surface.h just to avoid touching a bunch
> of other source files after some functions were moved from u_rect.h
> to u_surface.h. This patch cleans up that hack.
> ---
> src/gallium/auxiliary/util/u_format.c|2 +-
> sr
---
src/gallium/drivers/r600/r600_llvm.c | 47 +++-
src/gallium/drivers/r600/r600_shader.c | 1 +
src/gallium/drivers/radeon/radeon_llvm.h | 1 +
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/d
---
src/gallium/drivers/r600/r600_llvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 54291a1..c700f26 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llv
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 8ff9abd..ac2e511 100644
--- a/src/gallium/drivers/radeon/ra
---
src/gallium/drivers/r600/r600_llvm.c | 7 +--
src/gallium/drivers/r600/r600_shader.c | 1 +
src/gallium/drivers/radeon/radeon_llvm.h | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
inde
---
lib/Target/R600/R600ISelLowering.cpp | 6 +-
lib/Target/R600/R600Instructions.td | 4
lib/Target/R600/R600Intrinsics.td| 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index 126db73.
This required some reordering of headers to ensure that the symbol name
redefines happened before any prototypes.
---
configure.ac | 2 +-
src/mesa/drivers/dri/Makefile.am | 4 +
src/mesa/drivers/dri/r200/Makefile.am | 18 +---
i915 has symbols for formerly-shared code that conflict with i965, so we
define them away using gen-symbol-redefs.py. Options considered:
- This option. Downsides: The symbols in profiling and debugging don't
match the source. The symbol list may change in the future and we won't
notice wit
---
configure.ac | 2 +-
src/mesa/drivers/dri/Makefile.am | 2 ++
src/mesa/drivers/dri/nouveau/Makefile.am | 23 ++-
src/mesa/drivers/dri/nouveau/nouveau_screen.c | 15 +--
src/mesa/drivers/dri/nouveau/nouveau_scr
As we move to megadrivers, we are unable to build multiple drivers with
the same public global symbol per driver (Think an X Server with an intel
and a nouveau driver, and the X Server implementing indirect for both --
we have to actually talk to the right driver). By slipping the
driDriverAPI vta
---
src/mesa/drivers/dri/gen-symbol-redefs.py | 68 +++
1 file changed, 68 insertions(+)
create mode 100755 src/mesa/drivers/dri/gen-symbol-redefs.py
diff --git a/src/mesa/drivers/dri/gen-symbol-redefs.py
b/src/mesa/drivers/dri/gen-symbol-redefs.py
new file mode 1007
This will allow a megadrivers build to reference the actual driver being
loaded from the shared dri_util screen creation code.
---
include/GL/internal/dri_interface.h| 27 +++--
src/egl/drivers/dri2/egl_dri2.c| 27 +
src/egl/drivers/dri2/egl_dri2.h
Previously, we've split things such that mesa core is in libdricore,
exposing the whole Mesa core interface in the global namespace, and the
i965_dri.so code all links against that. Along with polluting application
namespace terribly, it requires extra PLT indirections and prevents LTO.
Instead,
No driver uses it any more, and it's been replaced by megadrivers.
---
configure.ac | 11 -
src/mesa/Makefile.am | 6 +--
src/mesa/drivers/dri/Makefile.am | 2 +-
src/mesa/drivers/dri/i965/Makefile.am | 2 +-
src/mesa/libdricore/Makefile.am
---
configure.ac | 26 +++---
src/mesa/drivers/dri/Makefile.am | 2 ++
src/mesa/drivers/dri/swrast/Makefile.am | 18 +++---
src/mesa/drivers/dri/swrast/Makefile.sources | 6 --
src/mesa/drivers/dri/swrast/swrast
---
src/egl/drivers/dri2/egl_dri2.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 04ab564..7c07fd6 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
This way they aren't all sitting in the global namespace (with the same
name per driver).
---
src/gallium/state_trackers/dri/common/dri_screen.c | 10 +++---
src/gallium/state_trackers/dri/common/dri_screen.h | 2 ++
src/gallium/state_trackers/dri/drm/dri2.c | 1 +
src/gallium/state
The previous interface relied on a static struct, which meant tha the
driver didn't get a chance to edit the struct before the struct got used.
For megadrivers, I want to return a variable struct based on what driver
is getting loaded.
---
include/GL/internal/dri_interface.h | 13 +
sr
Turns out already we have this nice mechanism for providing optional
things from the driver to the loader, and I was going to have to rename
the public global symbol to avoid conflicts when doing megadrivers.
While the former __driConfigOptions is technically loader interface, this
is the only loa
Here are the megadrivers changes, after the prep series I posted earlier.
A few tiny updates to the prep series are available in my tree as
"megadriver-prep" and this series is available as "megadrivers-5"
FPS improvement on GLB2.7 with INTEL_NO_HW=1: 2.61061% +/- 1.16957% (n=50)
One question I h
I'm planning on doing driver extension parsing from 3 places, and making
the extension loading step a bit longer.
---
src/glx/dri2_glx.c | 6 ++
src/glx/dri_common.c | 14 ++
src/glx/dri_common.h | 2 ++
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/src/glx/dr
After the last patch, we can replace the region allocated in the miptree
creation with a more straightforward (and hopefully smaller resulting)
buffer based on the bspec's allocation formula.
Since I am relatively new to this part of the bspec, I would very much
appreciate scrutiny during review o
Starting with Ivybridge, the hierarchical had relaxed requirements for
its allocation. Following a "simple" formula in the bspec was all you
needed to satisfy the requirement.
To prepare the code for this, extract all places where the miptree was
used, when we really only needed the region. This a
On 09/30/2013 11:03 AM, Ian Romanick wrote:
> On 09/30/2013 03:08 AM, Chris Forbes wrote:
>> From: Maxence Le Dore
>>
>> V2 [Chris Forbes]:
>>- Add new pattern, fixup parameter reading.
>>
>> V3: Rebase onto new builtins machinery
>>
>> Reviewed-by: Kenneth Graunke
>> ---
>> src/glsl/builtin
Paul Berry writes:
> On 15 September 2013 00:10, Francisco Jerez wrote:
>
>> Analogous to the GLSL IR predicate with the same name. This patch
>> fixes the three dead code elimination passes and the VEC4/FS
>> instruction scheduling passes so they leave instructions with side
>> effects alone.
Paul Berry writes:
> On 15 September 2013 00:19, Francisco Jerez wrote:
>
>>[...]
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> index 762832a..412d27a 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> +++ b/src/mes
On 09/30/2013 03:08 AM, Chris Forbes wrote:
> From: Maxence Le Dore
>
> V2 [Chris Forbes]:
>- Add new pattern, fixup parameter reading.
>
> V3: Rebase onto new builtins machinery
>
> Reviewed-by: Kenneth Graunke
> ---
> src/glsl/builtin_functions.cpp | 35
https://bugs.freedesktop.org/show_bug.cgi?id=69874
--- Comment #5 from Emil Velikov ---
(In reply to comment #3)
> Yeah. And subdir-objects is broken for the way we have our build set up at
> the moment (libdricore built from a separate directory, on the same .c files
> as core). Once we megadr
On 09/28/2013 12:38 AM, Eric Anholt wrote:
Carl Worth writes:
For some reason that I don't yet fully understand, Glaze does not work with
libEGL unless libEGL is linked with -Bsymbolic.[*]
Beyond that specific reason, all of the reasons for which libGL.so is linked
with -Bsymbolic, (see the c
On 09/30/2013 12:48 AM, Chris Forbes wrote:
We have the destination framebuffer object passed in; there's no need to
go digging around in the context.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Strictly speaking xmlpool does not require drm, although it's main
(and upto recently only user HW drivers) did. With the dri patch(es)
swrast now require xmlpool, thus changing that to dri seems like the
only sane option.
In other words without this patch and with HW drivers disabled,
swrast will
On 30/09/13 17:06, Eric Anholt wrote:
> Emil Velikov writes:
>
>> On 28/09/13 01:41, Eric Anholt wrote:
>>> Emil Velikov writes:
>>>
* clone the drienv to driswenv and adjust approapriately
* export driswenv and use it in dri-swrast
* ensure __NOT_HAVE_DRM_H is defined for drisw,
I don't understand all the details, but I did confirm
that it pacified the simulator.
Acked-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Emil Velikov writes:
> On 28/09/13 01:41, Eric Anholt wrote:
>> Emil Velikov writes:
>>
>>> * clone the drienv to driswenv and adjust approapriately
>>> * export driswenv and use it in dri-swrast
>>> * ensure __NOT_HAVE_DRM_H is defined for drisw, similar
>>> to all other common_drisw users
>>
Vinson Lee writes:
> Fixes "Resource leak" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
Reviewed-by: Eric Anholt
pgpsVboHuAB85.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freede
Paul Berry writes:
> From the bspec documentation of the SEND instruction:
>
> "destination region cannot cross the 256-bit register boundary."
>
> To avoid violating this restriction when executing SIMD16 texturing
> operations (such as those used by blorp), we need to ensure that the
> dest
From: Roland Scheidegger
There's two reasons for this:
1) even when ignoring rho approximation for cube maps, the result is still
not correct, but it's better as the max error at edges is now sqrt(2) instead
of 2 (which was a full mip level), same as it is for ordinary 2d maps when
doing rho appr
On 09/29/2013 05:18 PM, Dave Airlie wrote:
> Hey,
>
> So for virgl I was praying I could avoid having to keep a GL context
> on the host per guest context but it appears to do
> NV_conditional_render properly I either need the ability to
> suspend/resume queries (maybe I could write an extension)
u_rect.h was including u_surface.h just to avoid touching a bunch
of other source files after some functions were moved from u_rect.h
to u_surface.h. This patch cleans up that hack.
---
src/gallium/auxiliary/util/u_format.c|2 +-
src/gallium/auxiliary/util/u_rect.h |6 ---
On Sat, Sep 28, 2013 at 03:01:15PM +0100, Emil Velikov wrote:
> On 28/09/13 04:48, Tom Stellard wrote:
> > On Sun, Sep 22, 2013 at 09:29:28PM +0100, Emil Velikov wrote:
> >> Signed-off-by: Emil Velikov
> >
> > As long as you have build tested these with both automake and scons and
> > are prepare
On 09/28/2013 08:46 AM, Emil Velikov wrote:
Already available and used in other places of configure.ac.
Signed-off-by: Emil Velikov
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1f0a646..1dd0087 100644
--- a/configu
On 09/28/2013 08:46 AM, Emil Velikov wrote:
Commit a9f8baf00b264 removed the first and only use of the variables
but forgot to remove them.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xorg/xorg_xv.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/state_track
On 09/28/2013 08:46 AM, Emil Velikov wrote:
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xorg/xorg_driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c
b/src/gallium/state_trackers/xorg/xorg_driver.c
index dd243bc..097
On 09/28/2013 08:46 AM, Emil Velikov wrote:
v2: Remove xf86PciInfo.h, all drivers provide their own PCI ID list
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xorg/xorg_driver.c | 1 -
src/gallium/state_trackers/xorg/xorg_output.c | 7 ---
2 files changed, 8 deletions(-)
di
On 09/27/2013 10:30 PM, Vinson Lee wrote:
shader has already been dereferenced earlier so cannot be null here.
Fixes "Dereference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/llvmpipe/lp_state_fs.c | 2 +-
1 file changed, 1 insertion(+),
On 09/27/2013 11:52 PM, Vinson Lee wrote:
The block size for all formats is currently at least 1 byte. Add an
assertion for this.
This should silence several Coverity "Division or modulo by zero"
defects.
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/util/u_format.h | 7 ++-
1 fil
On 09/27/2013 10:51 PM, Vinson Lee wrote:
There is an earlier null check for draw so draw could be null here as
well.
Fixes "Dereference after null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/draw/draw_pipe_unfilled.c | 2 +-
1 file changed, 1 ins
I re-ran piglit with my resource streamer v2 implementation + this patch and
actually this fixed sporadic lockups that I've been struggling with. As
discussed at F2F with Chad and Paul, we need this for RS. I'll be posting the
RS v2 soon quite soon.
-abdiel
On Friday, September 27, 2013 01:08:
Am 30.09.2013 10:47, schrieb Grigori Goronzy:
On 30.09.2013 10:06, Michel Dänzer wrote:
On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote:
after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN
with
my RV730 (AGP).
Same problem on PALM. Bisection shows that it is caused
On Mon, Sep 30, 2013 at 11:01 AM, Henri Verbeet wrote:
> On 30 September 2013 02:18, Dave Airlie wrote:
>> So this led me to look at the spec and the mesa code, and I noticed it
>> appears at some point maybe around 3.1 that FBOs are no longer
>> considered shared objects at least in core profile
op 11-09-13 21:11, Ian Romanick schreef:
> Just an FYI...
>
> The 9.2 branch is falling a bit behind. I'm going to trickle out
> patches to the stable branch over the next few days / week. My plan is
> to do 9.2.1 during the week of XDC.
>
> If your favorite patch hasn't made it out but is listed
Hi all,
I've been tracking through src/mesa/vbo and tracking down the dispatch stuff
in relation to the stuff in src/mesa/vbo. I see how the function entries in
vbo_context#exec and vbo_context#save are filled (by essentially macros defined
in of src/mesa/vbo/vbo_attrib_tmp.h interacting with
Hi, I have committed a simpler fix as 7b25f52a95fe13bfc86c4d421328f6df7690876c .
Marek
On Mon, Sep 30, 2013 at 10:53 AM, Grigori Goronzy wrote:
> UVD was checked before the info fields were initialized. Introduced
> by commit 68f6dec32.
> ---
> src/gallium/drivers/r600/r600_pipe.c | 13 +++-
https://bugs.freedesktop.org/show_bug.cgi?id=55951
Tim Allen changed:
What|Removed |Added
CC||screwt...@froup.com
--
You are receiving th
It will indeed select RGBA32F if you supply GL_RGBA and GL_FLOAT, etc.
Marek
On Mon, Sep 30, 2013 at 9:36 AM, Rogovin, Kevin wrote:
> Hi,
>
>> No, I said it would be better to use st_choose_matching_format in
>> st_ChooseTextureFormat,
>> because st_choose_matching_format does exactly what you'
The new surface channel select bits allow us to avoid having to
recompile the shader for this workaround.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_wm.c| 5 +++--
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 14 --
2 files changed, 11 inser
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/intel_extensions.c | 4
2 files changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 5f58a29..0d677aa 10064
This allows us to use a different surface format for gather4, which is
required for R32G32_FLOAT to work on Gen7.
V4: - Only emit alternate surface state for shaders which will actually
use it.
- Pass a simple 'for_gather' flag rather than a function pointer.
The callee can decide
Worst-case is that *every* texunit uses a format that needs overriding.
V4: Place the gather slots last, so shaders which don't use gather don't
get penalized by having a huge binding table.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_context.h | 20 ++--
1
gather4 GREEN channel against a surface with format R32G32_FLOAT doesn't work
correctly on IVB. w/a from bspec:
- use R32G32_FLOAT_LD = 0x97 instead, for gather4 only.
- select BLUE channel to read GREEN
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
V4: Only flag quirks if there are any uses of gather in the shader,
to avoid spurious recompiles just because someone happened to use
RG32F.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4
src/mesa/drivers/dri/i965/brw_program.h| 5 +
---
src/glsl/ir_set_program_inouts.cpp | 9 +
src/mesa/main/mtypes.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/src/glsl/ir_set_program_inouts.cpp
b/src/glsl/ir_set_program_inouts.cpp
index 1267d6d..ab23538 100644
--- a/src/glsl/ir_set_program_inouts.cpp
+++ b/src
Pretty much the same as the FS case. Channel select goes in the header,
V2: Less mangling.
V3: Avoid sampling at all, for degenerate swizzles.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vec4.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 46 +
Lowers ir_tg4 (from textureGather and textureGatherOffset builtins) to
SHADER_OPCODE_TG4.
The usual post-sampling swizzle workaround can't work for ir_tg4,
so avoid doing that:
* For R/G/B/A swizzles use the hardware channel select (lives in the
same dword in the header as the texel offset), a
Adds the Gen7 message IDs, a new SHADER_OPCODE_TG4 pseudo-op, and
low-level support for emitting it via generate_tex().
V3: Updated for changes in master.
Signed-off-by: Chris Forbes
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h | 3 +++
src/mesa/drivers/dri
From: Maxence Le Dore
V2 [Chris Forbes]:
- Add new pattern, fixup parameter reading.
V3: Rebase onto new builtins machinery
Reviewed-by: Kenneth Graunke
---
src/glsl/builtin_functions.cpp | 35 +++
src/glsl/glcpp/glcpp-parse.y| 3 +++
src/glsl/
1 - 100 of 117 matches
Mail list logo
