Any reason why these patches are not applied in current GIT other than
lack of review? I was kind of hoping that maybe some of them can
impact Dota 2 perf, since it seems that Dota 2 is memory bandwidth
limited.
On Thu, Feb 27, 2014 at 11:53 PM, Eric Anholt wrote:
> On LLC, it should always be be
On Wed, Oct 30, 2013 at 2:43 PM, Paul Berry wrote:
> - What percentage of clears are affected by this patch? Even with this
> patch, some clears still won't take the fast path (e.g. stencil clears, MSAA
> color clears, and scissored clears).
>
When I was doing my Wine tweaks for the Windows Dot
On Tue, Sep 3, 2013 at 9:19 PM, Ville Syrjälä
wrote:
> On Thu, Aug 15, 2013 at 10:39:31PM +0200, Vedran Rodic wrote:
>> > We do have the set_caching ioctl. It's enough to flip the PTEs to UC and
>> > let MOCS manage things. I actually did a few experiments on my I
> We do have the set_caching ioctl. It's enough to flip the PTEs to UC and
> let MOCS manage things. I actually did a few experiments on my IVB. I
> made all Mesa's buffers UC via PTEs by patching libdrm to change the
> cache mode of each bo after allocation. Then I fiddled with the MOCS
> LLC bits
On Mon, Aug 12, 2013 at 3:07 PM, wrote:
> From: Ville Syrjälä
>
> IVB/BYT also has the same L3 cacheability control in MOCS as HSW,
> so let's make use of it.
According to the discussion we had on #intel-gfx a few weeks ago, on
IVB all Mesa memory is already marked as cached in DRM allocated PT
On Tue, Aug 13, 2013 at 7:19 PM, Kenneth Graunke wrote:
>
>
> As far as I know, --enable-glx-tls just makes things more efficient.
>
> Nothing should *rely* on it, or even be able to detect it...
Dota 2 crashes without that option when loading the actual game map. I
assumed it adds thread safety.
Hi,
I've been burned with the issue of GLX TLS not being enabled by
default in Mesa (Dota 2 seems to rely on it).
What's the rationale of not enabling it by default?
Thanks,
Vedran Rodic
___
mesa-dev mailing list
mesa-dev@lists.freedeskto
Sorry, please ignore me, sending fake patches through gmail is not my
a thing. :) But please apply the fix from Chris.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Can we pretend this came from Chris so it can be applied sooner rather
than later ? :)
Include src0 alpha in the RT write message when using MRT, so it is used
for the alpha test instead of the normal per-RT alpha value.
No Piglit regressions on Ivybridge.
V2: reuse (and simplify) existing sampl
Yes, it is fixed now. I had to revert the proposed patch from
beginning of this thread too.
Thank you,
Vedran
On Tue, Jun 11, 2013 at 7:54 PM, Kenneth Graunke wrote:
> On 06/10/2013 10:55 PM, Vedran Rodic wrote:
>>
>> On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Gr
xgears for this issue for example).
On Tue, Jun 11, 2013 at 7:55 AM, Vedran Rodic wrote:
> On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke
> wrote:
>>
>> Vedran,
>>
>> Can you try this patch and see if it solves your GPU hang issues? I still
>> haven't
On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke wrote:
>
> Vedran,
>
> Can you try this patch and see if it solves your GPU hang issues? I still
> haven't been able to reproduce it, but I believe I may just be getting lucky.
>
Nope, with this one it's even worse.
Before after the initial hang
> And just any old GL application hangs it? Nothing specific?
>
Yes, i tried some glretraces, shader toy in chrome (webgl). Hangs on both.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> This is my CPU:
>> vendor_id : GenuineIntel
>> cpu family : 6
>> model : 58
>> model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
>> stepping : 9
>> microcode : 0x12
>
>
> Yikes. I definitely tested this on my HD 4000. What kernel are you using
> (uname -a)?
Linux 3.9.4
___
Hi,
This patch makes my Ivy Bridge hang when starting an OpenGL application:
[ 30.835248] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 30.835255] [drm] capturing error event; look for more information
in/sys/kernel...
This is my CPU:
vendor_id : GenuineIntel
cpu fa
listed too) :)
On Sat, May 4, 2013 at 4:15 PM, Vedran Rodic wrote:
> Hi,
>
> I bisected a performance regression here:
> https://bugs.freedesktop.org/show_bug.cgi?id=64213
>
> Here's some benchmark numbers:
>
> Core i5-3320M, Firefox 23 nightly build 2013-05-04
>
Hi,
I bisected a performance regression here:
https://bugs.freedesktop.org/show_bug.cgi?id=64213
Here's some benchmark numbers:
Core i5-3320M, Firefox 23 nightly build 2013-05-04
Epic Citadel 1920x1080 (browser window maximized, not game screen)
Windows 40.5 FPS
Linux mesa git: 18.9 FPS 2013-
17 matches
Mail list logo
