Am 05.02.2014 00:01, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Better then guessing it.
Yeah we have had this query for a long time...
Sounds reasonable to me.
Both patches are: Reviewed-by: Christian König christian.koe...@amd.com
---
I can confirm this fixes the opencl-example tests and bfgminer now runs
without crashing
Thanks
Mike
On 4 February 2014 03:56, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Fixes opencl-example if_* tests with radeonsi.
Bugzilla:
Am 05.02.2014 08:37, schrieb Michel Dänzer:
On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Better then guessing it.
Yeah we have had this query for a long time...
[...]
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
I know, but do you have a better idea? If the buffer isn't evicted, we
should get the correct placement. The code also respects placement of
Prime buffers, which should be in GTT. This is as close to the ideal
solution as it can possibly be. I don't think it can be any better
with our kernel
On Mit, 2014-02-05 at 10:13 +0100, Christian König wrote:
Am 05.02.2014 08:37, schrieb Michel Dänzer:
On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 2ac060b..7c59f26
Am 05.02.2014 10:57, schrieb Michel Dänzer:
On Mit, 2014-02-05 at 10:13 +0100, Christian König wrote:
Am 05.02.2014 08:37, schrieb Michel Dänzer:
On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
https://bugs.freedesktop.org/show_bug.cgi?id=74563
Priority: medium
Bug ID: 74563
Assignee: mesa-dev@lists.freedesktop.org
Summary: Surfaceless contexts are not properly released by DRI
drivers
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=74563
Alexandros Frantzis alexandros.frant...@canonical.com changed:
What|Removed |Added
Attachment #93443|text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=74563
--- Comment #1 from Alexandros Frantzis alexandros.frant...@canonical.com ---
Created attachment 93444
-- https://bugs.freedesktop.org/attachment.cgi?id=93444action=edit
Potential fix
--
You are receiving this mail because:
You are the
On 12/30/2013 11:44 AM, Petri Latvala wrote:
Fourth version of patch series.
- Fixed vec4_register_coalesce unit test. That test passes NULL for
prog_data, which Mesa proper doesn't do.
- Renamed uniform_param_count to uniform_array_size.
- Used ALIGN() to round up when dividing buffer size
Hi,
Without my patch, mesa fails to compile:
#version 300 es
centroid in mediump vec2 centr;
gives the error message error: no precision specified this scope for type
`vec2'
You are both correct, and I was wrong, making centroid an interpolation
qualifier; the correct solution is to tweak
Hello Marek,
Nice to hear the extension is being tackled! Took me a while to get mesa
building again, and I did a quick test with your patches - unfortunately
they outright crash Dolphin at the moment. I'm not quite sure if you
have sent an updated patch series yet, so I used the one you sent
https://bugs.freedesktop.org/show_bug.cgi?id=74563
Alexandros Frantzis alexandros.frant...@canonical.com changed:
What|Removed |Added
Hardware|x86-64 (AMD64)
---
src/glsl/glsl_parser.yy | 215 +---
1 file changed, 114 insertions(+), 101 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 928c57e..c6a585f 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@
These patches changes the ast_node location holding by adding tokens
end position and assignment of it along with previously tracked start
position. Bison rules was updated to set appropriate tokens locations
instead of yylloc.
Sir Anthony (4):
glsl: Update lexers in glsl and glcpp to hande
After preprocessing by glcpp all adjacent spaces were replaced by
single one and glsl parser received column-shifted shader source.
It negatively affected ast location set up and produced wrong error
messages for heavily-spaced shaders.
---
src/glsl/glcpp/glcpp-lex.l
---
src/glsl/glcpp/glcpp-lex.l | 3 ++-
src/glsl/glsl_lexer.ll | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index c0709a2..188e454 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@
---
src/glsl/ast.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index a9352f9..8e54ddc 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -98,6 +98,20 @@ public:
}
/**
+* Set the source location range of an AST node using two
---
src/glsl/ast.h | 22 +-
src/glsl/glsl_parser_extras.cpp | 6 --
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 2d6f3a2..a9352f9 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -75,10 +75,10
On Tue, Jan 28, 2014 at 2:45 PM, Paul Berry stereotype...@gmail.com wrote:
On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index cb732a5..7075579 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have
been alright if it wasn't for this bit in
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:
2) Can the application still use the buffer using the CPU address?
RESOLVED: YES.
On 4 February 2014 10:03, Jordan Justen jljus...@gmail.com wrote:
What about trying to make use of
MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader?
We could add
extensions.c:bool _mesa_is_extension_override_enabled(char *)
And then
if
On Tue, Jan 28, 2014 at 1:50 PM, Paul Berry stereotype...@gmail.com wrote:
On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:
This patch introduces all the changes to the IR that are necessary for
representing programs in the SSA form. This consists of a new variable
mode,
On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have
been alright if it wasn't for this bit in
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:
2) Can the application still use the buffer using the
https://bugs.freedesktop.org/show_bug.cgi?id=65534
--- Comment #3 from Eric Anholt e...@anholt.net ---
*** Bug 66948 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev
Let's update LP_MAX_TGSI_IMMEDIATES and use it instead of 4096.
Otherwise looks good.
Jose
- Original Message -
We need to handle a lot more immediates and in order to do that
we also switch from allocating this structure on the stack to
allocating it on the heap.
Signed-off-by:
My understanding is that this is like having MAP_UNSYNCHRONIZED on at all
times, even when it isn't mapped, because it is always mapped (into
memory). Is that correct Jose?
Patrick
On Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy g...@chown.ath.cx wrote:
On 05.02.2014 18:08, Jose Fonseca
https://bugs.freedesktop.org/show_bug.cgi?id=65534
Eric Anholt e...@anholt.net changed:
What|Removed |Added
Assignee|i...@freedesktop.org
- Original Message -
On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would
have been alright if it wasn't for this bit in
Yes, precisely.
Jose
- Original Message -
My understanding is that this is like having MAP_UNSYNCHRONIZED on at all
times, even when it isn't mapped, because it is always mapped (into
memory). Is that correct Jose?
Patrick
On Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy
I don't think that will actually work as then the new code will never
get used and we will always have a huge static array.
There doesn't seem to be an explicit limit for immediates we could use -
there's one in patch 3/3 but that's only a ureg limit. Maybe need a new
limit somewhere.
Roland
Am
Sorry just saw your other answers so you can forget this.
Roland
Am 05.02.2014 19:19, schrieb Roland Scheidegger:
I don't think that will actually work as then the new code will never
get used and we will always have a huge static array.
There doesn't seem to be an explicit limit for
- Original Message -
- Original Message -
On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
would
have been alright if it wasn't for this bit in
On Fri, Jan 31, 2014 at 11:55 AM, Paul Berry stereotype...@gmail.comwrote:
On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:
Right now we are being basically as naive as possible, and inserting
more copies than necessary. It is possible to implement a more
sophisticated
However, GL_ARB_buffer_storage (OpenGL 4.4) with GL_MAP_PERSISTENT_BIT
isn't much different. The only difference I see between
ARB_buffer_storage and AMD_pinned_memory is that AMD_pinned_memory
allows mapping CPU memory to the GPU address space permanently, while
ARB_buffer_storage allows mapping
GLX_ARB_create_context allows making a GLX context current with None
drawable and readables, but this was never implemented correctly in GLX.
We would create a __DRIdrawable for the None GLX drawable and pass that
to the DRI driver and that would somehow work. Now it's somehow broken.
The way
Pass pattern as bitmask in a unsigned int instead of as array of floats to the
geometry shader.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/geom-stipple-lines.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git
Please disregard this mail.
Sorry about the noise.
On 2014-02-05 20:50, Fabian Bieler wrote:
Pass pattern as bitmask in a unsigned int instead of as array of floats to the
geometry shader.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/geom-stipple-lines.c | 21
https://bugs.freedesktop.org/show_bug.cgi?id=72895
--- Comment #11 from Benjamin Bellec b.bel...@gmail.com ---
I confirm the bug with mesa master and r600g (AMD CYPRESS).
You can try with this command (on Fedora 19):
/usr/bin/fgfs --fg-root=/usr/share/flightgear
Sir Anthony anth...@adsorbtion.org writes:
Thanks for this patch series. It looks great to me. I sent a separate
email with a small comment about some comments. The only other review
comment I have is:
@@ -2127,7 +2138,7 @@ function_definition:
{
void *ctx = state;
$$ =
Sir Anthony anth...@adsorbtion.org writes:
+ unsigned first_line; /** Line number within the source string. */
+ unsigned first_column;/** Column in the line. */
+ unsigned last_line; /** Line number within the source string. */
+ unsigned last_column;
Sir Anthony anth...@adsorbtion.org writes:
After preprocessing by glcpp all adjacent spaces were replaced by
single one and glsl parser received column-shifted shader source.
It negatively affected ast location set up and produced wrong error
messages for heavily-spaced shaders.
Thanks!
On 02/04/2014 04:26 PM, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
STATIC will be removed in the following commit.
---
src/gallium/docs/source/screen.rst | 18 --
src/gallium/include/pipe/p_defines.h | 13 +++--
2 files changed, 19 insertions(+), 12
Bind the transform feedback buffer before drawing into it und unbind it
afterwards.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index
The hardcoded numbers are a few lines off at the moment.
Keeping track of the numbers through further modifications is inconvenient.
The __LINE__ constant takes care of this automatically.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 10 +++---
1 file
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index adb6c7a..03d5f30 100644
---
The freeglut header only defines the extensions to request an OpenGL core
profile context if freeglut.h (rather than glut.h) is included.
Note that the header is installed to include/GL/freeglut.h on OS X, too.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/util/glut_wrap.h | 4
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 31e9fda..eace71b 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@
This commit prepares the transition from extension to core geometry shaders.
(Core geometry shaders require GLSL version 1.5 or later.)
This includes using generic vertex attributes instead of built-ins.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 58
To get an OpenGL core profile context freeglut 2.6 or later is required.
Note that in spite of it's name HAVE_FREEGLUT is only defined if freeglut 2.6
(released in 2009) or later ist found.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
configure.ac | 6 ++
1 file changed, 6
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/geom-outlining-150.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 3dffa16..2e2a54a 100644
--- a/src/glsl/geom-outlining-150.c
+++
Use a vbo for vertex data instead of client-side arrays.
Also bind a vertex array object.
This is necessary for the switch to a core profile context.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/geom-outlining-150.c | 25 ++---
1 file changed, 18
Hello!
As mesa only supports geometry shaders in core profile contexts this patchset
adjusts the gsraytrace and the geom-outlining-150 demos to use the core
profile.
Fabian
Fabian Bieler (12):
configure.ac: Check for freeglut.
glut_wrapper: Include freeglut.h if available.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 23c0f93..adb6c7a 100644
--- a/src/glsl/gsraytrace.cpp
+++
NV_transform_feedback is not supported by mesa.
Use transform feedback from core OpenGL 3.0.
This necessitates binding the transform feedback varyings before linking the
shader.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/gsraytrace.cpp | 72
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/geom-outlining-150.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 0bc20f0..3dffa16 100644
---
On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul bri...@vmware.com wrote:
On 02/04/2014 04:26 PM, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
STATIC will be removed in the following commit.
---
src/gallium/docs/source/screen.rst | 18 --
Since r600g in master now has GL 3.3 support and it would be really
good if we could provide a consistent 3.3 support level (not looking
at you sandybridge).
So I'd like to request that I can backport the r600g specific patches
to enable geom shaders and hence 3.3. I'll use a single squashed
This regressed when I converted BRW_REGISTER_TYPE_* to be an abstract
type that doesn't match the hardware description. dump_instruction()
was using reg_encoding[] from brw_disasm.c, which no longer matches
(and was incorrect for Gen8+ anyway).
This patch introduces a new function to convert the
On Wed, Feb 5, 2014 at 4:23 PM, Dave Airlie airl...@gmail.com wrote:
Since r600g in master now has GL 3.3 support and it would be really
good if we could provide a consistent 3.3 support level (not looking
at you sandybridge).
So I'd like to request that I can backport the r600g specific
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/i915/i915_screen.c | 5 +
src/gallium/drivers/ilo/ilo_screen.c | 3 +++
src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 ++
On Wednesday 05 February 2014, Marek Olšák wrote:
On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul bri...@vmware.com wrote:
On 02/04/2014 04:26 PM, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
STATIC will be removed in the following commit.
---
From: Marek Olšák marek.ol...@amd.com
OpenGL allows a buffer to be mapped only once, but we also map buffers
internally, e.g. in the software primitive restart fallback, for PBOs,
vbo_get_minmax_index, etc. This has always been a problem, but it will
be a bigger problem with persistent buffer
Okay, sounds good.
Marek
On Wed, Feb 5, 2014 at 11:03 PM, Fredrik Höglund fred...@kde.org wrote:
On Wednesday 05 February 2014, Marek Olšák wrote:
On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul bri...@vmware.com wrote:
On 02/04/2014 04:26 PM, Marek Olšák wrote:
From: Marek Olšák
On 02/05/2014 01:23 PM, Dave Airlie wrote:
Since r600g in master now has GL 3.3 support and it would be really
good if we could provide a consistent 3.3 support level (not looking
at you sandybridge).
So I'd like to request that I can backport the r600g specific patches
to enable geom
Am 05.02.2014 22:58, schrieb Grigori Goronzy:
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/i915/i915_screen.c | 5 +
src/gallium/drivers/ilo/ilo_screen.c | 3 +++
src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
I hadn't looked at GL_ARB_buffer_storage. I need to read more closely, but at a
glance i looks like GL_MAP_PERSISTENT_BIT alone is okay (app needs to call
FlushMappedBufferRange must be called to guarantee coherence) but if
GL_MAP_COHERENCE_BIT is set we are indeed in face of the same issue...
The synchronization for non-coherent persistent mappings can also be done using:
glMemoryBarrier(GL_CLIENT_MAPPED_BUFFER_BARRIER_BIT);
In which case you don't know the range either. However I fully support
the addition of coherent persistent mappings to GL. It's perfect for
uploading data
On 02/05/2014 11:10 AM, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
would
have been alright if it wasn't for this bit in
On 02/05/2014 01:07 PM, Fabian Bieler wrote:
The hardcoded numbers are a few lines off at the moment.
Keeping track of the numbers through further modifications is inconvenient.
The __LINE__ constant takes care of this automatically.
Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
Re-send to include the wayland and mesa mailing lists.
Sorry for the noise
Original Message
Subject:[GSoC2014] Call for projects ideas and mentors
Date: Thu, 06 Feb 2014 01:03:05 +0100
From: Martin Peres martin.pe...@free.fr
To: dri-de...@lists.freedesktop.org
From: Marek Olšák marek.ol...@amd.com
This binds a NULL sampler view in that case.
Cc: 10.1 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_texture.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
From the GL_ARB_fbo spec:
If the source and destination buffers are identical, and the
source and destination rectangles overlap, the result of the blit
operation is undefined.
As far as I know, that's the only thing that would have been of concern
for this.
---
Surprisingly, the GLSL shaders already wrote the sampled r value to
FragDepth.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51600
---
src/mesa/drivers/common/meta_blit.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git
We're looking at the option of using meta to implement glBlitFramebuffer()
on gen8, to avoid writing another set of blorp code. I think it's looking
pretty promising. Here's a first patch series that gets us to the point
of fixing glBlitFramebuffer(DEPTH) performance on gm45, which seems like a
There was this funny argument passed to setup for did alloc decide we
need to allocate new texture storage?, which goes away if we don't have
the caller do alloc as a separate step.
---
src/mesa/drivers/common/meta.c | 15 +++
src/mesa/drivers/common/meta.h | 1 -
On a core context, this would throw an error.
---
src/mesa/drivers/common/meta_blit.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index 46c8efd..4e48e74 100644
---
I want split some meta.c code off to a separate file, so these functions
can't be static any more.
---
src/mesa/drivers/common/meta.c | 139 ++---
src/mesa/drivers/common/meta.h | 37 +++
2 files changed, 113 insertions(+), 63 deletions(-)
diff --git
---
src/mesa/Makefile.sources | 1 +
src/mesa/drivers/common/meta.c | 608 +---
src/mesa/drivers/common/meta.h | 3 +
src/mesa/drivers/common/meta_blit.c | 675
4 files changed, 680 insertions(+), 607
This avoids a CopyTexImage() on Intel i965 hardware without blorp.
---
src/mesa/drivers/common/meta_blit.c | 59 ++---
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index
I tripped over one of these when debugging meta, and it's a lot nicer to
just see the internalFormat being complained about.
---
src/mesa/main/teximage.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
This function is only handling the color case. We can just unindent as
long as we're willing to do the check for the bit outside of the
function.
---
src/mesa/drivers/common/meta_blit.c | 331 ++--
1 file changed, 168 insertions(+), 163 deletions(-)
diff --git
I'd like to split some of our code to separate files, since 4k lines and
growing is pretty unreasonable for all these separate operations.
---
src/mesa/drivers/common/meta.c | 268 -
src/mesa/drivers/common/meta.h | 268
This will let us use meta's acceleration from renderbuffers without having
to do a CopyTexImage first.
This is like what we do for TFP, but just taking an existing renderbuffer
and binding it to a texture with whatever its format was. The
implementation won't work for stencil renderbuffers, and
Am 06.02.2014 00:49, schrieb Jose Fonseca:
I hadn't looked at GL_ARB_buffer_storage. I need to read more closely, but at
a glance i looks like GL_MAP_PERSISTENT_BIT alone is okay (app needs to call
FlushMappedBufferRange must be called to guarantee coherence) but if
GL_MAP_COHERENCE_BIT is
On Mit, 2014-02-05 at 22:58 +0100, Grigori Goronzy wrote:
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 14dfd30..2f4098c 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -299,6 +299,12
---
src/mesa/drivers/common/meta_blit.c | 24
1 file changed, 24 deletions(-)
None of these seem to be necessary; the code compiles just fine without them.
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index 5f7cad7..e030f4d
On 02/05/2014 05:20 PM, Eric Anholt wrote:
This avoids a CopyTexImage() on Intel i965 hardware without blorp.
---
src/mesa/drivers/common/meta_blit.c | 59
++---
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git
I've rebuilt my mesa/llvm stack with this patch instead of the
alternative patches for fdo bug 70410. Everything seems satisfactory
after I rebuilt llvm with --enable-shared. I haven't done full
before/after piglit runs, but the partial run that I did is showing
what looks like a proper amount
To make sure that both the Gen4 and Gen7 style messages work, I
initially disabled the SHADER_OPCODE_GEN7_SCRATCH_READ optimization,
ran Piglit, re-enabled it, and ran Piglit again. Both worked fine.
Fixes 40 Piglit tests (most of the varying-packing category).
Signed-off-by: Kenneth Graunke
The new accessors will make it easy to do Gen7-style scratch messages.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen8_instruction.c | 23 +++
src/mesa/drivers/dri/i965/gen8_instruction.h | 23 +++
2 files changed,
Mesa fails to retain the precision qualifier when parsing:
#version 300 es
centroid in mediump vec2 v;
Consider how the parser's type_qualifier production is applied.
First, the precision_qualifier rule creates a new ast_type_qualifier:
precision: mediump
Then the storage_qualifier
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Jan 31, 2014 at 09:13:57AM +0100, Axel Davy wrote:
On 31/01/2014, Michel Dänzer wrote :
On Don, 2014-01-30 at 16:10 +0100, Axel Davy wrote:
dri2_dup_image was not copying the dri_format field.
This was causing some bugs, for example:
. we create an gbm_bo.
. we get an EGLImage from
95 matches
Mail list logo
