Am 09.08.2013 20:06, schrieb Marek Olšák:
[SNIP]
What if I kept the current emission code, and only allocated a new
buffer at the end of the emit function, copied all descriptors to it
using CP_DMA or COPY_DATA, and pointed SPI_SHADER_USER_DATA to it. The
buffer where the descriptors are updated
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
The pipe_surface miscount caused issues for my (failed) attempt at getting
vdpau to work with pmpeg.
src/gallium/drivers/nouveau/nouveau_video.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Force the format to be the reasonable format that doesn't require an
inverse z-scan.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Tested this on both nv44 and nv96, and it works, all at the same time. Without
the 0x72 command, they default to different scan orders. Putting the 0x72
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I don't think anything looks at this right now, but seems good to store. (Also
ran into it with my vdpau attempt.)
src/gallium/drivers/nouveau/nouveau_video.c | 1 +
1 file changed, 1 insertion(+)
diff --git
This also allows people who don't want to install the binary blobs
required for VP2 to still get MPEG decoding.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nv50/nv50_context.c | 3 ++-
src/gallium/drivers/nv50/nv50_screen.c | 3 ++-
2 files changed, 4 insertions(+),
The RCU approach sounds good, but you can never know if 16 is enough.
We should release the buffer once it is full and allocate a new one.
The cache bufmgr in the winsys will assure there won't be any buffer
allocation overhead - it would work kinda a like a ring of buffers.
Marek
On Sat, Aug
Am 10.08.2013 15:53, schrieb Marek Olšák:
The RCU approach sounds good, but you can never know if 16 is enough.
We should release the buffer once it is full and allocate a new one.
The cache bufmgr in the winsys will assure there won't be any buffer
allocation overhead - it would work kinda a
On Sat, Aug 10, 2013 at 5:09 PM, Christian König
deathsim...@vodafone.de wrote:
Am 10.08.2013 15:53, schrieb Marek Olšák:
The RCU approach sounds good, but you can never know if 16 is enough.
We should release the buffer once it is full and allocate a new one.
The cache bufmgr in the winsys
Reviewed-by: Marek Olšák mar...@gmail.com
On Fri, Aug 9, 2013 at 11:59 AM, Niels Ole Salscheider
niels_...@salscheider-online.de wrote:
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/drivers/radeonsi/r600.h| 1 +
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Fri, Aug 9, 2013 at 11:59 AM, Niels Ole Salscheider
niels_...@salscheider-online.de wrote:
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 +
1 Datei
v2: simplify flushing in si_context_flush
---
src/gallium/drivers/radeonsi/r600_hw_context.c | 3 +
src/gallium/drivers/radeonsi/r600_resource.h | 21
src/gallium/drivers/radeonsi/r600_texture.c| 133 -
src/gallium/drivers/radeonsi/radeonsi_pipe.h | 2 +
Resolving to scanout buffers just doesn't work.
---
src/gallium/drivers/radeonsi/r600_blit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/r600_blit.c
b/src/gallium/drivers/radeonsi/r600_blit.c
index 3f9a184..1840e28 100644
---
This fixes the F2U opcode for the Mesa driver.
Signed-off-by: Marek Olšák marek.ol...@amd.com
---
lib/Target/R600/SIInstructions.td | 4 +++-
test/CodeGen/R600/fp_to_uint.ll | 27 ++-
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git
Signed-off-by: Marek Olšák marek.ol...@amd.com
---
lib/Target/R600/AMDGPUCallingConv.td | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Target/R600/AMDGPUCallingConv.td
b/lib/Target/R600/AMDGPUCallingConv.td
index fc95d58..84d3118 100644
---
Signed-off-by: Marek Olšák marek.ol...@amd.com
---
lib/Target/R600/SIInstructions.td | 5 +
lib/Target/R600/SIRegisterInfo.td | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/Target/R600/SIInstructions.td
b/lib/Target/R600/SIInstructions.td
index d941035..be2e290
Signed-off-by: Marek Olšák marek.ol...@amd.com
---
lib/Target/R600/R600Instructions.td| 16 +++-
lib/Target/R600/SIInstructions.td | 19 ++-
test/CodeGen/R600/llvm.SI.imageload.ll | 2 +-
3 files changed, 34 insertions(+), 3 deletions(-)
diff --git
Link to internal libwayland-drm library if Wayland
EGL platform is enabled.
Link to libdrm if gbm_dri is enabled.
---
src/gbm/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am
index e22c55c..1282b14 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=67962
Hrvoje Senjan hrvoje.sen...@gmail.com changed:
What|Removed |Added
Assignee|wayland-bugs@lists.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=67962
--- Comment #2 from Armin K kre...@email.com ---
I've sent a fix today
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043097.html
--
You are receiving this mail because:
You are the assignee for the bug.
On 08/10/2013 09:26 PM, Armin K wrote:
Link to internal libwayland-drm library if Wayland
EGL platform is enabled.
Link to libdrm if gbm_dri is enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67962
---
src/gbm/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1
Looks like the same issue that was seen with MULADD in trans slot on
R7xx also affects MULADD_IEEE (maybe all OP3 instructions and MULADD is
just a most frequently used?). The workaround is to never put
affected instructions into the trans slot.
IIRC it was mostly observed when affected
MSAA was tested by one user on RS690 and it works for him with color
compression (CMASK) disabled. Our theory is that his chipset lacks CMASK RAM.
Since we don't have hardware documentation about which chipsets actually have
CMASK RAM, I had to take a guess based on the presence of HiZ.
---
22 matches
Mail list logo
