https://bugs.freedesktop.org/show_bug.cgi?id=82050
Andy Furniss changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #79 from Michel D?nzer ---
(In reply to Andy Furniss from comment #78)
> https://bugs.freedesktop.org/show_bug.cgi?id=84662
I think that should cover Unigine as well.
Is there still an issue with pyrit?
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #78 from Andy Furniss ---
(In reply to Andy Furniss from comment #77)
> Ok, I'm going to open a new bug for this one when I have time to test more.
Bisected to the same kernel commit as this one, but did a new bug -
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #77 from Andy Furniss ---
(In reply to Christoph Haag from comment #76)
> (In reply to Andy Furniss from comment #75)
>
> > It would be useful to know if Elemental also worked with 3.17-rc7.
>
> It's stuttering quite severely, but
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #76 from Christoph Haag ---
(In reply to Andy Furniss from comment #75)
> It would be useful to know if Elemental also worked with 3.17-rc7.
It's stuttering quite severely, but it feels more like "normal" performance
drops and I
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #75 from Andy Furniss ---
(In reply to Christoph Haag from comment #74)
> Well.
>
> I have said that I used drm-next-3.18 and had these hangs.
> When I applied
> http://lists.freedesktop.org/archives/mesa-dev/2014-August/066746.html
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #74 from Christoph Haag ---
Well.
I have said that I used drm-next-3.18 and had these hangs.
When I applied
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066746.html it did
not help.
Now I am using 3.17-rc7 with that
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #73 from Michel D?nzer ---
(In reply to Andy Furniss from comment #67)
> In summary AIUI the fact there is a pause causes a spike because the count
> is from the last frame rendered - which is way longer than normal due to the
>
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #72 from Michel D?nzer ---
(In reply to comment #62)
> I do have 2 gig, but looking at the screenshot of elemantal to be attached I
> see that used and requested differ.
That's probably because of VRAM fragmentation. (BTW, I find it
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #71 from smoki ---
(In reply to comment #70)
> (In reply to comment #69)
> > @Andy
> >
> > Oops didn't notice... Elemental demo makes GPU faults for me, is it the
> > same for you or if you have assertation enabled llvm... there
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #70 from Andy Furniss ---
(In reply to comment #69)
> @Andy
>
> Oops didn't notice... Elemental demo makes GPU faults for me, is it the
> same for you or if you have assertation enabled llvm... there is a bug 82544
> Michel
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #69 from smoki ---
@Andy
Oops didn't notice... Elemental demo makes GPU faults for me, is it the same
for you or if you have assertation enabled llvm... there is a bug 82544 Michel
filled.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #68 from smoki ---
Offtopic... but if someone has sound crackling in those UE4 demos (at least
Elemental and Vehicle, demos i tried) that is probably because openal 1.15 they
shipped, 1.14 an 1.16 works fine for me... Sorry for
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #67 from Andy Furniss ---
(In reply to comment #64)
> It's pretty clear that the stutters correlate with activity in "num bytes
> moved"...
I brought this up earlier and as was explained way the graphing/counting works
may mean
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #66 from smoki ---
I mean kernel 3.16 requested-VRAM is lower, then with 3.17+ kernels :D
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #65 from smoki ---
So is that revert helps
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066746.html Keep in
mind that revert broke 32bit complitely, lot of corruption :)
About performance for UE4 demos i can't say
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #64 from Christoph Haag ---
(In reply to comment #61)
> Note that some of the Unreal Engine 4 demos want to use more than 1G of
> graphics memory (as shown by the GALLIUM_HUD queries requested-VRAM and
> requested-GTT), so if the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #63 from Andy Furniss ---
Created attachment 107183
--> https://bugs.freedesktop.org/attachment.cgi?id=107183=edit
Elemental screen showing vram usage
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #62 from Andy Furniss ---
(In reply to comment #61)
> Note that some of the Unreal Engine 4 demos want to use more than 1G of
> graphics memory (as shown by the GALLIUM_HUD queries requested-VRAM and
> requested-GTT), so if the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #61 from Michel D?nzer ---
Note that some of the Unreal Engine 4 demos want to use more than 1G of
graphics memory (as shown by the GALLIUM_HUD queries requested-VRAM and
requested-GTT), so if the GPU has 'only' 1G of VRAM or less,
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #60 from Andy Furniss ---
(In reply to comment #59)
> (In reply to comment #58)
> > (In reply to comment #57)
> > > I'm trying drm-next-3.18 and mesa git and many unreal engine demos are
> > > still
> > > broken like this:
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #59 from Christoph Haag ---
(In reply to comment #58)
> (In reply to comment #57)
> > I'm trying drm-next-3.18 and mesa git and many unreal engine demos are still
> > broken like this:
> > https://www.youtube.com/watch?v=NvgA9_B0dMo
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #58 from Michel D?nzer ---
(In reply to comment #57)
> I'm trying drm-next-3.18 and mesa git and many unreal engine demos are still
> broken like this:
> https://www.youtube.com/watch?v=NvgA9_B0dMo
Are you sure that's directly
https://bugs.freedesktop.org/show_bug.cgi?id=82050
Christoph Haag changed:
What|Removed |Added
CC||haagch at frickel.club
--- Comment #57
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #56 from Andy Furniss ---
(In reply to comment #55)
> BTW, this could also mean that the pyrit performance regression was simply
> due to LLVM now taking slightly longer to compile a shader.
The llvm commit still reverts cleanly, so
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #55 from Michel D?nzer ---
BTW, this could also mean that the pyrit performance regression was simply due
to LLVM now taking slightly longer to compile a shader.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #54 from Michel D?nzer ---
(In reply to comment #53)
> > Just updated llvm and my perf on pyrit is back to normal -
[...]
> Not llvm it's mesa -
>
> radeonsi: Compile dummy pixel shader on demand
Sounds like pyrit ends up creating
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #53 from Andy Furniss ---
(In reply to comment #52)
> Just updated llvm and my perf on pyrit is back to normal -
>
> Computed 77586.36 PMKs/s total.
> #1: 'OpenCL-Device 'AMD PITCAIRN'': 73865.3 PMKs/s (RTT 0.8)
> #2: 'CPU-Core
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #52 from Andy Furniss ---
Just updated llvm and my perf on pyrit is back to normal -
Computed 77586.36 PMKs/s total.
#1: 'OpenCL-Device 'AMD PITCAIRN'': 73865.3 PMKs/s (RTT 0.8)
#2: 'CPU-Core (SSE2)': 744.3 PMKs/s (RTT 2.9)
#3:
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #51 from Marek Ol??k ---
num-bytes-moved comes from TTM. It's the size of all buffer moves done by TTM.
This usually happens during command submission if VRAM is full.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #50 from Andy Furniss ---
(In reply to comment #49)
> (In reply to comment #48)
> > (In reply to comment #46)
> > What does num-bytes-moved measure - from where to where?
>
> The HUD always displays an average value per frame. It's
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #49 from Marek Ol??k ---
(In reply to comment #48)
> (In reply to comment #46)
> > I've seen some stutters without any corresponding buffer moves though. Still
> > not sure why it's stuttering so bad sometimes.
> >
> > BTW, Andy,
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #48 from Andy Furniss ---
(In reply to comment #46)
> I've seen some stutters without any corresponding buffer moves though. Still
> not sure why it's stuttering so bad sometimes.
>
> BTW, Andy, does the stuttering also seem to get
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #47 from Andy Furniss ---
(In reply to comment #45)
> (In reply to comment #41)
> > (In reply to comment #40)
> > > (In reply to comment #39)
> > > > If you let it run with Basic theme and few rounds you will spot i guess
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #46 from Michel D?nzer ---
I've seen some stutters without any corresponding buffer moves though. Still
not sure why it's stuttering so bad sometimes.
BTW, Andy, does the stuttering also seem to get better for you if you run
Valley
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #45 from smoki ---
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > If you let it run with Basic theme and few rounds you will spot i guess
> > > that only first round there is unusual maybe
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #44 from Andy Furniss ---
Created attachment 105564
--> https://bugs.freedesktop.org/attachment.cgi?id=105564=edit
valley better with revert num bytes moved
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #43 from Andy Furniss ---
Created attachment 105563
--> https://bugs.freedesktop.org/attachment.cgi?id=105563=edit
valley vanilla mesa bad num bytes moved
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #42 from Andy Furniss ---
Playing more with hud I can see that there is a 1 to 1 correlation between the
pauses and spikes in num-bytes-moved. The scale on the graphs did get squashed
a bit by outliers, which seemed a bit random
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #41 from Andy Furniss ---
(In reply to comment #40)
> (In reply to comment #39)
> > If you let it run with Basic theme and few rounds you will spot i guess
> > that only first round there is unusual maybe 2-3 times 1-2 sec
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #40 from smoki ---
(In reply to comment #39)
> If you let it run with Basic theme and few rounds you will spot i guess
> that only first round there is unusual maybe 2-3 times 1-2 sec stutters,
> then second time and later it is
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #39 from smoki ---
(In reply to comment #34)
> I tried on Windows with the same settings and you are right that there are
> stutters. For me they are about 10x shorter than my best Linux case, which
> means that some effectively
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #38 from Andy Furniss ---
(In reply to comment #36)
> Created attachment 105543 [details]
> valley worse pausing with stream buffer change
I notice that I seem to be pegged more to a single core on this one.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #37 from Andy Furniss ---
Created attachment 105544
--> https://bugs.freedesktop.org/attachment.cgi?id=105544=edit
valley better with stream buffer change reverted
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #36 from Andy Furniss ---
Created attachment 105543
--> https://bugs.freedesktop.org/attachment.cgi?id=105543=edit
valley worse pausing with stream buffer change
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #35 from Andy Furniss ---
(In reply to comment #33)
> (In reply to comment #28)
> > > I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for
> > > review, but it's strange: I couldn't notice any significant
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #34 from Andy Furniss ---
(In reply to comment #29)
> I also reported on irc Valley stutter on Kabini, but now i am somhow
> against reverting because performance suffer with reverting in other games.
>
> One other reason simply
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #33 from Michel D?nzer ---
(In reply to comment #28)
> > I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for
> > review, but it's strange: I couldn't notice any significant difference in
> > stutter in Valley
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #32 from Michel D?nzer ---
(In reply to comment #30)
Mathieu, it sounds like your problem isn't related to this report. Please file
your own report, and it would be great if you could bisect Mesa or the kernel.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #31 from smoki ---
(In reply to comment #30)
> Yes.
>
> Minecraft is unplayable with latest Kernel+latest Mesa.
>
> In the beginning, it's smooth.. after 30 sec or so it start to stuter a
> little... By the five minutes mark. if
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #30 from Mathieu Belanger ---
Yes.
Minecraft is unplayable with latest Kernel+latest Mesa.
In the beginning, it's smooth.. after 30 sec or so it start to stuter a
little... By the five minutes mark. if you move in the game, it
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #29 from smoki ---
I also reported on irc Valley stutter on Kabini, but now i am somhow against
reverting because performance suffer with reverting in other games.
One other reason simply because i tested it first time on Windows
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #28 from Andy Furniss ---
(In reply to comment #27)
> (In reply to comment #26)
> > No difference with those.
>
> Bummer, thanks for testing anyway.
>
> I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for
>
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #27 from Michel D?nzer ---
(In reply to comment #26)
> No difference with those.
Bummer, thanks for testing anyway.
I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for review,
but it's strange: I couldn't notice
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #26 from Andy Furniss ---
(In reply to comment #23)
> Created attachment 105318 [details] [review]
> r600g,radeonsi: Inform the kernel if a BO will likely be accessed by the CPU
>
> Does this Mesa patch (instead of the
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #25 from Michel D?nzer ---
(In reply to comment #24)
> Just a general note: We need to define that flag negated for compatibility
> reasons. E.g. RADEON_GEM_NO_CPU_ACCESS because code must assume with an old
> client that the buffer
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #24 from Christian K?nig ---
(In reply to comment #22)
> Created attachment 105317 [details] [review]
> drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
Just a general note: We need to define that flag negated for
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #23 from Michel D?nzer ---
Created attachment 105318
--> https://bugs.freedesktop.org/attachment.cgi?id=105318=edit
r600g,radeonsi: Inform the kernel if a BO will likely be accessed by the CPU
Does this Mesa patch (instead of the
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #22 from Michel D?nzer ---
Created attachment 105317
--> https://bugs.freedesktop.org/attachment.cgi?id=105317=edit
drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #21 from Michel D?nzer ---
Created attachment 105316
--> https://bugs.freedesktop.org/attachment.cgi?id=105316=edit
drm/ttm: move fpfn and lpfn into each placement
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #20 from Andy Furniss ---
(In reply to comment #18)
> Does the pyrit benchmark include compile time when calculating PMKs/s ? The
> patch you've bisected unrolls a loop that makes the pyrit kernel really big,
> so it will take longer
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #19 from Andy Furniss ---
(In reply to comment #17)
> (In reply to comment #14)
> > Yes, with that reverted perf is roughly back to "good" kernel for both.
>
> Can you try restoring the old behaviour for only PIPE_USAGE_DYNAMIC or
>
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #18 from Tom Stellard ---
Does the pyrit benchmark include compile time when calculating PMKs/s ? The
patch you've bisected unrolls a loop that makes the pyrit kernel really big, so
it will take longer to compile.
Is it possible to
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #17 from Michel D?nzer ---
(In reply to comment #14)
> Yes, with that reverted perf is roughly back to "good" kernel for both.
Can you try restoring the old behaviour for only PIPE_USAGE_DYNAMIC or
PIPE_USAGE_STREAM respectively, to
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #16 from Andy Furniss ---
(In reply to comment #15)
> Does pyrit transfer much data from the GPU to the CPU? If so, my patch
> "gallium/radeon: Do not use u_upload_mgr for buffer downloads" that I have
> just sent to the mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #15 from Niels Ole Salscheider
---
Does pyrit transfer much data from the GPU to the CPU? If so, my patch
"gallium/radeon: Do not use u_upload_mgr for buffer downloads" that I have just
sent to the mesa-dev mailing list might
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #14 from Andy Furniss ---
(In reply to comment #13)
> Does reverting Mesa commit 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 help for
> Valley or pyrit with the latest kernel?
Yes, with that reverted perf is roughly back to "good"
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #13 from Michel D?nzer ---
Does reverting Mesa commit 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 help for
Valley or pyrit with the latest kernel?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #12 from Andy Furniss ---
(In reply to comment #11)
> Created attachment 104549 [details]
> Only flush HDP cache for indirect buffers from userspace
>
> Does this patch help?
No, I'm afraid that doesn't help either.
Valley is the
https://bugs.freedesktop.org/show_bug.cgi?id=82050
Michel D?nzer changed:
What|Removed |Added
Attachment #104475|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #10 from Andy Furniss ---
(In reply to comment #9)
> Created attachment 104475 [details] [review]
> Flush HDP cache via the ring on SI
>
> Does this patch help for the kernel regression?
>
> Though this seems to make some piglit
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #9 from Michel D?nzer ---
Created attachment 104475
--> https://bugs.freedesktop.org/attachment.cgi?id=104475=edit
Flush HDP cache via the ring on SI
Does this patch help for the kernel regression?
Though this seems to make some
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #8 from Andy Furniss ---
kernel -
fb240a2534802a86742db51b7334138675bc435e is the first bad commit
commit fb240a2534802a86742db51b7334138675bc435e
Author: Michel D?nzer
Date: Thu Jul 31 18:43:49 2014 +0900
drm/radeon: Always
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #7 from Andy Furniss ---
Created attachment 104083
--> https://bugs.freedesktop.org/attachment.cgi?id=104083=edit
bad
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #6 from Andy Furniss ---
Created attachment 104082
--> https://bugs.freedesktop.org/attachment.cgi?id=104082=edit
good
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #5 from Tom Stellard ---
Can you post the output of R600_DEBUG=cs from both the "good" and "bad"
commits?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #4 from Andy Furniss ---
I bisected LLVM and it came up with -
ph4[llvm]$ git bisect good
ee17bf3fd4189d1981a6e908b4519e600ec7b002 is the first bad commit
commit ee17bf3fd4189d1981a6e908b4519e600ec7b002
Author: Matt Arsenault
Date:
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #3 from Tom Stellard ---
(In reply to comment #2)
> There was a recent change to LLVM which increased conformance with OpenCL
> floating point semantics at some performance cost. That might explain at
> least some of the difference.
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #2 from Michel D?nzer ---
There was a recent change to LLVM which increased conformance with OpenCL
floating point semantics at some performance cost. That might explain at least
some of the difference.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=82050
--- Comment #1 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
80 matches
Mail list logo
