https://bugs.freedesktop.org/show_bug.cgi?id=110781
Michel Dänzer changed:
What|Removed |Added
CC||linuxhi...@gmail.com
--- Comment #69
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Marek Olšák changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #67 from Rui Salvaterra ---
(In reply to Richard Thier from comment #66)
> Is there any indicator to look for? Like shader files on disk at some places
> or near the runned binary or current dir or whatever with this or that name?
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #66 from Richard Thier ---
> Yes, I think it's a good idea to open a new bug.
Added seperate bug for working on HyperZ glitches:
https://bugs.freedesktop.org/show_bug.cgi?id=110897
> By the way, I have a vague memory of HiZ on
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #65 from Rui Salvaterra ---
(In reply to Richard Thier from comment #64)
> Rui!
>
> Btw I am also running your patch already too and did not see much problems
> so far, but many of the stuff I am running was DX7 and DX8 level in
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #64 from Richard Thier ---
Rui!
Btw I am also running your patch already too and did not see much problems so
far, but many of the stuff I am running was DX7 and DX8 level in graphics
settings so I do not know how many times I
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #63 from Rui Salvaterra ---
(In reply to Richard Thier from comment #62)
> Added a blog post about the whole issue and its solving process here:
>
> http://ballmerpeak.web.elte.hu/devblog/debugging-mesa-and-the-linux-3d-
>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #62 from Richard Thier ---
Added a blog post about the whole issue and its solving process here:
http://ballmerpeak.web.elte.hu/devblog/debugging-mesa-and-the-linux-3d-graphics-stack.html
I have linked to this bug report and every
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #61 from Richard Thier ---
I still get some slowdown when playing Mount: Warband which worked
before, but there is some chances it is something else or not even in mesa.
On my last system I was playing it with wine 1.8 and now with
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Richard Thier changed:
What|Removed |Added
Attachment #144454|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #59 from Marek Olšák ---
Richard, your change for create_fence is correct.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #58 from Richard Thier ---
The output from gdb glxgears on the segfault:
#0 0xb75a8892 in radeon_winsys_bo_create (rws=0x45e100, size=4096,
alignment=4096, domain=RADEON_DOMAIN_GTT, flags=(unknown: 0))
at radeon_drm_bo.c:993
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #57 from Richard Thier ---
Hello everyone!
I have found one more place where we can end up calling extra ioctls for
GEM_CREATE. I remember telling you above after the very first proposed patch of
Marek, that "Interesting to me is
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #56 from Rui Salvaterra ---
And speaking of performance, I wonder if this will have any effect… I'll try it
later.
https://git.congatec.com/android/qmx6_kernel/commit/a0a53aa8c7b491a43e2ef66786f9511bae8cbc35
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #55 from Alex Deucher ---
Performance will be better because the 3D engine is rendering to a smaller
surface (e.g., 640x480) regardless of whether you are fullscreen or windowed.
The size of the rendered image is what impact 3D
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #54 from Richard Thier ---
> The GPU has a scaler that can scale a smaller image to the native timing.
> Many > LCD monitors also have a scaler built in to provide the same
> functionality.
I see, but still I see a big
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #53 from Rui Salvaterra ---
(In reply to Richard Thier from comment #49)
> I don't get it. Is there no supported resolution below that big one? That is
> quite hard to believe. Mine is 1024x768 when maxed, but sometimes I reverse
>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #52 from Alex Deucher ---
(In reply to Richard Thier from comment #51)
> > I do have an old 1024x768 monitor with VGA input,
> > I might give it a spin this weekend.
>
> But didn't the LCD also supports smaler resolutions natively?
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #51 from Richard Thier ---
> I do have an old 1024x768 monitor with VGA input,
> I might give it a spin this weekend.
But didn't the LCD also supports smaler resolutions natively? Most of them do
even if their best native is more
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #50 from Rui Salvaterra ---
(In reply to Richard Thier from comment #49)
> I don't get it. Is there no supported resolution below that big one? That is
> quite hard to believe. Mine is 1024x768 when maxed, but sometimes I reverse
>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #49 from Richard Thier ---
> as if the Xpress 200M wasn't slow enough, the screen has
> a resolution of > 1680x1050 when the typical resolution,
> at the time, was 1280x800.
I don't get it. Is there no supported resolution below
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #48 from Rui Salvaterra ---
(In reply to Rui Salvaterra from comment #43)
> Compiz feels much snappier, indeed.
To be 100 % honest, the difference is noticeable, but my laptop has one big
problem: as if the Xpress 200M wasn't slow
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #47 from Rui Salvaterra ---
(In reply to Marek Olšák from comment #45)
> Yeah that looks good.
Great! In that case, I'm going to do a proper version and send it. I don't like
the fact that I'm doing
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #46 from Richard Thier ---
In comparison this is the unpatched 19.x originally (10 sec):
-> 12466 (any) ioctl calls
-> 3111 DRM_IOCTL_RADEON_GEM_CREATE
-> 3112 DRM_IOCTL_GEM_CLOSE
^^Sorry these values were bad, it is not this much
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #45 from Marek Olšák ---
Yeah that looks good.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #44 from Rui Salvaterra ---
Created attachment 144469
--> https://bugs.freedesktop.org/attachment.cgi?id=144469=edit
r300g: implement glsl shader caching.
And here's a preliminary patch. If it looks good enough to you, I'll send
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #43 from Rui Salvaterra ---
Hi, everyone!
I finally did it, I was able to point the envvars in the right direction,
tested Marek's patch and it seems to be working nicely. Compiz feels much
snappier, indeed. Feel free to add,
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #42 from Andrew Randrianasulu ---
(In reply to Rui Salvaterra from comment #41)
> Hi, guys
>
> I haven't tried Marek's solution yet. It's the first time I build Mesa from
> scratch and I've never used Meson before, so I'm studying
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #41 from Rui Salvaterra ---
Hi, guys
I haven't tried Marek's solution yet. It's the first time I build Mesa from
scratch and I've never used Meson before, so I'm studying along the way. I
applied the patch, configured with no DRI
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #40 from Richard Thier ---
Okay... I cannot easily test more heavy games because some of them crash with
the 17.x last good one (maybe because missing external S3TC or whatever, or
just something similar).
Will try to bisect the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #39 from Richard Thier ---
First I went on to strace a bit and measure directly...
10 sec glxgears - lastfast 17.x:
- 2105 ioctl calls
- 6 DRM_IOCTL_RADEON_GEM_CREATE
- 7 DRM_IOCTL_GEM_CLOSE
10 sec glxgears - patched 19.x:
-
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #38 from Richard Thier ---
Hello everyone!
While hopefully someone is testing Marek's solution as I went to test if the
"minor problem" between 04ea03d99d8 and 19.x is causing a slowdown or not.
Despite most of the heavy slowdown
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #37 from Rui Salvaterra ---
(In reply to Marek Olšák from comment #36)
> I think if you just implement the disk cache callback, it'll automatically
> enable the shader cache for the GLSL compiler.
Hi, Marek
Yeah, that was my
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #36 from Marek Olšák ---
I think if you just implement the disk cache callback, it'll automatically
enable the shader cache for the GLSL compiler.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #35 from Rui Salvaterra ---
(In reply to Marek Olšák from comment #34)
> Created attachment 144454 [details] [review]
> possible fix v2
>
> Please test this one.
Hi, Marek,
Unfortunately I couldn't do it yesterday, but I'll try
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Marek Olšák changed:
What|Removed |Added
Attachment #144431|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #33 from Richard Thier ---
I have compiled a "how to build" just for you - linking sources I used:
http://ballmerpeak.web.elte.hu/devblog/building-your-own-mesa.html
Everyone should be able to try the quickfix using this and the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #32 from Rui Salvaterra ---
(In reply to Richard Thier from comment #28)
> Hi Rui!
Hi, Richard!
> We should also thank Marek for him proposing a possible fix.
Yeah, Marek kicks ass, he's one of the original developers of r300g.
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #31 from Richard Thier ---
While bisecting the original issue I saw a point where speed was already bad,
but not that much as with latest however mostly like that (at least 90-95%).
So there might be a little bit more speedup gain
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #30 from Richard Thier ---
Interesting to me is that the CREATE call number is still higher in strace
output than how it was originally before the first slowdown, but the
performance seems to be the same after applying the quickfix
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Richard Thier changed:
What|Removed |Added
Attachment #144439|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #28 from Richard Thier ---
Hi Rui!
We should also thank Marek for him proposing a possible fix. I am currently
creating a "less hacky" solution based on that attachment and a better idea to
not always force VRAM domain, but only if
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #27 from Rui Salvaterra ---
This is amazing work, Richard. I'd love to help you with testing, since I also
have the same hardware, but unfortunately I don't have a build environment
ready. I'm using padoka's PPA, though. FWIW, I'll
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Richard Thier changed:
What|Removed |Added
Attachment #144427|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #25 from Richard Thier ---
In the assert problem this is the domain and flag meanings in case of only my
hack is in place:
domain(6) == RADEON_DOMAIN_GTT(2) | RADEON_DOMAIN_VRAM(4)
flags(1) == RADEON_FLAG_GTT_WC (1 << 0)
So I get
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #24 from Richard Thier ---
Sorry! I have to add that the above printf only prints as such if I use my
hacky patch on latest git! I will try what it says with the "proposed fix"
patch of Marek as the body of radeon_get_heap_index
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #23 from Richard Thier ---
I have added this before the assert:
fprintf(stderr, "radeon_get_heap_index(%u, %u): %d", domain, flags, heap);
And I see this logged out before the assertion fail:
radeon_get_heap_index(6, 1): -1
Will
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #22 from Richard Thier ---
I also get the same error if I apply my simple hack of use_reusable_pool=true;
Applying the changes to the revision where things went wrong in the past seem
to be working though (but I did not test them
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #21 from Richard Thier ---
Hi!
I have applied this "possible fix" patch to the (nearly) latest 19.x from git
and I get an assertion error there.
glxinfo: ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:1023:
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #20 from Marek Olšák ---
GEM_CREATE just creates a buffer, you should always see them, but a lot less.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #19 from Richard Thier ---
Hmmm... I have tried the possible fix and Extreme Tux Racer became fast again
however I still see a lot of "DRM_IOCTL_RADEON_GEM_CREATE" if I do an
strace -T -e ioctl glxgears 2>&1 | vim -
So things are
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #18 from Richard Thier ---
Will try that supposed patch as soon as possible. It seems reasonable to me as
far as I understand it. So you basically set the flag for r300. I was searching
a lot to see where to add these, but I was too
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #17 from Marek Olšák ---
Created attachment 144431
--> https://bugs.freedesktop.org/attachment.cgi?id=144431=edit
possible fix
Hey fellas, can you test this patch? Thanks.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #16 from Richard Thier ---
Created attachment 144427
--> https://bugs.freedesktop.org/attachment.cgi?id=144427=edit
Simple diff/patch to test the issue
See attached diff/patch for what I am trying as a quickfix and testing what
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #15 from Richard Thier ---
It seems similar issues not only affect me then...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #14 from Richard Thier ---
Now seeing that the commit diff is actually small, I can put some printf logs
in place to see what is going on and where the code ends up.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #13 from Rui Salvaterra ---
This is interesting. I have the exact same problem on an old Turion X2 laptop
I've been given. I attributed it to memory controller contention (since the GPU
resides in the northbridge and the memory
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #12 from Richard Thier ---
My friend "Googling" at the commit hash we found that my problem might possibly
relate to this other bug report already existing:
https://bugs.freedesktop.org/show_bug.cgi?id=105171
They also report a
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #11 from Richard Thier ---
Slowdown cause is found when bisecting:
8b3a257851905ff444d981e52938cbf2b36ba830 is the first bad commit
commit 8b3a257851905ff444d981e52938cbf2b36ba830
Author: Marek Olšák
Date: Tue Jul 18 16:08:44
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #10 from Richard Thier ---
I am getting really close to bisecting the bigger identified problem.
bad: b672c3833b7
good: aff1ad0798
Now at this point:
Bisecting: 9 revisions left to test after this (roughly 3 steps)
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #9 from Richard Thier ---
The problem is now surely been between cf2e92262b4 (good) and 04ea03d99d8 (bad)
now. Still there are a number of some bisects still to do.
Also there is a chance there is a minor issue on the other side of
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #8 from Richard Thier ---
I became a bit uncertain now as after every bisect I am choosing "git
bisect bad" and see no change so far. There is 4 more bisect to do
still, but I expected at least one change so far.
Maybe it is in
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #7 from Richard Thier ---
Latest bisect result so far:
Fast mesa version: 17.2.8 (2017 december 22)
Slow mesa version: 18.0.0 (git: 44c7d1aa2ea)
The change that slows the system is between the two.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #6 from Richard Thier ---
Latest bisect result so far:
Fast mesa version: 17.2.8 (2017 december 22)
Slow mesa version: 18.0.5 (2018 june 3)
The change that slows the system is between the two. The strace outputs are
generally the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #5 from Richard Thier ---
Still fast with mesa 17.2.8 and X.Org X Server 1.19.5
The problem is somewhere between 17.x and 19.x mesa versions (and corresponding
xorg).
Also I have made an strace when it is good in one older system
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Richard Thier changed:
What|Removed |Added
Severity|normal |major
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #4 from Richard Thier ---
Btw what is a "slab buffer" or "slab"? It bugs me and I see this everywhere in
the code too...
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #3 from Richard Thier ---
When doing an strace this is what I am getting:
...
ioctl(6, DRM_IOCTL_RADEON_GEM_CREATE, 0xbfafd880) = 0 <0.68>
> [vdso]() [0x891]
ioctl(6, DRM_IOCTL_RADEON_CS, 0xafe2404c) = 0 <0.000102>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #2 from Richard Thier ---
The "gallium/winsys/radeon/drm/radeon_drm_bo.c" is indeed used by r300 because
I have put a log in it.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #1 from Richard Thier ---
PS.: As you can see I already have the mesa sources and can build and test my
own in case there is any kind of idea what I should search for...
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Bug ID: 110781
Summary: Radeon: heavy r300 performance drop regression between
11.x and 19.x
Product: Mesa
Version: git
Hardware: x86 (IA32)
OS: Linux
71 matches
Mail list logo
