On Saturday, March 07, 2015 10:09:15 PM Jason Ekstrand wrote:
> LGTM.
Jason,
Sean doesn't have commit access (it's actually his first patch) - if
this is good to go, would you mind pushing it for him?
Nice work, Sean!
--Ken
signature.asc
Description: This is a digitally signed message part.
_
LGTM.
On Mar 7, 2015 8:34 PM, "Sean Burke" wrote:
> The memory layout of compatible internal formats may differ in bytes per
> block, so TexFormat is not a reliable measure of compatibility. For
> example,
> GL_RGB8 and GL_RGB8UI are compatible formats, but GL_RGB8 may be laid out
> in
> memory a
The memory layout of compatible internal formats may differ in bytes per
block, so TexFormat is not a reliable measure of compatibility. For example,
GL_RGB8 and GL_RGB8UI are compatible formats, but GL_RGB8 may be laid out in
memory as B8G8R8X8. If GL_RGB8UI has a 3 byte-per-block memory layout, t
This fixes ARB_texture_query_levels to actually return the desired
value.
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.5"
---
src/gallium/drivers/freedreno/ir3/ir3_compiler.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler.c
b
On Sat, Mar 7, 2015 at 2:10 PM, Sean Burke wrote:
> The memory layout of compatible internal formats may differ in bytes per
> block, so TexFormat is not a reliable measure of compatibility. For
> example,
> GL_RGB8 and GL_RGB8UI are compatible formats, but GL_RGB8 may be laid out
> in
> memory a
The memory layout of compatible internal formats may differ in bytes per
block, so TexFormat is not a reliable measure of compatibility. For example,
GL_RGB8 and GL_RGB8UI are compatible formats, but GL_RGB8 may be laid out in
memory as B8G8R8X8. If GL_RGB8UI has a 3 byte-per-block memory layout, t
Suggested-by: Emil Velikov
Signed-off-by: Vinson Lee
---
configure.ac | 1 +
scons/gallium.py | 1 +
src/util/macros.h | 6 ++
3 files changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index 90c7737..2954f80 100644
--- a/configure.ac
+++ b/configure.ac
@@ -195,6 +195,7
On Sat, Mar 7, 2015 at 9:58 AM, Emil Velikov
wrote:
> On 27 February 2015 at 08:06, Kenneth Graunke
> wrote:
> > We used to loop over all color attachments, and emit FB writes for each
> > one, even if the shader didn't write to a corresponding output variable.
> > Those color attachments would
On Thu, Mar 5, 2015 at 9:39 PM, Jason Ekstrand wrote:
> This looks fine to me. I just kicked off a build on our test farm and,
> assuming that looks good (I'll send another e-mail in the morning if it
> does),
>
> Reviewed-by: Jason Ekstrand
>
Jenkins results look god so feel free to apply the
On Sat, Mar 7, 2015 at 12:16 PM, Sean Burke wrote:
>
>
> On Sat, Mar 7, 2015 at 12:06 PM, Jason Ekstrand
> wrote:
>
>>
>> On Mar 7, 2015 10:57 AM, "Sean Burke" wrote:
>> >
>> > The memory layout of compatible internal formats may differ in bytes per
>> > block, so TexFormat is not a reliable me
Matt Turner writes:
> On Sat, Mar 7, 2015 at 12:54 PM, Francisco Jerez
> wrote:
>> Matt Turner writes:
>>
>>> On Fri, Mar 6, 2015 at 11:43 PM, Vinson Lee wrote:
Silences GCC unused-function warning.
nv30/nvfx_fragprog.c:333:1: warning: ‘nv40_fp_bra’ defined but not used
[
On Sat, Mar 7, 2015 at 12:54 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Fri, Mar 6, 2015 at 11:43 PM, Vinson Lee wrote:
>>> Silences GCC unused-function warning.
>>>
>>> nv30/nvfx_fragprog.c:333:1: warning: ‘nv40_fp_bra’ defined but not used
>>> [-Wunused-function]
>>> nv40_fp_br
Matt Turner writes:
> On Fri, Mar 6, 2015 at 11:43 PM, Vinson Lee wrote:
>> Silences GCC unused-function warning.
>>
>> nv30/nvfx_fragprog.c:333:1: warning: ‘nv40_fp_bra’ defined but not used
>> [-Wunused-function]
>> nv40_fp_bra(struct nvfx_fpc *fpc, unsigned target)
>> ^
>>
>> Signed-off-by
On Fri, Mar 6, 2015 at 11:43 PM, Vinson Lee wrote:
> Silences GCC unused-function warning.
>
> nv30/nvfx_fragprog.c:333:1: warning: ‘nv40_fp_bra’ defined but not used
> [-Wunused-function]
> nv40_fp_bra(struct nvfx_fpc *fpc, unsigned target)
> ^
>
> Signed-off-by: Vinson Lee
> ---
> src/galli
On Sat, Mar 7, 2015 at 1:13 PM, Brian Paul wrote:
> On Sat, Mar 7, 2015 at 12:38 PM, Emil Velikov
> wrote:
>
>
>> FYI I'm contemplating on about adding a final wrapper - c99_string.h. It
>> should nuke nearly all of the remaining compiler abstraction that we
>> have around - mapi, egl, gallium,
On Sat, Mar 7, 2015 at 12:06 PM, Jason Ekstrand
wrote:
>
> On Mar 7, 2015 10:57 AM, "Sean Burke" wrote:
> >
> > The memory layout of compatible internal formats may differ in bytes per
> > block, so TexFormat is not a reliable measure of compatibility.
> Additionally,
> > the current check allow
On Sat, Mar 7, 2015 at 12:38 PM, Emil Velikov
wrote:
>
> FYI I'm contemplating on about adding a final wrapper - c99_string.h. It
> should nuke nearly all of the remaining compiler abstraction that we
> have around - mapi, egl, gallium, mesa, glsl...
>
Yeah, I was looking at doing something like
On 07/03/15 07:23, Jose Fonseca wrote:
...
> we still
> didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
> tree gave me pause.
>
The only way I can think about resolving this, is to use call_once() to
initialize the mutex, but I'm not 100% sure if T2 will sync until T1
call_o
On Mar 7, 2015 10:57 AM, "Sean Burke" wrote:
>
> The memory layout of compatible internal formats may differ in bytes per
> block, so TexFormat is not a reliable measure of compatibility.
Additionally,
> the current check allows compressed textures of the same block size to be
used,
> which is in
The memory layout of compatible internal formats may differ in bytes per
block, so TexFormat is not a reliable measure of compatibility. Additionally,
the current check allows compressed textures of the same block size to be used,
which is in violation of the spec.
v2: Use a switch instead of arra
On 07/03/15 07:43, Vinson Lee wrote:
> Silences GCC unused-function warning.
>
> nv30/nvfx_fragprog.c:333:1: warning: ‘nv40_fp_bra’ defined but not used
> [-Wunused-function]
> nv40_fp_bra(struct nvfx_fpc *fpc, unsigned target)
> ^
>
> Signed-off-by: Vinson Lee
> ---
> src/gallium/drivers/no
On 4 March 2015 at 22:26, Dave Airlie wrote:
> this isn't hooked up to anything at all from what I can see.
>
> Signed-off-by: Dave Airlie
I've noticed the same thing the other day, thanks to Ilia for bringing
me here :-)
Seems like a left over from commit 5d67d4fbebb(st/mesa: remove
st_TexImage
On 7 March 2015 at 18:00, Matt Turner wrote:
> On Sat, Mar 7, 2015 at 9:54 AM, Emil Velikov wrote:
>> On 27 February 2015 at 19:34, Matt Turner wrote:
>>> For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
>>> function would see that one of the +'s sources was a negate expressio
[+jekstrand, who wrote the initial ARB_copy_image support and knows a
thing or two about texture formats]
On Sat, Mar 7, 2015 at 4:42 AM, Sean Burke wrote:
> The memory layout of compatible internal formats may differ in bytes per
> block, so TexFormat is not a reliable measure of compatibility.
On Sat, Mar 7, 2015 at 9:54 AM, Emil Velikov wrote:
> On 27 February 2015 at 19:34, Matt Turner wrote:
>> For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
>> function would see that one of the +'s sources was a negate expression
>> and set mul_negate = true without confirming t
On 27 February 2015 at 08:06, Kenneth Graunke wrote:
> We used to loop over all color attachments, and emit FB writes for each
> one, even if the shader didn't write to a corresponding output variable.
> Those color attachments would be filled with garbage (undefined values).
>
> Football Manager
On 27 February 2015 at 19:34, Matt Turner wrote:
> For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
> function would see that one of the +'s sources was a negate expression
> and set mul_negate = true without confirming that it was actually a
> multiply.
>
Hi Matt,
This commit
On 4 March 2015 at 23:15, Emil Velikov wrote:
> On 4 March 2015 at 17:22, Neil Roberts wrote:
>> This reverts commit 546aba143d13ba3f993ead4cc30b2404abfc0202.
>>
>> I think the changes to the calls to glBlitFramebuffer from this patch
>> are no different to what it was doing previously because it
On 5 March 2015 at 01:57, Matt Turner wrote:
> On Wed, Mar 4, 2015 at 4:53 AM, Emil Velikov wrote:
>> Trivial merge conflicts
>> ---
>> Here are the commits where I manually merged conflicts, so these might
>> merit additional review:
>>
>> commit a598a9bdfe9f5d0ed35ca89a55cf7
Topi Pohjolainen writes:
> The original patch from Curro was based on something that is not
> present in the master yet. This patch tries to mimick the logic on
> top master.
> I wanted to see if could separate the building of the descriptor
> instruction from building of the send instruction. Th
On Thu, Mar 05, 2015 at 09:51:22PM -0500, Vivek Kasireddy wrote:
> If there are multiple EGL surfaces associated with one EGL context, for
> any given surface, we unnecessarily have to wait for swapbuffers to
> complete on other EGL surfaces because we throttle to the context.
> By moving first_pos
On Fri, Mar 06, 2015 at 03:11:27PM +0200, Francisco Jerez wrote:
> "Pohjolainen, Topi" writes:
>
> > On Fri, Feb 27, 2015 at 05:34:51PM +0200, Francisco Jerez wrote:
> >> This doesn't actually enable untyped surface message sends from GRF
> >> yet, the upcoming atomic counter and image intrinsic
The memory layout of compatible internal formats may differ in bytes per
block, so TexFormat is not a reliable measure of compatibility. Additionally,
the current check allows compressed textures of the same block size to be used,
which is in violation of the spec.
Additionally, add a fixme for an
The original patch from Curro was based on something that is not
present in the master yet. This patch tries to mimick the logic on
top master.
I wanted to see if could separate the building of the descriptor
instruction from building of the send instruction. This logic now
allows the caller to con
On Friday, February 27, 2015 05:34:44 PM Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_eu.h | 19 ++--
> src/mesa/drivers/dri/i965/brw_eu_emit.c | 58
> ++--
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 55 +
On Friday, March 06, 2015 03:20:26 PM Pohjolainen, Topi wrote:
> On Fri, Mar 06, 2015 at 02:46:51PM +0200, Francisco Jerez wrote:
> > "Pohjolainen, Topi" writes:
> >
> > > On Fri, Mar 06, 2015 at 02:29:15PM +0200, Francisco Jerez wrote:
> > >> "Pohjolainen, Topi" writes:
> > >>
> > >> > On Fri,
nouveau_compiler.c: In function ‘main’:
nouveau_compiler.c:216:27: warning: ‘code’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
printf("%08x ", code[i / 4]);
^
nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in this
funct
nouveau_compiler.c: In function ‘main’:
nouveau_compiler.c:216:27: warning: ‘code’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
printf("%08x ", code[i / 4]);
^
nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in this
funct
38 matches
Mail list logo
