Hi all!
Some time ago both nouveau and radeon developers wished to have some in-kernel
interface for hwmon, so automatic fan management can be implemented for GPU
drivers ...
Today I was looking at LKML and found this RFC:
https://lkml.org/lkml/2011/11/4/18
Subject [RFC PATCH 0/2] HWMON: ad
On Sun, Nov 06, 2011 at 09:16:00PM +, Chris Wilson wrote:
> On Sun, 6 Nov 2011 20:13:56 +0100, Daniel Vetter
> wrote:
> > ~120 ?s instead fo ~210 ?s to write 1mb on my snb. I like this.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_gem.c |1 +
> > 1 files
On Sun, 6 Nov 2011 20:13:58 +0100, Daniel Vetter
wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for th
https://bugs.freedesktop.org/show_bug.cgi?id=37528
Oleg German changed:
What|Removed |Added
CC||kh3095 at yandex.ru
xbx changed:
https://bugs.freedesktop.org/show_bug.cgi?id=42645
Christian Inci changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Sun, 6 Nov 2011 20:13:56 +0100, Daniel Vetter
wrote:
> ~120 ??s instead fo ~210 ??s to write 1mb on my snb. I like this.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #7 from Kunal 2011-11-06 20:29:09
PST ---
Created attachment 53225
--> https://bugs.freedesktop.org/attachment.cgi?id=53225
dmesg output from 3.1.0-2.3 taken on 2011-11-07
--
Configure bugmail: https://bugs.freedesktop.org/userpr
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #6 from Kunal 2011-11-06 20:28:26
PST ---
Noticed these new messages in dmesg output:
[ 15.828387] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0016
address=0x000e7000 flags=0x0010]
[ 15.828394] AMD-Vi: Eve
The pagemap.h prefault helpers do the prefaulting by simply writing
some data into every page. Hence we should not prefault when we're not
yet commited to to actually writing data to userspace. The problem is
now that
- we can't prefault while holding dev->struct_mutex for we could
deadlock with
With the proper prefault, it's extremely unlikely that we fall back
to the gtt slowpath.
So just kill it and use the shmem_pwrite path as fallback.
To further clean up the code, move the preparatory gem calls into the
respective pwrite functions. This way the gtt_fast->shmem fallback
is much more
drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.
I've checked the callsites and they all already clamp size when
calling fault_in_pages_* to the same as for the subsequent
__copy_to|from_user and hence don't rely on the implicit
This speeds up pwrite and pread from ~120 ?s ro ~100 ?s for
reading/writing 1mb on my snb (if the backing storage pages
are already pinned, of course).
v2: Chris Wilson pointed out a claring page reference bug - I've
unconditionally dropped the reference. With that fixed (and the
associated reduct
~120 ?s instead fo ~210 ?s to write 1mb on my snb. I like this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0048917..8fd175c 10064
No longer needed.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |7 --
drivers/gpu/drm/i915/i915_gem.c | 117 ---
2 files changed, 0 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i9
This is obviously gonna slow down pread. But for a half-way realistic
micro-benchmark, it doesn't matter: Non-broken userspace reads back
data from the gpu once before the gpu again dirties it.
So all this ranged clflush tracking is just a waste of time.
No pread performance change (neglecting th
Useful when the page is already mapped to copy date in/out.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_cache.c | 23 +++
include/drm/drmP.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/dr
With the previous rewrite, they've become essential identical.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 108 ++-
1 files changed, 27 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/
With the previous rewrite, they've become essential identical.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 126 ++
1 files changed, 33 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i
Like for shmem_pwrite_slow. The only difference is that because we
read data, we can leave the fetched cachelines in the cpu: In the case
that the object isn't in the cpu read domain anymore, the clflush for
the next cpu read domain invalidation will simply drop these
cachelines.
slow_shmem_bit17_
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault
The gtt_pwrite slowpath grabs the userspace memory with
get_user_pages. This will not work for non-page backed memory, like a
gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
-EFAULT in the gtt paths.
Now the shmem paths have exactly the same problem, but this way we
only nee
Hi all,
I've finally managed to clean up my pwrite/pread rework. Major changes since the
first submission:
- fixed a bunch of bugs, some of them discovered by the intel-gpu-tools gem test
suite
- extracted the clflush helper into common drm code as suggested by Chris
Wilson.
- extended the pre
On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
wrote:
> Trusting the spec worries me; could this break anybody?
It will allow the user to override possibly safer default settings. If
a user has specified, say, 2x in his xorg.conf and this was not
honored because the card only reported 4x, this pa
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #140 from Abdul Nazar P 2011-11-06
08:44:26 PST ---
pls work for i845
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
From: Tormod Volden
Signed-off-by: Tormod Volden
---
drivers/char/agp/generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index c5d04e5..2dc2d5b 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/ch
From: Tormod Volden
Some cards report that they support only 4x, in which case they
should support 2x and 1x as well, according to the AGP spec.
Otherwise a requested 1x or 2x rate will result in 0 being set:
agpgart-via :00:00.0: putting AGP V2 device into 0x mode
For instance ProSavage K
https://bugs.freedesktop.org/show_bug.cgi?id=42645
--- Comment #1 from Christian Inci 2011-11-06
07:56:48 PST ---
Created attachment 53222
--> https://bugs.freedesktop.org/attachment.cgi?id=53222
Incorrect rendering
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=42645
Bug #: 42645
Summary: Graphics issues on BZFlag 2.4.0 with i915g (gallium)
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
URL: http://bzflag.o
On Sun, 6 Nov 2011 20:13:58 +0100, Daniel Vetter
wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for th
On Sun, Nov 06, 2011 at 09:16:00PM +, Chris Wilson wrote:
> On Sun, 6 Nov 2011 20:13:56 +0100, Daniel Vetter
> wrote:
> > ~120 µs instead fo ~210 µs to write 1mb on my snb. I like this.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_gem.c |1 +
> > 1 files
https://bugs.freedesktop.org/show_bug.cgi?id=37528
Oleg German changed:
What|Removed |Added
CC||kh3...@yandex.ru
xbx changed:
On Sun, 6 Nov 2011 20:13:56 +0100, Daniel Vetter
wrote:
> ~120 µs instead fo ~210 µs to write 1mb on my snb. I like this.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i
https://bugs.freedesktop.org/show_bug.cgi?id=25764
--- Comment #6 from Dave Airlie 2011-11-06
05:06:37 PST ---
please retry with latest r600g.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee fo
The pagemap.h prefault helpers do the prefaulting by simply writing
some data into every page. Hence we should not prefault when we're not
yet commited to to actually writing data to userspace. The problem is
now that
- we can't prefault while holding dev->struct_mutex for we could
deadlock with
With the proper prefault, it's extremely unlikely that we fall back
to the gtt slowpath.
So just kill it and use the shmem_pwrite path as fallback.
To further clean up the code, move the preparatory gem calls into the
respective pwrite functions. This way the gtt_fast->shmem fallback
is much more
drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.
I've checked the callsites and they all already clamp size when
calling fault_in_pages_* to the same as for the subsequent
__copy_to|from_user and hence don't rely on the implicit
This speeds up pwrite and pread from ~120 µs ro ~100 µs for
reading/writing 1mb on my snb (if the backing storage pages
are already pinned, of course).
v2: Chris Wilson pointed out a claring page reference bug - I've
unconditionally dropped the reference. With that fixed (and the
associated reduct
~120 µs instead fo ~210 µs to write 1mb on my snb. I like this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0048917..8fd175c 10064
No longer needed.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |7 --
drivers/gpu/drm/i915/i915_gem.c | 117 ---
2 files changed, 0 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i9
This is obviously gonna slow down pread. But for a half-way realistic
micro-benchmark, it doesn't matter: Non-broken userspace reads back
data from the gpu once before the gpu again dirties it.
So all this ranged clflush tracking is just a waste of time.
No pread performance change (neglecting th
Useful when the page is already mapped to copy date in/out.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_cache.c | 23 +++
include/drm/drmP.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drive
With the previous rewrite, they've become essential identical.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 108 ++-
1 files changed, 27 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/
With the previous rewrite, they've become essential identical.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 126 ++
1 files changed, 33 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i
Like for shmem_pwrite_slow. The only difference is that because we
read data, we can leave the fetched cachelines in the cpu: In the case
that the object isn't in the cpu read domain anymore, the clflush for
the next cpu read domain invalidation will simply drop these
cachelines.
slow_shmem_bit17_
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter
wrote:
> The reclaim_buffers function of the savage driver actually wants to run
> with the hw_lock held - at least there are printks in the call-chain
> to that effect. But the drm core only calls reclaim_buffers as used
> by savage _after_ forceful
The gtt_pwrite slowpath grabs the userspace memory with
get_user_pages. This will not work for non-page backed memory, like a
gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
-EFAULT in the gtt paths.
Now the shmem paths have exactly the same problem, but this way we
only nee
Hi all,
I've finally managed to clean up my pwrite/pread rework. Major changes since the
first submission:
- fixed a bunch of bugs, some of them discovered by the intel-gpu-tools gem test
suite
- extracted the clflush helper into common drm code as suggested by Chris
Wilson.
- extended the pre
Thanks for writing it!
Reviewed-by: Corbin Simpson
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 10:39 AM, "Tormod Volden" wrote:
> On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
> wrote:
> > Trusting the spec worries me; could this break anybody?
>
> It will allow the user
>> + case 2:
> >> + *vga_agpstat |= AGPSTAT2_1X;
> >> + printk(KERN_INFO PFX "Graphics card claims to only
> support
> >> x2 rate. "
> >> + "Fixing up support for x1\n");
> >> + break;
> >> + default:
> >> + break;
> >> + }
> >> +
> >>/* Check the speed bits make sense. Only one should be set. */
> >>tmp = *requested_mode & 7;
> >>switch (tmp) {
> >> --
> >> 1.7.5.4
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2006/5da721fe/attachment.html>
On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
wrote:
> Trusting the spec worries me; could this break anybody?
It will allow the user to override possibly safer default settings. If
a user has specified, say, 2x in his xorg.conf and this was not
honored because the card only reported 4x, this pa
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #5 from Kunal 2011-11-06 02:00:43
PST ---
Created attachment 53209
--> https://bugs.freedesktop.org/attachment.cgi?id=53209
new dmesg.log with kernel 3.1.0-2.3
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=42373
Kunal changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
Hi all!
Some time ago both nouveau and radeon developers wished to have some in-kernel
interface for hwmon, so automatic fan management can be implemented for GPU
drivers ...
Today I was looking at LKML and found this RFC:
https://lkml.org/lkml/2011/11/4/18
Subject [RFC PATCH 0/2] HWMON: ad
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #140 from Abdul Nazar P 2011-11-06 08:44:26
PST ---
pls work for i845
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=42645
--- Comment #1 from Christian Inci 2011-11-06
07:56:48 PST ---
Created attachment 53222
--> https://bugs.freedesktop.org/attachment.cgi?id=53222
Incorrect rendering
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=42645
Bug #: 42645
Summary: Graphics issues on BZFlag 2.4.0 with i915g (gallium)
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
URL: http://bzflag.o
Trusting the spec worries me; could this break anybody?
Is there any reason to use the not-so-magic numbers instead of the named
constants?
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:03 AM, "Tormod Volden" wrote:
> From: Tormod Volden
>
> Some cards report that they supp
ld be set. */
>tmp = *requested_mode & 7;
>switch (tmp) {
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2006/7363198e/attachment.htm>
FWIW, Reviewed-by: Corbin Simpson
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:04 AM, "Tormod Volden" wrote:
> From: Tormod Volden
>
> Signed-off-by: Tormod Volden
> ---
> drivers/char/agp/generic.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>
ot set GATT table memory to
> UC!\n");
>
>bridge->gatt_table = (void *)table;
> #else
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2006/ac42aa8a/attachment-0001.htm>
From: Tormod Volden
Signed-off-by: Tormod Volden
---
drivers/char/agp/generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index c5d04e5..2dc2d5b 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/ch
From: Tormod Volden
Some cards report that they support only 4x, in which case they
should support 2x and 1x as well, according to the AGP spec.
Otherwise a requested 1x or 2x rate will result in 0 being set:
agpgart-via :00:00.0: putting AGP V2 device into 0x mode
For instance ProSavage K
https://bugs.freedesktop.org/show_bug.cgi?id=25764
--- Comment #6 from Dave Airlie 2011-11-06 05:06:37
PST ---
please retry with latest r600g.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #10 from Mandeep Singh Baines
2011-11-05 19:58:01 PDT ---
Woot! HDMI works fine.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee f
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter wrote:
> The reclaim_buffers function of the savage driver actually wants to run
> with the hw_lock held - at least there are printks in the call-chain
> to that effect. But the drm core only calls reclaim_buffers as used
> by savage _after_ forcefull
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #5 from Kunal 2011-11-06 02:00:43
PST ---
Created attachment 53209
--> https://bugs.freedesktop.org/attachment.cgi?id=53209
new dmesg.log with kernel 3.1.0-2.3
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=42373
Kunal changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
68 matches
Mail list logo
