We keep having to pass the attachments around with our gl_renderbuffers
because that's the only way to find what the gl_renderbuffer actually
refers to. This is a step toward removing that (though drivers still need
the Zoffset as well).
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +
This is the opportunity that radeon and intel drivers rely on for flushing
render targets that may get reused as textures. Before EGL, that only
happened for GL_TEXTURE attachments.
Fixes piglits:
KHR_gl_renderbuffer_image/renderbuffer-texture
OES_EGL_image/renderbuffer-texture
NOTE: This is a c
Now that the rb has a reference to the teximage, we didn't need anything
else out of the attachment.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 4 +---
src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 4 ++--
src/mesa/drivers/dri/radeon/radeon_fbo.c | 5 ++---
src/mesa/main/dd.h
I should have killed this in my previous cleanup.
---
src/mesa/drivers/dri/radeon/radeon_fbo.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c
b/src/mesa/drivers/dri/radeon/radeon_fbo.c
index e546a6b..c43f527 100644
--- a
This patch fixes SCons builds on Fedora 18.
Signed-off-by: Vinson Lee
---
scons/llvm.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index 7cd609c..432ece6 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -198,7 +198,15 @@ def gener
On Fri, May 10, 2013 at 2:49 PM, Ian Romanick wrote:
> On 05/08/2013 07:21 PM, Matt Turner wrote:
>>
>> For vec4 equality comparisons we emit
>>
>> (and (and (and a b) c) d)
>
>
> Refresh my memory... what generates this? Is this from the compiler itself,
> or are people writing this code by
https://bugs.freedesktop.org/show_bug.cgi?id=64450
Priority: medium
Bug ID: 64450
Keywords: regression
CC: srol...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit cubemap npot regression
S
On Wed, May 1, 2013 at 10:10 PM, Kenneth Graunke wrote:
> On 05/01/2013 09:25 PM, Jordan Justen wrote:
>> On Wed, May 1, 2013 at 9:13 PM, Matt Turner wrote:
>>> On Wed, May 1, 2013 at 8:41 PM, Jordan Justen wrote:
On Tue, Apr 30, 2013 at 10:01 AM, Jordan Justen
wrote:
> On Tue, Ap
On 04/16/2013 05:21 PM, Eric Anholt wrote:
The next commit introduces what is apparently our first one, which tripped
over this in glReadPixels.
---
src/mesa/drivers/dri/intel/intel_blit.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/mesa/dri
On 04/16/2013 05:21 PM, Eric Anholt wrote:
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 94e712e..c1e3b14
On 05/08/2013 07:21 PM, Matt Turner wrote:
For vec4 equality comparisons we emit
(and (and (and a b) c) d)
Refresh my memory... what generates this? Is this from the compiler
itself, or are people writing this code by hand? On old, vec4-centric
architectures, this sort of thing was usu
On 05/10/2013 01:45 PM, Eric Anholt wrote:
Ian Romanick writes:
On 04/16/2013 05:21 PM, Eric Anholt wrote:
This should already be handled by _mesa_base_tex_format() calls in
TexImage*.
---
NOTE!
I've replaced the actual patch full of unindentation of code described by:
src/mesa/main/texf
https://bugs.freedesktop.org/show_bug.cgi?id=58137
--- Comment #1 from romula...@gmail.com ---
Retest with latest please. I do not see this issue on latest.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing
Andreas Hartmetz writes:
> On Wednesday 08 May 2013 13:33:37 Eric Anholt wrote:
>> Christoph Brill writes:
>> > Hi list,
>> >
>> > I'm trying to follow the patches and patchsets sent to mesa-dev and
>> > really like the process of how they get reviewed. It's a good way of
>> > catching bugs bef
On Fri, May 10, 2013 at 12:57 PM, Manfred Ernst wrote:
> Problem: The IEEE float optimized version of UNCLAMPED_FLOAT_TO_UBYTE in
> macros.h
> computed incorrect results for inputs in the range 0x3f7f (=0.99609375) to
> 0x3f7f7f80 (=0.99803924560546875) inclusive. 0x3f7f7f80 is the IEEE floa
Ian Romanick writes:
> On 04/16/2013 05:21 PM, Eric Anholt wrote:
>> This should already be handled by _mesa_base_tex_format() calls in
>> TexImage*.
>> ---
>>
>> NOTE!
>>
>> I've replaced the actual patch full of unindentation of code described by:
>> src/mesa/main/texformat.c | 1184
>> +
Problem: The IEEE float optimized version of UNCLAMPED_FLOAT_TO_UBYTE in
macros.h
computed incorrect results for inputs in the range 0x3f7f (=0.99609375) to
0x3f7f7f80 (=0.99803924560546875) inclusive. 0x3f7f7f80 is the IEEE float
value that results in 254.5 when multiplied by 255. With roun
Kenneth Graunke writes:
> This series does two things: first, it plumbs ShaderCompilerOptions into
> do_common_optimization(), since optimization & lowering passes may want
> to consult that.
>
> Secondly, it adds an optimization pass that converts (matrix * vector)
> operations to (vector * matr
On Wednesday 08 May 2013 13:33:37 Eric Anholt wrote:
> Christoph Brill writes:
> > Hi list,
> >
> > I'm trying to follow the patches and patchsets sent to mesa-dev and
> > really like the process of how they get reviewed. It's a good way of
> > catching bugs before they get committed. But current
Chad Versace writes:
> On 05/10/2013 10:16 AM, Eric Anholt wrote:
>> Chad Versace writes:
>>
>>> The drivers was setting MOCS (Memory Object Control State) to 0 for all
>>> objects. This patch sets it as following:
>>> renderbuffer, depthbuffer => LLC uncacheable, L3 cacheable
>>> text
On 05/07/2013 10:55 PM, Kenneth Graunke wrote:
On 04/17/2013 05:30 PM, Kenneth Graunke wrote:
We can't include shaderobj.h from the standalone utilities, so we
unfortunately have to copy this function.
Signed-off-by: Kenneth Graunke
---
src/glsl/standalone_scaffolding.h | 17
On 05/10/2013 02:06 AM, Kenneth Graunke wrote:
Marek added these new formats in commit f9fa725690c470daf308, but
without comments relating to the packing. Sometimes the naming is
confusing, so these comments are helpful in determining whether two
formats are compatible.
The new comments are bas
On 05/10/2013 10:16 AM, Eric Anholt wrote:
Chad Versace writes:
The drivers was setting MOCS (Memory Object Control State) to 0 for all
objects. This patch sets it as following:
renderbuffer, depthbuffer => LLC uncacheable, L3 cacheable
texture, stencil, hiz => LLC cacheable, L3 cach
Chad Versace writes:
> The drivers was setting MOCS (Memory Object Control State) to 0 for all
> objects. This patch sets it as following:
> renderbuffer, depthbuffer => LLC uncacheable, L3 cacheable
> texture, stencil, hiz => LLC cacheable, L3 cacheable
>
> The goal here is to avoid blow
Marek Olšák writes:
> Ping. Can I push this commit, Eric?
>
> Also, I don't think it's important what the
> MAX_COMBINED_TEXTURE_IMAGE_UNITS limit is right now, because a program
> object cannot have more than 16 samplers *combined* anyway
> (Elements(gl_shader_program::SamplerUnits) == 16), so t
Ping. Can I push this commit, Eric?
Also, I don't think it's important what the
MAX_COMBINED_TEXTURE_IMAGE_UNITS limit is right now, because a program
object cannot have more than 16 samplers *combined* anyway
(Elements(gl_shader_program::SamplerUnits) == 16), so the old limit
was wrong too.
We h
On 05/07/2013 10:55 PM, Kenneth Graunke wrote:
On 04/17/2013 05:30 PM, Kenneth Graunke wrote:
We can't include shaderobj.h from the standalone utilities, so we
unfortunately have to copy this function.
Signed-off-by: Kenneth Graunke
---
src/glsl/standalone_scaffolding.h | 17
Reviewed-by: Marek Olšák
Marek
On Fri, May 10, 2013 at 11:06 AM, Kenneth Graunke wrote:
> Marek added these new formats in commit f9fa725690c470daf308, but
> without comments relating to the packing. Sometimes the naming is
> confusing, so these comments are helpful in determining whether two
Marek added these new formats in commit f9fa725690c470daf308, but
without comments relating to the packing. Sometimes the naming is
confusing, so these comments are helpful in determining whether two
formats are compatible.
The new comments are based on my reading of format_unpack.c.
Cc: Eric An
On Fri, May 10, 2013 at 10:44:05AM +0300, Ander Conselvan de Oliveira wrote:
> On 05/08/2013 11:50 PM, Jonas Ådahl wrote:
> >On Tue, Apr 23, 2013 at 3:54 PM, Ander Conselvan de Oliveira
> > wrote:
> >>Linux kernel 3.8 shipped with a bug in the prime fd passing code that
> >>makes it unreliable. As
On 05/08/2013 11:50 PM, Jonas Ådahl wrote:
On Tue, Apr 23, 2013 at 3:54 PM, Ander Conselvan de Oliveira
wrote:
Linux kernel 3.8 shipped with a bug in the prime fd passing code that
makes it unreliable. As of this writing, it seems unlikely that 3.9
will contain the fix for the issue.
This patc
On Fri, May 10, 2013 at 1:42 PM, Vinson Lee wrote:
> Fixes "Uninitialized scalar variable" defect reported by Coverity.
Committed, thanks.
> Signed-off-by: Vinson Lee
> ---
> src/gallium/drivers/ilo/ilo_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/galli
Good morning everyone,
On 08.05.2013 23:30, Uli Schlachter wrote:
[...]
> Ah, after writing the rest of this mail, I just had this idea:
>
> - X11 has taken the socket
> - Thread A has locked the display.
> - Thread B does xcb_no_operation() and thus ends up in libX11's
> return_socket(),
> wait
33 matches
Mail list logo
