Am 05.02.2014 00:01, schrieb Marek Olšák:
From: Marek Olšák
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
---
src/gallium/drivers/radeon/r600_texture.c | 2 +-
src/gallium/winsys/rad
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 wrote:
> From: Michel Dänzer
>
> Fixes opencl-example if_* tests with radeonsi.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74469
> Sign
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
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
b/src/gallium/winsys/radeon/drm/rade
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 interf
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 2ac
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
b/src/gallium/winsys/radeon/drm/ra
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
Classifica
https://bugs.freedesktop.org/show_bug.cgi?id=74563
Alexandros Frantzis changed:
What|Removed |Added
Attachment #93443|text/plain |application/x-gtar
mime t
https://bugs.freedesktop.org/show_bug.cgi?id=74563
--- Comment #1 from Alexandros Frantzis ---
Created attachment 93444
--> https://bugs.freedesktop.org/attachment.cgi?id=93444&action=edit
Potential fix
--
You are receiving this mail because:
You are the assignee for the bug.
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 b
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 changed:
What|Removed |Added
Hardware|x86-64 (AMD64) |All
OS|Linux (All)
---
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
@@ -386,
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
@@ -47,
---
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 lo
---
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 @@
Thanks for you response.
First three changes pursued one purpose and meaningless without each other, but
glcpp changes can be separated from it. I think, glsl_parser.yy may be
separated too, because it have a lot of alteration. I'll do it today.
> Or did you mean just that it computed location i
On Tue, Jan 28, 2014 at 2:45 PM, Paul Berry wrote:
> On 22 January 2014 09:16, Connor Abbott 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
>> @@ -40,7 +40,15 @@ ir_rvalue::clon
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. However,
On 4 February 2014 10:03, Jordan Justen 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 (_mesa_is_extension_override_enabl
On Tue, Jan 28, 2014 at 1:50 PM, Paul Berry wrote:
> On 22 January 2014 09:16, Connor Abbott 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, the SSA temporary, which is guarentee
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 C
https://bugs.freedesktop.org/show_bug.cgi?id=65534
--- Comment #3 from Eric Anholt ---
*** 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 mailing list
me
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-
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 wrote:
> On 05.02.2014 18:08, Jose Fonseca wrote:
>
>> I hones
https://bugs.freedesktop.org/show_bug.cgi?id=65534
Eric Anholt changed:
What|Removed |Added
Assignee|i...@freedesktop.org |mesa-dev@lists.freedesktop.
- Original Message -
> ureg_program is allocated on the heap so we can just bump the
> number of immediates that it can handle. It's needed for d3d10.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
- 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
> > https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_
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 Goro
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 immedi
- 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
> > > https://urldefense.proofpoint.com/v1/url
On Fri, Jan 31, 2014 at 11:55 AM, Paul Berry wrote:
> On 22 January 2014 09:16, Connor Abbott 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 algorithm later, although extending the
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 G
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 thi
Pass pattern as bitmask in a unsigned int instead of as array of floats to the
geometry shader.
Signed-off-by: Fabian Bieler
---
src/glsl/geom-stipple-lines.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/src/glsl/geom-stipple-lines.c b/src/glsl/geom-
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
> ---
> src/glsl/geom-stipple-lines.c | 21 -
>
https://bugs.freedesktop.org/show_bug.cgi?id=72895
--- Comment #11 from Benjamin Bellec ---
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
--fg-scenery=/usr/share/flightgear/Scenery --airport
Sir Anthony 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;
>$$ = new(ctx) ast_function_
Sir Anthony 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; /**< Column in the
Sir Anthony 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!
This commit message a
On 02/04/2014 04:26 PM, Marek Olšák wrote:
From: Marek Olšák
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 deletions(-)
diff --
Bind the transform feedback buffer before drawing into it und unbind it
afterwards.
Signed-off-by: Fabian Bieler
---
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 eace71b..e76a3a2 100644
--- a
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
---
src/glsl/gsraytrace.cpp | 10 +++---
1 file changed, 7 insertions(+)
Signed-off-by: Fabian Bieler
---
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
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsra
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
---
src/util/glut_wrap.h | 4 +++-
1 file changed, 3 in
Signed-off-by: Fabian Bieler
---
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
@@ -776,7 +776,6 @@ Reshape(
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
---
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
---
configure.ac | 6 ++
1 file changed, 6 insertions(+)
diff --git a/c
Signed-off-by: Fabian Bieler
---
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
+++ b/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
---
src/glsl/geom-outlining-150.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
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.
glsl/gsraytrace
Signed-off-by: Fabian Bieler
---
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
+++ b/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
---
src/glsl/gsraytrace.cpp | 72 +
1 fi
Signed-off-by: Fabian Bieler
---
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
--- a/src/glsl/geom-outlining-150.c
+++ b/src/
On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul wrote:
> On 02/04/2014 04:26 PM, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> STATIC will be removed in the following commit.
>> ---
>> src/gallium/docs/source/screen.rst | 18 --
>> src/gallium/include/pipe/p_defines.h | 13 +++
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 patch
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 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 enab
Reviewed-by: Matt Turner
___
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 ++
s
On Wednesday 05 February 2014, Marek Olšák wrote:
> On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul wrote:
> > On 02/04/2014 04:26 PM, Marek Olšák wrote:
> >>
> >> From: Marek Olšák
> >>
> >> STATIC will be removed in the following commit.
> >> ---
> >> src/gallium/docs/source/screen.rst | 18 +++
From: Marek Olšák
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 mappings, which will pr
Okay, sounds good.
Marek
On Wed, Feb 5, 2014 at 11:03 PM, Fredrik Höglund wrote:
> On Wednesday 05 February 2014, Marek Olšák wrote:
>> On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul wrote:
>> > On 02/04/2014 04:26 PM, Marek Olšák wrote:
>> >>
>> >> From: Marek Olšák
>> >>
>> >> STATIC will be re
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 without
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 i
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
> ---
> src/glsl/gsra
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
To: dri-de...@lists.freedesktop.org ,
xorg-de...@lists.x.or
From: Marek Olšák
This binds a NULL sampler view in that case.
Cc: "10.1" "10.0"
---
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
b/src/mesa/state_tracker/st_cb_texture.c
index 81a5d9b..824a13e 100644
-
>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.
---
src/mesa/drivers/com
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 a/src/mesa/drivers/c
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
n
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 -
src/mesa
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
--- a/src/mesa/drivers/common/
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 a
---
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 deletion
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 3c
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
ind
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 a/s
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 i
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
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 +2
---
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 1006
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 a/src/mesa/drivers/common/m
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 of
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
---
src/mesa/drivers/dri/i965/gen8_instruction.c | 23 +++
src/mesa/drivers/dri/i965/gen8_instruction.h | 23 +++
2 files changed, 46 insertions(+)
diff
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:
Then the storage_qualifier rule creates a secon
Reviewed-by: Matt Turner
___
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
97 matches
Mail list logo
