https://bugs.freedesktop.org/show_bug.cgi?id=67672
Vladimír Čunát vcu...@gmail.com changed:
What|Removed |Added
CC||vcu...@gmail.com
---
On 11/06/2013 12:55 PM, Paul Berry wrote:
[snip]
Ok, I think you are correct about the functions. But I believe for
variables, the ir_variable always appears in the IR before any
references to it. Can someone confirm this? (Ken or Ian perhaps?)
That's correct, and actually critical. Driver
On Tue, Nov 5, 2013 at 8:55 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 05/11/13 18:18, Chad Versace wrote:
On 11/02/2013 12:00 PM, Emil Velikov wrote:
Rip out the source file list from mesa/Makefile.sources, to a
more sensible location/file.
* Split PROGRAM_FILES and GENERATED_FILES.
Ever since this had appeared as part of GL4.4 I'd been curious
about whether this extension was going to Just Work, or be a
workaround-party like ARB_vertex_type_2_10_10_10_rev.
Today my curiousity got the better of me, and it turns out it
just works.
Tested and enabled on Gen6+ -- theoretically
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/varray.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index dee476a..5af4c8c 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 48c4e9f..3da1c42 100644
--- a/src/mesa/main/extensions.c
+++
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/glformats.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index dfee6f1..740faa8 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -345,6 +345,11
This theoretically works on earlier hardware as well, but the extension
requires at least GL3.0.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
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
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7d100df..93bd09e 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -175,7 +175,7 @@ GL_ARB_multi_bind
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/vbo/vbo_attrib_tmp.h | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h
index bbc0205..358d12d 100644
---
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 4da1b7e..e2002e8 100644
---
Am Mittwoch, den 06.11.2013, 21:52 -0800 schrieb Matt Turner:
---
Deleted files diff removed.
I think there was some nice stuff in here that didn't make it into XA,
but that's no valid reason to keep st/xorg alive in the tree.
If someone is interested in porting things to XA, it's just some
https://bugs.freedesktop.org/show_bug.cgi?id=67672
--- Comment #17 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #15)
I can reproduce the problem on my machine.
I'm using the tarball at
ftp://ftp.freedesktop.org/pub/mesa/${version}/MesaLib-${version}.tar.bz2 ,
where
On 11/06/2013 04:59 PM, burlen wrote:
On 11/06/2013 12:58 PM, Brian Paul wrote:
On 11/06/2013 12:34 PM, burlen wrote:
When I build osmesa with --with-osmesa-bits=32 I notice that I get 31
bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31.
What's the story with the number
On 11/07/2013 12:06 AM, Chris Forbes wrote:
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/bufferobj.c| 14 ++
src/mesa/main/get.c | 4
On 11/07/2013 12:06 AM, Chris Forbes wrote:
V2: Check for mapping failure (thanks Brian)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/vbo/vbo_primitive_restart.c | 33 +
1 file changed, 33 insertions(+)
diff --git
On 11/07/2013 06:42 AM, Brian Paul wrote:
On 11/06/2013 04:59 PM, burlen wrote:
On 11/06/2013 12:58 PM, Brian Paul wrote:
On 11/06/2013 12:34 PM, burlen wrote:
When I build osmesa with --with-osmesa-bits=32 I notice that I get 31
bits by way of the compile line define
On 11/07/2013 09:09 AM, burlen wrote:
On 11/07/2013 06:42 AM, Brian Paul wrote:
On 11/06/2013 04:59 PM, burlen wrote:
On 11/06/2013 12:58 PM, Brian Paul wrote:
On 11/06/2013 12:34 PM, burlen wrote:
When I build osmesa with --with-osmesa-bits=32 I notice that I get 31
bits by way of the
We must send to the compositor buffer it is able to read.
Since tiling modes are different on graphic cards, we have
to disable tiling when creating the buffers if we render
with a different graphic card than the compositor.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
From: Cyril Brulebois k...@debian.org
Thanks to Pino Toscano.
Patch from Debian package.
---
src/gallium/auxiliary/os/os_thread.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/os/os_thread.h
b/src/gallium/auxiliary/os/os_thread.h
index
These patches enable using DRI_PRIME to use a different card
than the compositor card (with render-nodes).
At the time of writing, Mesa Wayland egl backend doesn't
support render-nodes, because it uses the dri2 backend, which
require using GEM names (render-nodes aren't allowed to use GEM
names).
This patch moves the code to open the graphic device in the Wayland backend,
removes the authentication request when we are on a render-node,
and has a few fixes.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/egl/drivers/dri2/egl_dri2.h | 1 +
src/egl/drivers/dri2/platform_wayland.c
two formats are supported: DRI_PRIME=1 will tell Mesa
to choose an other card than the compositor card if possible,
while setting DRI_PRIME to the id_path_tag of a device (like
pci-_02_00_0) tells Mesa to take the device with this
id_path_tag.
If it isn't able to find the desired card ( no
On 11/07/2013 08:14 AM, Brian Paul wrote:
On 11/07/2013 09:09 AM, burlen wrote:
On 11/07/2013 06:42 AM, Brian Paul wrote:
On 11/06/2013 04:59 PM, burlen wrote:
On 11/06/2013 12:58 PM, Brian Paul wrote:
On 11/06/2013 12:34 PM, burlen wrote:
When I build osmesa with --with-osmesa-bits=32 I
Matt Turner matts...@gmail.com writes:
We do support out of tree builds now.
This series is:
Reviewed-by: Eric Anholt e...@anholt.net
pgpi1Kk4N3O2m.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Hi;
On 11/06/2013 07:35 PM, Erik Faye-Lund wrote:
Sorry for the late reply.
On Fri, Nov 1, 2013 at 4:14 PM, Tapani tapani.pa...@intel.com wrote:
On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
That won't help for programs that maintain their own (explicit)
shader-cache, which was the
Courtney Goeltzenleuchter court...@lunarg.com writes:
What's the process of contributing a test to the Mesa demos repository?
Tests should be made automated and put in piglit, instead of in the Mesa
demos repository.
pgpt0EWtwH3M0.pgp
Description: PGP signature
Chris Forbes chr...@ijw.co.nz writes:
V2: Check for mapping failure (thanks Brian)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/vbo/vbo_primitive_restart.c | 33 +
1 file changed, 33 insertions(+)
diff --git
On Thu, Nov 7, 2013 at 9:01 AM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
What's the process of contributing a test to the Mesa demos repository?
Send patches to this list with a [PATCH demos] prefix.
___
mesa-dev mailing list
Chris Forbes chr...@ijw.co.nz writes:
Ever since this had appeared as part of GL4.4 I'd been curious
about whether this extension was going to Just Work, or be a
workaround-party like ARB_vertex_type_2_10_10_10_rev.
Today my curiousity got the better of me, and it turns out it
just works.
On 7 November 2013 09:20, Eric Anholt e...@anholt.net wrote:
Courtney Goeltzenleuchter court...@lunarg.com writes:
What's the process of contributing a test to the Mesa demos repository?
Tests should be made automated and put in piglit, instead of in the Mesa
demos repository.
Also
Brian Paul bri...@vmware.com writes:
On 11/07/2013 12:06 AM, Chris Forbes wrote:
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/bufferobj.c| 14 ++
src/mesa/main/get.c
On 11/07/2013 10:23 AM, Eric Anholt wrote:
Chris Forbes chr...@ijw.co.nz writes:
V2: Check for mapping failure (thanks Brian)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/vbo/vbo_primitive_restart.c | 33 +
1 file changed, 33 insertions(+)
diff
Hi Eric,
Include performance tests?
In my quick look I didn't see anything that looked appropriate to
performance regression testing. The Perf folder under Mesa demos seemed the
closest that I could find.
Thanks,
Courtney
On Thu, Nov 7, 2013 at 10:20 AM, Eric Anholt e...@anholt.net wrote:
Chris Forbes chr...@ijw.co.nz writes:
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/api_validate.c | 163
+++
src/mesa/main/api_validate.h | 26 +++
2
On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/api_validate.c | 163
+++
Chris Forbes chr...@ijw.co.nz writes:
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_context.h | 10 +
src/mesa/drivers/dri/i965/brw_draw_upload.c | 32
src/mesa/drivers/dri/i965/brw_state.h| 1 +
Brian Paul bri...@vmware.com writes:
On 11/07/2013 10:23 AM, Eric Anholt wrote:
Chris Forbes chr...@ijw.co.nz writes:
V2: Check for mapping failure (thanks Brian)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/vbo/vbo_primitive_restart.c | 33
Oops -- had pushed tests to my piglit branch but not sent them to the list.
On Fri, Nov 8, 2013 at 6:25 AM, Eric Anholt e...@anholt.net wrote:
Chris Forbes chr...@ijw.co.nz writes:
Ever since this had appeared as part of GL4.4 I'd been curious
about whether this extension was going to Just
OK -- that's much simpler, thanks.
On Fri, Nov 8, 2013 at 7:11 AM, Eric Anholt e...@anholt.net wrote:
Chris Forbes chr...@ijw.co.nz writes:
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_context.h | 10 +
On 11/07/2013 10:55 AM, Matt Turner wrote:
Improves performance of RoboHornet's 2D Canvas toDataURL benchmark
[http://www.robohornet.org/#e=canvastodataurl] by approximately 5x
on Baytrail on ChromiumOS.
---
v2: Added benchmark results
Remove unnecessary _mesa_align_free in error case
These were entirely interactive. Adding ability to pass in
command line arguments allows future tests to include
automated test capabilities.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/perf/copytex.c | 2 +-
src/perf/drawoverhead.c | 2 +-
This patch series adds a new benchmark test designed to
measure texture upload speed with configurable parameters.
Can run interactively, similar to teximage test or can use
command line arguments to specify size of texture, mipmap or not,
source pixel format and internal pixel format.
The first
texture_enh allows the user to specify source, internal formats
and mipmap or not. This provides a quick way to get feedback
on texture upload related performance tuning.
Texture image data is initialized and aligned to 64 byte bounary.
Uses Mesa demos Perf library to do the measurements.
Needed test to measure texture upload speed under a variety
of modes (mipmap, source format, internal format, size, etc.)
This new test has an interactive run mode like the other Mesa
Perf tests but also includes command line options to make
it automatable.
Fix up code formatting.
Signed-off-by:
On 10/11/2013 03:10 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
The enumerated values are currently allocated from Intel's range.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
docs/MESA_query_renderer.spec | 381
MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 ++-
1 file changed, 2 insertions(+), 1
Support all levels of a supported texture format.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is
On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The enumerated values are currently allocated from Intel's range.
Some highlevel comments below,
+GLX renderer attribute number description
+
On 10/11/2013 03:10 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/intel_screen.c | 81
1 file changed, 81 insertions(+)
diff --git
I saw the perf demo patches and expected to see results from them in
this patch. Any results to share?
On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
Support all levels of a supported texture format.
Signed-off-by: Courtney Goeltzenleuchter
On Thu, Nov 7, 2013 at 1:28 PM, Matt Turner matts...@gmail.com wrote:
I saw the perf demo patches and expected to see results from them in
this patch. Any results to share?
Oh, I see they're in the cover letter. They should really be in the
commit messages, for a variety of reasons.
Hi Matt,
I posted results in my cover letter email: [PATCH 0/2v2] i965: Extend fast
texture upload
Please let me know if you want more details.
Courtney
On Thu, Nov 7, 2013 at 2:28 PM, Matt Turner matts...@gmail.com wrote:
I saw the perf demo patches and expected to see results from them in
On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
+ /* Once a batch uses more than 75% of the maximum mappable size, we
+ * assume that there's some fragmentation, and we start doing extra
+ * flushing, etc. That's the big cliff apps will care about.
On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
I'd like to hear Eric's opinion on patch 8's memory limit.
I sent comments on patches 6, 8, 10, and 15.
With those fixes, patches 1-11 and 13-15 would get:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
I don't plan to review patches 12 or 16-18 (unit tests).
https://bugs.freedesktop.org/show_bug.cgi?id=71359
Priority: medium
Bug ID: 71359
Keywords: regression
CC: chr...@ijw.co.nz, e...@anholt.net
Assignee: mesa-dev@lists.freedesktop.org
Summary: varray.c:324:7: error: non-void
---
src/glsl/opt_algebraic.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index ea3c386..448f27e 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -377,7 +377,6 @@
---
src/glsl/opt_algebraic.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 3da27e5..ea3c386 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -357,7 +357,6 @@
I want to reuse them in opt_algebraic.
---
src/glsl/Makefile.sources | 1 +
src/glsl/ir.h | 22 ++
src/glsl/ir_equals.cpp| 196 ++
src/glsl/opt_cse.cpp | 178 +
4 files changed, 220
total instructions in shared programs: 1732385 - 1732373 (-0.00%)
instructions in affected programs: 416 - 404 (-2.88%)
GAINED:0
LOST: 0
(That's 4 already-short fragment shaders in dota2)
---
src/glsl/opt_algebraic.cpp | 4 +++-
The comment was stale, because the lowering in question wasn't happening
in lower_instructions.cpp. Presumably if the lowering ever moves there,
we can plumb the lowering mask through to opt_algebraic.
total instructions in shared programs: 1618696 - 1616810 (-0.12%)
instructions in affected
MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full
Support all levels of a supported texture format.
Using 1024x1024, RGBA source, mipmap
THIS PATCH
internal-format Before (MB/sec) XRGB (MB/sec) mipmap (MB/sec)
GL_RGBA 628.15 627.15 615.90
GL_RGB
Re-posted patches with updated commit messages.
Thanks,
Courtney
On Thu, Nov 7, 2013 at 2:34 PM, Matt Turner matts...@gmail.com wrote:
On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
This series builds on work from Frank Henigman to optimize the
Does this affect anything in shader-db?
On Fri, Nov 8, 2013 at 10:58 AM, Eric Anholt e...@anholt.net wrote:
---
src/glsl/opt_algebraic.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 3da27e5..ea3c386
https://bugs.freedesktop.org/show_bug.cgi?id=71359
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Previously, we only exposed them in desktop GL or with:
#extension GL_OES_standard_derivatives : enable
GLSL ES 3.00 includes these without an extension, so we need to expose
them by default.
Note that the above #extension line results in an error or desktop GL,
so we don't need to worry
two formats are supported: DRI_PRIME=1 will tell Mesa
to choose an other card than the compositor card if possible,
while setting DRI_PRIME to the id_path_tag of a device (like
pci-_02_00_0) tells Mesa to take the device with this
id_path_tag.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
I forgot to test the capabilities to know if we can use render-nodes.
Being able to do that was the goal of patch 1.
I send a better patch 3.
Axel Davy (1):
Implement choosing the device to use with DRI_PRIME
src/egl/drivers/dri2/platform_wayland.c | 180 ++--
1
On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_draw.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
The current plan I think is just to drop the extra state in brw, and
just reference the indirect bo directly when we need it [see Eric's
comment on 09/15]
On Fri, Nov 8, 2013 at 11:41 AM, Paul Berry stereotype...@gmail.com wrote:
On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:
On 7 November 2013 14:46, Chris Forbes chr...@ijw.co.nz wrote:
The current plan I think is just to drop the extra state in brw, and
just reference the indirect bo directly when we need it [see Eric's
comment on 09/15]
Ah, ok, that makes sense. Thanks.
On Fri, Nov 8, 2013 at 11:41 AM,
On Thu, Nov 7, 2013 at 1:22 PM, Dave Airlie airl...@gmail.com wrote:
On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The enumerated values are currently allocated from Intel's range.
Some highlevel comments below,
On Thu, Nov 7, 2013 at 2:39 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Previously, we only exposed them in desktop GL or with:
#extension GL_OES_standard_derivatives : enable
GLSL ES 3.00 includes these without an extension, so we need to expose
them by default.
Note that the
https://bugs.freedesktop.org/show_bug.cgi?id=71363
--- Comment #1 from burlen burlen.lor...@gmail.com ---
Created attachment 88860
-- https://bugs.freedesktop.org/attachment.cgi?id=88860action=edit
correct baseline image
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=71363
Priority: medium
Bug ID: 71363
Assignee: mesa-dev@lists.freedesktop.org
Summary: line rendering with --with-osmesa-bits=32
Severity: normal
Classification: Unclassified
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=71363
burlen burlen.lor...@gmail.com changed:
What|Removed |Added
Attachment #88859|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=71363
--- Comment #3 from burlen burlen.lor...@gmail.com ---
Created attachment 88862
-- https://bugs.freedesktop.org/attachment.cgi?id=88862action=edit
diff
--
You are receiving this mail because:
You are the assignee for the bug.
Chris Forbes chr...@ijw.co.nz writes:
Does this affect anything in shader-db?
Nope, the shader-db-affecting patches had it cited.
pgpOd0euvJ9qG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 11/07/2013 08:45 AM, burlen wrote:
On 11/07/2013 08:14 AM, Brian Paul wrote:
On 11/07/2013 09:09 AM, burlen wrote:
On 11/07/2013 06:42 AM, Brian Paul wrote:
On 11/06/2013 04:59 PM, burlen wrote:
On 11/06/2013 12:58 PM, Brian Paul wrote:
On 11/06/2013 12:34 PM, burlen wrote:
When I build
radeon_llvm_compile allocates memory for binary.code, binary.config, or neither
depending on
what's being done.
We need to make sure to free that memory after it's no longer needed.
---
src/gallium/drivers/r600/r600_llvm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
use memset to initialize to 0's... otherwise code_size and config_size could be
uninitialized when read later in this method. It's also hard to do NULL checks
on uninitialized pointers.
---
src/gallium/drivers/r600/r600_llvm.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Prevents a memory leak.
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index d2e5642..e35c212 100644
---
With the 3 attached patches and my previous series of 6 from yesterday, I can
now launch glxgears on Evergreen without any definite memory leaks according
to: valgrind --leak-check=full glxgears
I've run this through piglit/tests/quick.tests without any regressions.
I don't have commit access,
On 11/07/2013 01:33 PM, Daniel Vetter wrote:
On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
+ /* Once a batch uses more than 75% of the maximum mappable size, we
+ * assume that there's some fragmentation, and we start doing extra
+ * flushing, etc.
On 11/07/2013 01:22 PM, Dave Airlie wrote:
On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The enumerated values are currently allocated from Intel's range.
Some highlevel comments below,
+GLX renderer attribute
Commit b16b3c87 began performing CSE on CMP instructions with null
destinations. I relaxed the restrictions a bit too much, thereby
allowing CSE to be performed on instructions with, for instance, an
explicit accumulator destination.
This broke the arb_gpu_shader5/fs-imulExtended shader tests
Only loop over the actual number of color buffers supported, not
PIPE_MAX_COLOR_BUFS.
---
src/gallium/drivers/svga/svga_context.c |3 ++-
src/gallium/drivers/svga/svga_pipe_misc.c |5 +++--
src/gallium/drivers/svga/svga_screen.c| 10 ++
Grab the comments from commit message b84b7f19dfdc0 to explain
what the code is doing.
---
src/gallium/drivers/svga/svga_state_framebuffer.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_state_framebuffer.c
This helps fix an issue in the svga driver, and is just safer all-around.
---
src/gallium/auxiliary/util/u_framebuffer.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_framebuffer.c
b/src/gallium/auxiliary/util/u_framebuffer.c
index
On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:
texture_enh allows the user to specify source, internal formats
and mipmap or not. This provides a quick way to get feedback
on texture upload related performance tuning.
Texture image data is initialized and aligned to 64 byte bounary.
On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:
These were entirely interactive. Adding ability to pass in
command line arguments allows future tests to include
automated test capabilities.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/perf/copytex.c |
On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:
Needed test to measure texture upload speed under a variety
of modes (mipmap, source format, internal format, size, etc.)
This new test has an interactive run mode like the other Mesa
Perf tests but also includes command line options to
X_f, Y_f, Xp_f, Yp_f variables are used just inside
translate_dst_to_src().So, they can be defined just as
local variables.
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
I think I missed this change during the review of my single
sample scaled blit patches.
https://bugs.freedesktop.org/show_bug.cgi?id=71363
--- Comment #4 from Brian Paul bri...@vmware.com ---
I'm guessing it's a fragment Z interpolation issue. Can you provide some info
about:
* does the test use GL_DEPTH_TEST?
* Any calls to glDepthRange()?
* What are the vertex Z values (zeros?)
*
On 10/29/2013 06:07 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Soon some drivers will support a different set of flags than other
drivers. If some flags have to be filtered in the driver, we might as
well filter all of them in the driver.
I'm not sure that I agree,
On 11/05/2013 02:25 PM, Courtney Goeltzenleuchter wrote:
Give glTexStorage* equivalent debug logging to glTexImage*.
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/main/texstorage.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
On 10/29/2013 06:07 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
No drivers advertise the DRI2 extension yet, so no driver should ever
see a value other than false for notify_reset.
The changes in nouveau use tabs because nouveau seems to have it's own
indentation
1 - 100 of 103 matches
Mail list logo
