On Thu, Dec 19, 2013 at 01:40:23PM -0800, Matt Turner wrote:
> Previously we simply considered two registers whose live ranges
> overlapped to interfere. Cases such as
>
>set A --
>... |
>mov B, A --|
>... | B | A
>use B --|
>...
This fixes piglit arb_draw_buffers-rt0_none on AMD CEDAR. No piglit
regressions on the same hardware.
Signed-off-by: Henri Verbeet
---
src/mesa/state_tracker/st_cb_clear.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
In particular, we don't want it to be -1. In practice this is probably
unlikely to be an issue, since Attachment[-1] should still be a valid memory
location, and the code only reads it. No piglit regressions on AMD CEDAR.
Signed-off-by: Henri Verbeet
---
src/mesa/state_tracker/st_manager.c |
This looks good, but it's only papering over the real problem, which
is that st/mesa doesn't bind NULL colorbuffers and skips them instead.
For example, if DRAWBUFFER0 is NONE, st/mesa binds DRAWBUFFER1 to
cb[0], but then all writes to gl_FragData[1] are broken, because the
draw buffer has been mov
Reviewed-by: Marek Olšák
Marek
On Wed, Dec 25, 2013 at 12:41 PM, Henri Verbeet wrote:
> In particular, we don't want it to be -1. In practice this is probably
> unlikely to be an issue, since Attachment[-1] should still be a valid memory
> location, and the code only reads it. No piglit regress
https://bugs.freedesktop.org/show_bug.cgi?id=72889
--- Comment #6 from Martin Andersson ---
Created attachment 91188
--> https://bugs.freedesktop.org/attachment.cgi?id=91188&action=edit
patch
Yep, that seems to be the issue. The attached patch fixes the issue for me, but
I'm not familiar with
Some comments about the r300g patch.
The hardware doesn't support Axxx texture formats for blending and
alpha-test. Only xxxA formats are supported. The driver already
supports all formats it can support and no other formats can be added
(except for those where the component ordering matches
curre
---
src/mesa/state_tracker/st_program.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index f72122b..f13132e 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_t
---
src/mesa/state_tracker/st_extensions.c | 4 +++-
src/mesa/state_tracker/st_format.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 5e4a3b3..8c49e54 100644
--- a/src/mesa/state_tra
---
src/gallium/drivers/nouveau/nv50/nv50_formats.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index 0a7e812..b301890 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
+++
The motivation was to use the same names as Gallium and then to fix
the Gallium naming. Also, core Mesa is likely to share u_format tools
and code generation with Gallium eventually anyway and then all the
Mesa format pack and unpack functions will get removed. Given that, I
don't see a point in im
On Wed, Dec 25, 2013 at 5:53 PM, Christoph Bumiller
wrote:
> ---
> src/mesa/state_tracker/st_extensions.c | 4 +++-
> src/mesa/state_tracker/st_format.c | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_track
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #76 from Thomas131 ---
Hello,
Now, I have the same problem with Linux Mint 15. There is also a bug on
launchpad.: https://bugs.launchpad.net/ubuntu/+source/blender/+bug/902618
--
You are receiving this mail because:
You are the assi
On 25 December 2013 14:17, Marek Olšák wrote:
> This looks good, but it's only papering over the real problem, which
> is that st/mesa doesn't bind NULL colorbuffers and skips them instead.
> For example, if DRAWBUFFER0 is NONE, st/mesa binds DRAWBUFFER1 to
> cb[0], but then all writes to gl_FragD
I'd like to propose a draft naming convention for MESA_FORMATs, which, if
we can agree on that, then other format systems can be brought to
conformance on their own time, after the MESA_FORMATS are fixed.
First, there shall be 3 naming format base types: those for component array
formats (type A);
On Mit, 2013-12-25 at 15:57 +0100, Marek Olšák wrote:
> Some comments about the r300g patch.
>
> The hardware doesn't support Axxx texture formats for blending and
> alpha-test. Only xxxA formats are supported.
I know, the idea is to only actually use the Axxx layout for transfers
but to use xxxA
https://bugs.freedesktop.org/show_bug.cgi?id=72889
--- Comment #7 from Michel Dänzer ---
Looks like a good start at least. Please submit it to the mesa-dev /
wayland-devel mailing list(s) for review.
--
You are receiving this mail because:
You are the QA Contact for the bug.
___
On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:
>
> --Format Base Type P: Packed --
> MESA_FORMAT_[[component list,bit width][storage type*][_]][_][storage
> type**]
> * when type differs between component
> ** when type applies to all components
>
>
> examples:
>
On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer wrote:
> On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:
> >
> > --Format Base Type P: Packed --
> > MESA_FORMAT_[[component list,bit width][storage type*][_]][_][storage
> > type**]
> > * when type differs between compon
https://bugs.freedesktop.org/show_bug.cgi?id=59304
Bug 59304 depends on bug 60016, which changed state.
Bug 60016 Summary: After automake merge two different GPU (AMD + NVIDIA)
willnot work on same machine
https://bugs.freedesktop.org/show_bug.cgi?id=60016
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=60016
Axel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
21 matches
Mail list logo
