On 08.04.2014 00:31, Timo Aaltonen wrote:
On 12.03.2014 10:43, Kenneth Graunke wrote:
arekm reported that using Chrome with GPU acceleration enabled on GM45
triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
We definitely do not want to advertise reset notification
On 23.03.2014 04:53, Kai Wasserbäch wrote:
Dear Mesa devs,
I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash
happens
in _int_malloc, but since that is certainly one of the more often used
functions, I'm not yet convinced, the fault lies indeed with eglibc.
Therefore
Hi,
Tremulous and Smoking Guns regressed in Mesa master, ok in 020c43f,
broken in 4ddf51db.
Tremulous 133 to 33 fps, Smoking Guns 153 to 40. In the ok version,
hyperz was enabled by default; in the more recent master, it was
disabled by default, but enabled via the R600_DEBUG env var. The env
Fixes piglit's fbo-blit-stretch test on drivers which use the meta path.
(i965: should fix Broadwell, but also fixes Sandybridge/Ivybridge/Haswell
since this test falls off the blorp path now due to format conversion)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Bugzilla:
On 04/08/2014 02:03 PM, Eric Anholt wrote:
Here's a rework of the series for meta CopyTexSubImage (required for
i965's gen8 support, since we're probably going to avoid doing blorp at
all for it). Ken had almost-reviewed a previous version of the patch, but
I went back and did some refactors
We are traversing the relevant branch manually with a for loop to insert the
instructions one by one. I think we can insert all the instructions in a single
operation using a list insert instead.
One thing to notice, the insert_before() method for lists will call
make_empty() on the passed list
Once the relevant branch has been identified do not iterate over the
instructions in the branch, do a linked list insertion instead to avoid the
loop.
---
src/glsl/opt_if_simplification.cpp | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
The staging texture should always be idle, so I guess this just skips
the needless GEM_WAIT_IDLE call?
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Tue, Apr 15, 2014 at 7:46 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
The transfer staging
Well the question isn't if we need a synchronous flush, which as far as
I can see is clear that we need it. But instead if we should implement
the synchronous flush if with an extra flag while calling cs_flush_sync
directly after the submission is equivalent.
It is possible that upper layers
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Dorrington, Albert albert.dorring...@lmco.com writes:
From reading the OpenCL spec (and perhaps I'm misinterpreting something
again), section 5.10 Flush and Finish says:
Any blocking commands queued in
Dorrington, Albert albert.dorring...@lmco.com writes:
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Dorrington, Albert albert.dorring...@lmco.com writes:
From reading the OpenCL spec (and perhaps I'm misinterpreting something
again), section 5.10 Flush
Am 15.04.2014 02:52, schrieb Andreas Hartmetz:
+ /* right shift convert, losing the low bit - must clear
+* high bit because there is no unsigned convert
instruction */
sse2_psrld_imm(p-func, dataXMM, 1);
+ sse2_cvtdq2ps(p-func,
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Dorrington, Albert albert.dorring...@lmco.com writes:
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Dorrington, Albert albert.dorring...@lmco.com writes:
From
Ping
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
Ping (with fixed subject)
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
This is a refresh of:
http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
At the moment the python code uses sys.byteorder to
Dorrington, Albert albert.dorring...@lmco.com writes:
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Dorrington, Albert albert.dorring...@lmco.com writes:
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Dorrington,
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Courtney Goeltzenleuchter court...@lunarg.com changed:
What|Removed |Added
Depends on||68690,
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
In the case where I had the 23,328 events in the queue, at least two
dozen kernels has been compiled, and each kernel had been executed 6
times, with different input parameters.
(I would have to back the
FWIW the idea looks good to me. But my python skills are lacking...
Roland
Am 15.04.2014 15:54, schrieb Richard Sandiford:
Ping
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
Ping (with fixed subject)
Richard Sandiford rsand...@linux.vnet.ibm.com writes:
This is a refresh of:
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Courtney Goeltzenleuchter court...@lunarg.com changed:
What|Removed |Added
Depends on||77207
--
Dorrington, Albert albert.dorring...@lmco.com writes:
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
In the case where I had the 23,328 events in the queue, at least two
dozen kernels has been compiled, and each kernel had been executed 6
times, with
What timing, we were just looking at this exact issue - intermittent
glxgears rendering issues when using multisample buffers.
What's the plan for DRM? Seems like it's broken if writing to the buffer
size indicated (bo-size) causes us to clobber other BOs.
Courtney
On Mon, Apr 14, 2014 at 8:54
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Laurent carlier lordhea...@gmail.com changed:
What|Removed |Added
Depends on||76484
--
You are
I would go farther than requiring the returned bo-size to be covered by
backing pages.
There really should be backing pages for every page mapped by
drm_intel_gem_bo_map.
No mapped addresses should be affecting memory outside of an object's
backing pages.
If tiling can result in access to
On Tue, Apr 8, 2014 at 2:54 PM, Ian Romanick i...@freedesktop.org wrote:
On 04/08/2014 02:03 PM, Eric Anholt wrote:
Here's a rework of the series for meta CopyTexSubImage (required for
i965's gen8 support, since we're probably going to avoid doing blorp at
all for it). Ken had almost-reviewed
On Sat, 2014-04-12 at 02:25 +0200, Giovanni Campagna wrote:
Hi everyone,
Some time ago I sent patches to enable the swrast driver on
GBM/DRM, and I did them in the dumbest way possible (that is,
having GBM implement the dri-swrast interface), to make sure
it would work without kernel
On Wed, Feb 12, 2014 at 4:24 PM, m...@lunarg.com wrote:
From: Mike Stroyan m...@lunarg.com
Putting NoDDClr and NoDDChk dependency control on instruction
sequences that include math opcodes can cause corruption of channels.
Treat math opcodes like send opcodes and suppress dependency
https://bugs.freedesktop.org/show_bug.cgi?id=77493
Priority: medium
Bug ID: 77493
CC: bri...@vmware.com, jfons...@vmware.com,
srol...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: lp_test_arit fails with
https://bugs.freedesktop.org/show_bug.cgi?id=77493
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
See Also|
Kenneth Graunke kenn...@whitecape.org writes:
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server. Today we decided that the problem in compositors was
Am 15.04.2014 02:52, schrieb Andreas Hartmetz:
+ /* right shift convert, losing the low bit - must clear
+* high bit because there is no unsigned convert
instruction */
sse2_psrld_imm(p-func, dataXMM, 1);
+ sse2_cvtdq2ps(p-func,
On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt e...@anholt.net wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in
Courtney Goeltzenleuchter court...@lunarg.com writes:
On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt e...@anholt.net wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors
https://bugs.freedesktop.org/show_bug.cgi?id=77500
Priority: medium
Bug ID: 77500
CC: bri...@vmware.com, jfons...@vmware.com,
srol...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe]
Hi,
I've been trying to get piglit working on radeon without X using gbm and
render-nodes, and the problem right now is that the radeon winsys is
trying to use DRM_IOCTL_GEM_OPEN, which is not allowed with render-nodes.
I'm not sure if we need to replace this ioctl with something else or
if the
On 15/04/2014, Tom Stellard wrote :
Hi,
I've been trying to get piglit working on radeon without X using gbm and
render-nodes, and the problem right now is that the radeon winsys is
trying to use DRM_IOCTL_GEM_OPEN, which is not allowed with render-nodes.
Hi,
For render-nodes, you need to
https://bugs.freedesktop.org/show_bug.cgi?id=77502
Priority: medium
Bug ID: 77502
Assignee: mesa-dev@lists.freedesktop.org
Summary: libOpenVG contains no vg Symbols
Severity: major
Classification: Unclassified
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 77207, which changed state.
Bug 77207 Summary: [ivb/hsw] batch overwritten with garbage
https://bugs.freedesktop.org/show_bug.cgi?id=77207
What|Removed |Added
Matt Turner matts...@gmail.com writes:
From: Kenneth Graunke kenn...@whitecape.org
The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.
total instructions in shared programs: 1656292 - 1651898
On Tue, Apr 15, 2014 at 2:16 PM, Eric Anholt e...@anholt.net wrote:
Courtney Goeltzenleuchter court...@lunarg.com writes:
On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt e...@anholt.net wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 04/14/2014 05:33 PM, Eric Anholt wrote:
On 04/15/2014 12:18 PM, Eric Anholt wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server. Today we
On 04/15/2014 10:08 AM, Mike Stroyan wrote:
I would go farther than requiring the returned bo-size to be covered by
backing pages.
There really should be backing pages for every page mapped by
drm_intel_gem_bo_map.
No mapped addresses should be affecting memory outside of an object's
backing
On 04/15/2014 03:50 PM, Kenneth Graunke wrote:
On 04/15/2014 10:08 AM, Mike Stroyan wrote:
I would go farther than requiring the returned bo-size to be covered by
backing pages.
There really should be backing pages for every page mapped by
drm_intel_gem_bo_map.
No mapped addresses should be
Hi folks,
I've been through all of my email backlog to the mesa-stable@ list and
just pushed out a few additional fixes to the 10.1 branch, (perhaps with
a bit less testing than I would normally do before pushing).
I'll give this some additional, real testing and let it sit overnight
for anyone
Alexander von Gluck IV kallis...@unixzen.com writes:
I'd like to get this into the 10.1.x branch as all of the changes are
build fixes to issues present in 10.1.0 (even the pthread change, seems
pthread support is a requirement now as without it Mesa won't build)
Hi Alexander,
I did just pick
bump
On Fri, 2014-04-04 at 22:08 +1100, Timothy Arceri wrote:
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mapi/glapi/tests/check_table.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mapi/glapi/tests/check_table.cpp
b/src/mapi/glapi/tests/check_table.cpp
Timothy Arceri t_arc...@yahoo.com.au writes:
Forgot to CC stable. This should apply to both 10 branches.
Hi Timothy,
The specific patch you were referring to didn't get applied. But a very
similar version did appear later (which I didn't find in my email
archives). See below.
Shall I pick this
https://bugs.freedesktop.org/show_bug.cgi?id=77493
--- Comment #1 from Roland Scheidegger srol...@vmware.com ---
I'm actually not seeing this by default, apparently because we already pass in
+avx if that's available precisely because llvm couldn't handle it on its own
(so setting
From: Roland Scheidegger srol...@vmware.com
Just adjust to the ever-changing API, pass in MCContext when creating the
MCDisassembler.
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 31 +++-
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git
Hi Carl,
In the end I created a new series [1] to fix this issue and at the same
time fix a few other issues such as making ARB_debug_output an alias of
KHR_debug. I didn't send this to stable as I wasn't sure if this change
would be considered to invasive for stable, but it would be good in my
On Wed, Apr 16, 2014 at 03:49:03AM +0200, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Just adjust to the ever-changing API, pass in MCContext when creating the
MCDisassembler.
---
Fixes piglit's fbo-blit-stretch test on drivers which use the meta path.
(i965: should fix Broadwell, but also fixes Sandybridge/Ivybridge/Haswell
since this test falls off the blorp path now due to format conversion)
V2: Use scissor instead of just mangling the rects, to avoid texcoord
rounding
Hi Carl,
After a quite look the new series doesnt apply cleanly to 10.1 as there
have been a number of cleanups in between. I don't think I will get
around to rebasing in time for the stable release but I don't think its
a big deal if this fix doesn't go in.
Tim
On Tue, 2014-04-15 at 17:19
On Wed, Apr 16, 2014 at 3:18 AM, Eric Anholt e...@anholt.net wrote:
Kenneth Graunke kenn...@whitecape.org writes:
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the
On 04/15/2014 05:16 PM, Ian Romanick wrote:
On 04/15/2014 03:50 PM, Kenneth Graunke wrote:
On 04/15/2014 10:08 AM, Mike Stroyan wrote:
I would go farther than requiring the returned bo-size to be covered by
backing pages.
There really should be backing pages for every page mapped by
On 04/15/2014 05:59 PM, Carl Worth wrote:
Hi folks,
I've been through all of my email backlog to the mesa-stable@ list and
just pushed out a few additional fixes to the 10.1 branch, (perhaps with
a bit less testing than I would normally do before pushing).
I'll give this some additional,
On 15.04.2014 19:40, Marek Olšák wrote:
The staging texture should always be idle, so I guess this just skips
the needless GEM_WAIT_IDLE call?
Yes, exactly. Apparently that can incur a significant cost in some cases.
Reviewed-by: Marek Olšák marek.ol...@amd.com
Thank you, pushed.
--
56 matches
Mail list logo
