https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #14 from Michel Dänzer ---
(In reply to Thomas Hellström from comment #12)
> It would also be good to try to rule out server side radeon dri3 problems.
> Perhaps by running it on nouveau or intel...
Or simply the modesetting Xorg dr
On some (Bay Trail) devices the LCD panel is mounted upside-down.
This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Syrjala's
"drm/fb-helper: Inherit rotation wip" patch and when re-using the
initial fb it stores that in intel_c
Bhumika,
> Make these const as they are only stored in the type field of a device
> structure, which is const.
Applied to 4.14/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
___
dri-devel mailing list
dri-devel@lists.freedesk
Hi All,
When I last send this patch not everyone was enthusiastic about this
patch. As already mentioned in the v2 discussion, solving this in userspace
is not really feasible since there is no single place to fix it there, it
will need fixing in at least 6 different places from the top of my head
On Fri, Aug 25, 2017 at 8:10 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Fri, Aug 18, 2017 at 11:34:40AM -0700, Jason Ekstrand wrote:
> > This updates the documentation on the intel CCS modifiers for a couple
> > of reasons:
> >
> > 1) The old documentation required that the CC
Sorry for the mobile email client, but:
Reviewed-by: Daniel Stone
> On 25 Aug 2017, at 9:16 pm, Rodrigo Vivi wrote:
>
> This Fixes build on branches where we already have format-modifier.
>
> Reference:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/151044.html
> Fixes: e6fc3b
This Fixes build on branches where we already have format-modifier.
Reference:
https://lists.freedesktop.org/archives/dri-devel/2017-August/151044.html
Fixes: e6fc3b68558e ("drm: Plumb modifiers through plane init")
Cc: Linus Walleij
Cc: Janet Morgan
Cc: Ben Widawsky
Cc: Daniel Stone (v2)
Cc:
https://bugzilla.kernel.org/show_bug.cgi?id=196337
--- Comment #4 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
I've added pg_mask=0xFFFE as suggested by Tom St Denis at
https://lists.freedesktop.org/archives/amd-gfx/2017-August/012329.html
This works for me, so I don't need to modif
https://bugs.freedesktop.org/show_bug.cgi?id=102414
--- Comment #4 from Harry Wentland ---
Created attachment 133786
--> https://bugs.freedesktop.org/attachment.cgi?id=133786&action=edit
Patch for suspend/resume issues
Hopefully this helps with the suspend/resume issues.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=102414
--- Comment #3 from Vadim Girlin ---
Created attachment 133785
--> https://bugs.freedesktop.org/attachment.cgi?id=133785&action=edit
dmesg right after boot
There is a lot of noise, so initial stuff is missing anyway.
Please let me know if you
https://bugs.freedesktop.org/show_bug.cgi?id=102414
--- Comment #2 from Vadim Girlin ---
Created attachment 133784
--> https://bugs.freedesktop.org/attachment.cgi?id=133784&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=102414
--- Comment #1 from Vadim Girlin ---
Created attachment 133783
--> https://bugs.freedesktop.org/attachment.cgi?id=133783&action=edit
lspci
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=102414
Bug ID: 102414
Summary: Hawaii gpu (R9 290) and the troubles with the
amd-staging-drm-next branch
Product: Mesa
Version: unspecified
Hardware: Other
OS: Al
This IOCTL provides a mechanism for userspace to trigger a sync object
directly. There are other ways that userspace can trigger a syncobj
such as submitting a dummy batch somewhere or hanging on to a triggered
sync_file and doing an import. This just provides an easy way to
manually trigger the
This just resets the dma_fence to NULL so it looks like it's never been
signaled. This will be useful once we add the new wait API for allowing
wait on "submit and signal" behavior.
v2:
- Take an array of sync objects (Dave Airlie)
Signed-off-by: Jason Ekstrand
Reviewed-by: Christian König (v
This requests that the driver create the sync object such that it
already has a signaled dma_fence attached. Because we don't need
anything in particular (just something signaled), we use a dummy null
fence. This is useful for Vulkan which has a similar flag that can be
passed to vkCreateFence.
It is useful in certain circumstances to know when the fence is replaced
in a syncobj. Specifically, it may be useful to know when the fence
goes from NULL to something valid. This does make syncobj_replace_fence
a little more expensive because it has to take a lock but, in the common
case where
From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute
Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted. This is
perfectly safe because the CPU wait has a timeout which will get
triggered eventually if no work is ever submitted. This behavior is
advantageous for multi-th
The wait ioctl has a bunch of code to read an syncobj handle array from
userspace and turn it into an array of syncobj pointers. We're about to
add two new IOCTLs which will need to work with arrays of syncobj
handles so let's make some helpers.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm
The function has far more in common with drm_syncobj_find than with
any in the get/put functions.
Signed-off-by: Jason Ekstrand
Acked-by: Christian König (v1)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 10 +-
include/drm/drm_syncobj.h
The atomic exchange operation in drm_syncobj_replace_fence is sufficient
for the case where it races with itself. However, if you have a race
between a replace_fence and dma_fence_get(syncobj->fence), you may end
up with the entire replace_fence happening between the point in time
where the one th
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3d74f3a..4c20162 100644
--- a/drivers/gpu/drm/i915/i91
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #13 from har...@gmx.de ---
Ok, that makes sense for me, thank you :)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.fre
https://bugzilla.kernel.org/show_bug.cgi?id=196771
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
The only call of wait_for_engine() is wrapped in a GEM_WARN_ON macro,
which confusingly suppresses the call unless CONFIG_DRM_I915_DEBUG_GEM
is set.
According to http://www.spinics.net/lists/intel-gfx/msg128768.html the
current behavior is correct, even though it's not obvious. Different
solutions
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #12 from Thomas Hellström ---
(In reply to haro41 from comment #11)
> i applied your patch successful, still the freezes, maybe in average a bit
> later now.
>
> The behavoir changed a bit:
>
> before patch:
>
> vblank_mode=2 (def
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #11 from har...@gmx.de ---
i applied your patch successful, still the freezes, maybe in average a bit
later now.
The behavoir changed a bit:
before patch:
vblank_mode=2 (default)-> always freezes inside 0..2 minutes runtime,
https://bugzilla.kernel.org/show_bug.cgi?id=196773
Bug ID: 196773
Summary: System hangs with nouveau 'trapped write' error
(GeForce 9600 GT, [10de:0622])
Product: Drivers
Version: 2.5
Kernel Version: 4.13.0-0.rc5.git2.1.fc27.x86_
On Fri, Aug 18, 2017 at 11:34:40AM -0700, Jason Ekstrand wrote:
> This updates the documentation on the intel CCS modifiers for a couple
> of reasons:
>
> 1) The old documentation required that the CCS modifier only be used
> with formats. While i915 currently only supports CCS scanout
https://bugs.freedesktop.org/show_bug.cgi?id=101483
--- Comment #5 from FFAB ---
Created attachment 133777
--> https://bugs.freedesktop.org/attachment.cgi?id=133777&action=edit
kernel parameter iommu=soft
Upstream kernel test - kernel 4.13-rc6
Installation, on which upstream kernel was inst
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #10 from Thomas Hellström ---
(In reply to haro41 from comment #8)
> @Thomas,
>
> i got two rejects when trying to apply the patch.
>
> Let me sync to your base version first, to avoid additional diffs,
> where/when did you branch
https://bugs.freedesktop.org/show_bug.cgi?id=102358
Thomas Hellström changed:
What|Removed |Added
Attachment #133771|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=101483
--- Comment #4 from FFAB ---
Created attachment 133775
--> https://bugs.freedesktop.org/attachment.cgi?id=133775&action=edit
no workaround parameter
no workaround parameter
--
You are receiving this mail because:
You are the assignee for th
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--- Comment #12 from Alex Deucher (alexdeuc...@gmail.com) ---
I sent the patch to Greg last week.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing
https://bugzilla.kernel.org/show_bug.cgi?id=196771
--- Comment #2 from Rokas Kupstys (rokups+kernel-b...@zoho.com) ---
Created attachment 258107
--> https://bugzilla.kernel.org/attachment.cgi?id=258107&action=edit
What it looks like (console text)
--
You are receiving this mail because:
You ar
https://bugzilla.kernel.org/show_bug.cgi?id=196771
--- Comment #1 from Rokas Kupstys (rokups+kernel-b...@zoho.com) ---
Created attachment 258105
--> https://bugzilla.kernel.org/attachment.cgi?id=258105&action=edit
What it looks like
Colors on 1440p are fine, they look weird due to me using phon
https://bugzilla.kernel.org/show_bug.cgi?id=196771
Bug ID: 196771
Summary: [AMDGPU] Scrambled video output during boot on WQHD
monitor
Product: Drivers
Version: 2.5
Kernel Version: 4.12
Hardware: x86-64
From: Daniel Drake
As discussed in
http://www.spinics.net/lists/linux-samsung-soc/msg24617.html
the 1024x768 timings don't quite work out of the box, for unknown reasons.
However, massaging of the values in the way implemented in this patch
makes the system usable, although it is missing the top
Hello,
I was asked by a user of my kernel tree to try to upstream this. The patch is
originally by Daniel who figured out this peculiar behaviour of the HDMI block.
Since this is clearly a hack, should it even be upstreamed?
Some more questions/thoughts:
- I know that it works for the HDMI bloc
This results in a nice cleanup, and fixes link errors when fbdev support
is disabled.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_fb.c | 150 +++-
1 file changed, 9 insertions(+), 141 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_fb
On Thu, Aug 24, 2017 at 10:10:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we only check that the plane supports the pixel format of the
> fb we're about to feed to it. Extend it to check also the modifier, and
> more specifically that the combination of th
On Thu, Aug 24, 2017 at 10:10:58PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The member is called 'modifiers_property' instead of 'modifiers'. Adjust
> the kernel docs to match.
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Cc: Da
On Sat, Aug 19, 2017 at 01:52:13PM +0530, Bhumika Goyal wrote:
> Make these const as they are only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
I can't apply this, it's missing your s-o-b line. You can just replay with
that.
Thanks, Daniel
> ---
> d
On Thu, Aug 24, 2017 at 11:04:01AM +0100, Brian Starkey wrote:
> Hi,
>
> Thanks for the CC.
>
> On Fri, Aug 18, 2017 at 06:13:14PM +0200, Noralf Tr??nnes wrote:
> > (cc affected parties)
> >
> >
> > Den 18.08.2017 09.46, skrev Daniel Vetter:
> > > On Thu, Aug 17, 2017 at 06:21:30PM +0200, Noral
Inki Dae wrote:
> Hi Tobias,
>
> Regarding below two patches, I'd like to have more review so I will consider
> to merge them in next turn. Sorry for this.
Thanks, calling out to potential reviewers then :-)
- Tobias
> drm/exynos: introduce BYTE_PITCH capability
> drm/exynos: add BYTE_PITC
On Wed, Aug 23, 2017 at 10:13 AM, Fabio Estevam wrote:
> In order to reproduce the failure, just run 'glmark2-es2-drm' and wait
> until it completes. The crash always happen after the last test runs.
I have been running glmark2 tests with linux-next-20170824 overnight
and do not observe the cras
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #8 from har...@gmx.de ---
@Thomas,
i got two rejects when trying to apply the patch.
Let me sync to your base version first, to avoid additional diffs,
where/when did you branch exactly?
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--- Comment #11 from Peter Spiess-Knafl (p...@autistici.org) ---
Alex, when will this be released?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailin
dim finds remote name by matching repository urls, but different users
requires different protocols/paths for remotes (ssh/git/https). Current
code incorrectly translates provided url to alternatives, the patch
fixes it.
Signed-off-by: Andrzej Hajda
---
dim | 26 --
1 fil
Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Linux core provide helpers for polling with timeout, lets use them.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20
>> 1 file changed, 8 insertions(+), 12 de
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #7 from Thomas Hellström ---
Created attachment 133771
--> https://bugs.freedesktop.org/attachment.cgi?id=133771&action=edit
Patch to see if there might be a race causing this
@haro41: Could you test the attached dri3_mutex.diff a
Hi Noralf,
On Sun, Aug 13, 2017 at 03:31:49PM +0200, Noralf Trønnes wrote:
> drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now,
> so use the function directly.
>
> Cc: Liviu Dudau
I was on holiday for 2+ weeks, so I have no idea if you still need this,
but for hdlcd and mali
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #36 from Ethan Hsieh ---
Based on AMD's comment (The issue is gone without Compiz), I did some tests.
Here is the test result:
---
1) Run glxgears without a desktop environment
---
Hello Hean Loon,
On Friday, 25 August 2017 04:21:17 EEST Ong, Hean Loong wrote:
> Hi Laurent,
>
> The encoder resides as a hardware logic as part of the FPGA fabric. The
> software driver has no direct access to the encoder. The VIP is created
> in such a way that the software i.e Linux Driver on
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 65ec8bb6c5ab..b2ac40dab812 100644
--- a/drivers/
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 041711adfc84..def0507ad7bf 100644
--- a/drivers/gpu/d
We increment the minor driver version so userspace can detect perfmon support.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 76405b0e8815..041711adfc84 100644
--- a/
In order to support performance counters in a sane way we need to provide
a method to sync the GPU with the CPU. The GPU can process multpile command
buffers/events per irq. With the help of a 'sync point' we can trigger an event
and stop the GPU/FE immediately. When the CPU is done with is process
Some performance register are debug register and they need to
be enabled in order to be functional.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 310792c546a6..65ec8bb6c5ab 100644
--- a/
As done by Vivante kernel driver.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 842b6642d
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index def0507ad7bf..310792c546a6 100644
--- a/
Check if the selected domain and signal combination exists.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 15 +++
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gp
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 3bda13cc4025..76405b0e8815 100644
--- a/
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 55 +++
1 file changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index a8518bd4fbf6..9079ffce9391 100644
--- a/
Changes from v1 -> v2:
- renamed submit_perfmon_request() to submit_perfmon_validate()
- extended flags validation
- added comment about offset 0
- moved assigment of cmdbuf->nr_pmrs below the copy_from_user of the pmrs.
Changes from v2 -> v3:
- fixed flags validation
Signed-off-by: Christian Gme
We need to iterate over all pixel pipelines to get overall value.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnav
Results in less code as the users do not set every struct member to 0/NULL.
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gp
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 4
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 12
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
index 80d7807
This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number
of struct etnaviv_perfmon elements gets used.
Changes from v1 -> v2:
- make use of goto as requested by Lucas
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 15 ++-
drivers/gpu/
With 'sync points' we can sample the reqeustes perform signals
before and/or after the submited command buffer.
Changes v2 -> v3:
- fixed indentation and init nr_events to 1
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 102 +++---
driv
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 16
drivers/gpu/drm/etnaviv/etnaviv_perfmon.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index b8
In a perfect world we would be able to read GPU registers of interest
via the command stream with a 'read-register' command/package. For perf
counters it is a must to read them synchronized with the GPU to put the
values in relation to a draw command. As Vivante GPUs do not provide this
functionali
Make it possible that userspace can query all performance domains and
its signals. This information is needed to sample those signals via
submit ioctl.
At the moment no performance domain is available.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/Makefile | 3 +-
drive
This makes it possible to allocate multiple events under the event
spinlock. This change is needed to support 'sync'-points.
Changes v2 -> v3:
- wait for the completion of all events
- use 10sec timeout regardless of the number of events
- removed validation if there are enough free events
- fixed
This is prep work to be able to allocate multiple events in one go.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31 +--
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 --
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a
Sadly we can not read any registers via command stream so we need
to extend the drm_etnaviv_gem_submit struct with performance monitor
requests. Those requests gets process before or after the actual
submitted command stream.
The Vivante kernel driver has a special ioctl to read all perfmon
regist
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #35 from alex_zha...@dell.com ---
(In reply to Ben Widawsky from comment #34)
> Just some thoughts...
>
> The corruption are x-tiled cachelines, looks like stale ones. I don't know
> what the vertical lines are. It looks to me like t
https://bugs.freedesktop.org/show_bug.cgi?id=93301
--- Comment #29 from Kamil Páral ---
Yes, I can confirm NS2 works well now. One thing to note is that when compiling
the shaders, the memory usage of the game is much higher than when running from
the cache (even *after* the compilation has ended
On 24/08/17 14:26, Brian Starkey wrote:
> On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote:
>> On 08/24/17 13:14, Brian Starkey wrote:
>>> Hi Hans,
>>>
>>> On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
On 08/21/2017 06:01 PM, Daniel Vetter wrote:
> On Mon, Aug 2
82 matches
Mail list logo
