From: Michel Dänzer
For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle geometry shaders yet,
but that's just the tip of the iceberg.
So building Mesa with --enable-r600-llvm-compiler is currently not
recommended for anyone w
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
Thank you, pushed.
--
Earthling Michel Dänz
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 additi
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
On Wed, Apr 16, 2014 at 3:18 AM, Eric Anholt wrote:
> Kenneth Graunke 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 dec
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 -07
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 p
On Wed, Apr 16, 2014 at 03:49:03AM +0200, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
Reviewed-by: Tom Stellard
> Just adjust to the ever-changing API, pass in MCContext when creating the
> MCDisassembler.
> ---
> src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 31
> ++
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
op
From: Roland Scheidegger
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 a/src/gallium/auxiliary/gallivm/lp_
https://bugs.freedesktop.org/show_bug.cgi?id=77493
--- Comment #1 from Roland Scheidegger ---
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 LP_NATIVE_VECTOR_WIDTH=128 causes
Timothy Arceri 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 over to both the 10.
bump
On Fri, 2014-04-04 at 22:08 +1100, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
> ---
> 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
> index 89d907
Alexander von Gluck IV 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 this over to the 1
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 e
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
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
> b
On 04/15/2014 12:18 PM, Eric Anholt wrote:
> Kenneth Graunke 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
On Tue, Apr 15, 2014 at 2:16 PM, Eric Anholt wrote:
> Courtney Goeltzenleuchter writes:
>
> > On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt wrote:
> >
> >> Kenneth Graunke writes:
> >>
> >> > On 04/14/2014 05:33 PM, Eric Anholt wrote:
> >> >> This manifested as rendering failures or sometimes G
Matt Turner writes:
> From: Kenneth Graunke
>
> 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 (-0.27%)
> instructions in affecte
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
--
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 (All)
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 us
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 p
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]
Courtney Goeltzenleuchter writes:
> On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt wrote:
>
>> Kenneth Graunke 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
On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt wrote:
> Kenneth Graunke 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
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);
>>>
>>> + sse
Kenneth Graunke 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 equivalent
>> to a
https://bugs.freedesktop.org/show_bug.cgi?id=77493
Vinson Lee changed:
What|Removed |Added
See Also||http://llvm.org/bugs/show_b
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
On Wed, Feb 12, 2014 at 4:24 PM, wrote:
> From: Mike Stroyan
>
> 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 hinting.
>
> Signed-off-by: Mike
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 s
On Tue, Apr 8, 2014 at 2:54 PM, Ian Romanick 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 a previous ve
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 unalloc
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Laurent carlier changed:
What|Removed |Added
Depends on||76484
--
You are receiving this mail
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
"Dorrington, Albert" 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 different input par
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Courtney Goeltzenleuchter changed:
What|Removed |Added
Depends on||77207
--
You are receiving
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 writes:
>> Ping (with fixed subject)
>>
>> Richard Sandiford writes:
>>> This is a refresh of:
>>>
>>>
>>> https://urldefense.proofpoint.c
> -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
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Courtney Goeltzenleuchter changed:
What|Removed |Added
Depends on||68690, 74700, 76749
--
You
"Dorrington, Albert" writes:
>> -Original Message-
>> From: Francisco Jerez [mailto:curroje...@riseup.net]
>>
>> "Dorrington, Albert" writes:
>>
>> >> -Original Message-
>> >> From: Francisco Jerez [mailto:curroje...@riseup.net]
>> > > "Dorrington, Albert" writes:
>> >> >
>>
Ping
Richard Sandiford writes:
> Ping (with fixed subject)
>
> Richard Sandiford 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 decide whether
>> u_format_table.c should be f
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
>
> "Dorrington, Albert" writes:
>
> >> -Original Message-
> >> From: Francisco Jerez [mailto:curroje...@riseup.net]
> > > "Dorrington, Albert" writes:
> >> >
> >> > From reading the OpenCL spec (and pe
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);
>>>
>>> + sse
"Dorrington, Albert" writes:
>> -Original Message-
>> From: Francisco Jerez [mailto:curroje...@riseup.net]
> > "Dorrington, Albert" writes:
>> >
>> > From reading the OpenCL spec (and perhaps I'm misinterpreting something
>> again), section 5.10 Flush and Finish says:
>> >
>> >Any b
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
> "Dorrington, Albert" 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 a command-qu
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 n
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
On Tue, Apr 15, 2014 at 7:46 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The transfer staging texture is always freshly allocated, so for write-only
> t
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 a/src/glsl/opt_if_simplificatio
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 af
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 refacto
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
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
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
var
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.
>
> The
56 matches
Mail list logo
