On 05/10/2018 04:45 PM, zhoucm1 wrote:
On 2018年05月10日 13:07, Zhang, Jerry (Junwei) wrote:
On 05/09/2018 02:45 PM, Chunming Zhou wrote:
move implemenation from ttm to amdgpu driver. (suggested by Christian)
per-vm-lru is because of per-vm-bo, which has no chance to refresh lru, the
nagtive eff
On 05/10/2018 04:45 PM, zhoucm1 wrote:
On 2018年05月10日 13:07, Zhang, Jerry (Junwei) wrote:
On 05/09/2018 02:45 PM, Chunming Zhou wrote:
move implemenation from ttm to amdgpu driver. (suggested by Christian)
per-vm-lru is because of per-vm-bo, which has no chance to refresh lru, the
nagtive eff
Hi Dave,
Adding S5PV210 FIMD variant and IPPv2 support.
As for IPPv2, we have applied the use of IPPv2 userspace API
to a real user, which was what other maintainers pointed out.
And it includes two cleanups to MIPI-DSI driver and GEM module.
Please kindly let me know if there is
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #31 from jian-h...@endlessm.com ---
Created attachment 139550
--> https://bugs.freedesktop.org/attachment.cgi?id=139550&action=edit
config of Linux kernel 4.17-rc4
This is the config for building Linux kernel 4.17-rc4 and get the d
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #30 from jian-h...@endlessm.com ---
Created attachment 139549
--> https://bugs.freedesktop.org/attachment.cgi?id=139549&action=edit
config of Linux kernel with freedesktop branch
This is the config for building Linux kernel and get
https://bugs.freedesktop.org/show_bug.cgi?id=105095
--- Comment #2 from Roland Scheidegger ---
FWIW this looks very similar to a bug recently fixed for radv.
Probably not so coincidentally, radeonsi has workarounds for 2/10/10/10 signed
formats, apparently gcn hw before vega (with the exception o
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #201 from heavy...@web.de ---
(In reply to Sandeep from comment #200)
> You can probably ignore the warnings, I get them too and nothing bad has
> happened so far. As long as GPU hang doesn't occur, it's all good.
Thanks for the reply
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #200 from Sandeep ---
You can probably ignore the warnings, I get them too and nothing bad has
happened so far. As long as GPU hang doesn't occur, it's all good.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=91880
heavy...@web.de changed:
What|Removed |Added
Status|REOPENED|NEEDINFO
--- Comment #199 from heavy...
https://bugs.freedesktop.org/show_bug.cgi?id=103246
--- Comment #4 from kmk3.b...@gmail.com ---
(In reply to iive from comment #2)
> I just sow that there is already issue opened for the same/similar issue:
>
> https://github.com/iXit/Mesa-3D/issues/296
Good catch, just commented in there and lin
https://bugs.freedesktop.org/show_bug.cgi?id=103246
kmk3.b...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106289
--- Comment #2 from Dave Coffin ---
I fixed this problem by downgrading libgl1-mesa-dri, libgl1-mesa-glx,
libglapi-mesa, and mesa-vdpau-drivers to version 11.2.0 from the Ubuntu 16.04
.deb files. I could have also used Mesa 17.0.3 from the Ubunt
https://bugs.freedesktop.org/show_bug.cgi?id=106430
--- Comment #1 from mikhail.v.gavri...@gmail.com ---
If do not restart the computer and leave it in a hang state, then after a while
the turbine starts spinning at full speed, and the LEDs on the video card all
go out.
I was even frightened. reb
On Wed, May 9, 2018 at 1:52 PM, Satendra Singh Thakur
wrote:
> On Thu, May 08, 2018 at 16:28:30 +0530, Satendra Singh Thakur wrote:
>> On Thu, May 07, 2018 at 15:46:02 +0200, Daniel Vetter wrote:
>> > On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
>> > > 1.There is a functi
https://bugs.freedesktop.org/show_bug.cgi?id=105083
denisgolo...@yandex.ru changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIX
On Wed, May 09, 2018 at 10:59:27AM +0200, Marek Szyprowski wrote:
> From: Andrzej Pietrasiewicz
>
> There are 3 scaler devices in Exynos5420 SoCs, all are a part of MSCL
> power domain. MSCL power domain and SYSMMU controllers (two per each
> scaler device) have been already added to exynos5420.d
On Wed, May 09, 2018 at 10:59:28AM +0200, Marek Szyprowski wrote:
> From: Andrzej Pietrasiewicz
>
> There are two Scaler devices in Exynos5433 SoCs. Add nodes for them and
> their SYSMMU controllers.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Signed-off-by: Marek Szyprowski
> ---
> arch/arm64
https://bugs.freedesktop.org/show_bug.cgi?id=106500
Bug ID: 106500
Summary: GPU Recovery + DC deadlock
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Prior
https://bugs.freedesktop.org/show_bug.cgi?id=106499
Gregor Münch changed:
What|Removed |Added
CC||mar...@gmail.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=106499
Bug ID: 106499
Summary: [regression, bisected] Several games crash on start
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
As we keep an rbtree of available holes sorted by their size, we can
very easily determine if there is any hole large enough that might
satisfy the allocation request. This helps when dealing with a highly
fragmented address space and a request for a search by address.
To cache the largest size, w
Searching for an available hole by address is slow, as there no
guarantee that a hole will be available and so we must walk over all
nodes in the rbtree before we determine the search was futile. In many
cases, the caller doesn't strictly care for the highest available hole
and was just opportunist
If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.
Signed-off-by: Chris Wilson
Cc: Joo
To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
times), doing a search by address over a pathologically fragmented
address space is exceeding slow. To protect ourselves from nearly
unbounded latency (think searching a million holes while under
struct_mutex), limit the search
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #15 from Roc Vallès Domènech ---
I'm seeing this on a Vega64.
kernel 4.16.7-rt1
mesa 18.0.3
xf86-video-amdgpu 18.0.1
chromium 66.0.3359.170
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, 09 May 2018 15:18:52 +0200,
Mauro Carvalho Chehab wrote:
>
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is valid, removing a few
> false-p
https://bugs.freedesktop.org/show_bug.cgi?id=99403
Roman Elshin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=91808
Roman Elshin changed:
What|Removed |Added
CC||roman.els...@gmail.com
--- Comment #17 fr
28 matches
Mail list logo
