subject:"Re\:"

Re: [git pull] drm fixes for v4.12-rc1

2017-05-14 Thread Linus Torvalds

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie  wrote:
>
> It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
> which is new in this kernel and is preliminary support so may have a
> fair bit of movement.

Note: I will *not* be taking these kinds of pull requests after rc1.

If Vega10 is in such bad shape that it will need this kind of stuff
and isn't worth shipping without them in 4.12, I will take a *oneline*
that just disables it.

So no "thousands of lines of fixes for a new driver".

Being new to 4.12 isn't an excuse for crazy stuff after the merge
window. If it will need more of this kind of attention, all it means
is that it shouldn't have been sent to me at all in the first place.

The drm subsystem is still on my "no more of this shit" list, so I'm
going to be very unforgiving of big pull requests when they aren't
appropriate.

 Linus

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: drm/exynos: g2d userptr memory corruption

2015-08-17 Thread Lucas Stach

Hi Tobias,

Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
 Hello,
 
 some time ago I checked whether I could use the userptr functionality to
 do zero-copy from userspace allocated buffers via the G2D. This didn't
 work out so well, so kinda put this to the bottom of my TODO list.
 
 Now that IOMMU support has landed and Jan Kara has rewrote page pinning
 using frame vectors (see [1]) I gave userptr another try.
 
 The results are much better. I'm not experiencing any kernel lockups or
 sysmmu pagefaults anymore. However the image now suffers from visual
 artifacts. These images show the nature of the artifacts:
 http://i.imgur.com/nzT6g3Y.jpg
 http://i.imgur.com/wkuYI6X.jpg
 
 The corruption always manifests itself in these pixel lines of fixed
 size and wrong color.
 
 I have written a testcase as part of libdrm for this issue:
 https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71
 
 It allocates N (N an even number) buffers which are aligned to the
 system pagesize. Then it does this each iteration:
 1) Fill the first N/2 buffers with random data
 2) Copy the first half to the second half of the buffers
 3) memcmp() first and second half (verification pass)
 
 Usually this verification already fails on the first iteration. An
 interesting observation is that increasing (!) the buffer size (so the
 amount of pixels that have to copied per buffer grows) makes this issue
 less likely to happen.
 
 With the default 512x512 buffers however it happens, like I said above,
 almost immediately.
 
This is obviously a cache flush missing. The memory you get from
userspace is normal cached memory, so to make it visible to the GPU you
need to flush parts of the cache out to main memory.

The corruption you are seeing is just unflushed cachelines. This also
explains why increasing the buffer size helps: the more memory the CPU
touches the more cachelines will be flushed out to be replaced with new
data.

So you need to go and have a look at dma_map() and dma_sync_*_for_*()
and friends.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |


--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: drm/exynos: g2d userptr memory corruption

2015-08-17 Thread Tobias Jakobi

Thanks Lucas for the explanation!


Lucas Stach wrote:
 Hi Tobias,
 
 Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
 Hello,

 some time ago I checked whether I could use the userptr functionality to
 do zero-copy from userspace allocated buffers via the G2D. This didn't
 work out so well, so kinda put this to the bottom of my TODO list.

 Now that IOMMU support has landed and Jan Kara has rewrote page pinning
 using frame vectors (see [1]) I gave userptr another try.

 The results are much better. I'm not experiencing any kernel lockups or
 sysmmu pagefaults anymore. However the image now suffers from visual
 artifacts. These images show the nature of the artifacts:
 http://i.imgur.com/nzT6g3Y.jpg
 http://i.imgur.com/wkuYI6X.jpg

 The corruption always manifests itself in these pixel lines of fixed
 size and wrong color.

 I have written a testcase as part of libdrm for this issue:
 https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71

 It allocates N (N an even number) buffers which are aligned to the
 system pagesize. Then it does this each iteration:
 1) Fill the first N/2 buffers with random data
 2) Copy the first half to the second half of the buffers
 3) memcmp() first and second half (verification pass)

 Usually this verification already fails on the first iteration. An
 interesting observation is that increasing (!) the buffer size (so the
 amount of pixels that have to copied per buffer grows) makes this issue
 less likely to happen.

 With the default 512x512 buffers however it happens, like I said above,
 almost immediately.

 This is obviously a cache flush missing. The memory you get from
 userspace is normal cached memory, so to make it visible to the GPU you
 need to flush parts of the cache out to main memory.
 
 The corruption you are seeing is just unflushed cachelines. This also
 explains why increasing the buffer size helps: the more memory the CPU
 touches the more cachelines will be flushed out to be replaced with new
 data.
I should point out that the snapshots I uploaded were done with a
different setup. There only the source memory of the G2D operation is a
userspace allocated buffer. The destination is a GEM buffer allocated
through libdrm, which is then used as framebuffer. So the issue already
appears when just the source is userspace allocated.

What works however is an operation between GEM to GEM. However this
might be related to the default allocation flags libdrm uses.



 So you need to go and have a look at dma_map() and dma_sync_*_for_*()
 and friends.
 
 Regards,
 Lucas
 


With best wishes,
Tobias



--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-25 Thread Pavel Machek

On Thu 2015-01-29 14:11:25, Dave Airlie wrote:
 These two copy to/from VGA memory, however on the Silicon
 Motion SMI750 VGA card on a 64-bit system cause console corruption.
 
 This is due to the hw being buggy and not handling a 64-bit transaction
 correctly.
 
 We could try and create a 32-bit version of these routines,
 but I'm not sure the optimisation is worth much today.
 
 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1132826
 
 Tested-by: Huawei engineering.
 Signed-off-by: Dave Airlie airl...@redhat.com

Actually... are you sure this is right fix?

IOW can gcc do the optimalization behind your back and still break the
buggy card?
Pavel

 diff --git a/include/linux/vt_buffer.h b/include/linux/vt_buffer.h
 index 057db7d..f38c10b 100644
 --- a/include/linux/vt_buffer.h
 +++ b/include/linux/vt_buffer.h
 @@ -21,10 +21,6 @@
  #ifndef VT_BUF_HAVE_RW
  #define scr_writew(val, addr) (*(addr) = (val))
  #define scr_readw(addr) (*(addr))
 -#define scr_memcpyw(d, s, c) memcpy(d, s, c)
 -#define scr_memmovew(d, s, c) memmove(d, s, c)
 -#define VT_BUF_HAVE_MEMCPYW
 -#define VT_BUF_HAVE_MEMMOVEW
  #endif
  
  #ifndef VT_BUF_HAVE_MEMSETW

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-09 Thread Geert Uytterhoeven

On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone dan...@fooishbar.org wrote:
 On 5 February 2015 at 11:35, One Thousand Gnomes
 gno...@lxorguk.ukuu.org.uk wrote:
 If I'm not mistaken, that would be as simple as adding

 #define VT_BUF_HAVE_RW.
 #define scr_writew(val, addr) (*(addr) = (val))
 #define scr_readw(addr) (*(addr))

 to arch/x86/include/asm/vga.h.

 and stick an

 #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)

 #endif

 around that and its sorted as an option everyone can leave off but the
 afflicted.

 Well, given all the distros will enable that, might as well be #if
 !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).

All distros on 1 out of 29 architectures?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-09 Thread One Thousand Gnomes

On Mon, 9 Feb 2015 11:00:55 +
Daniel Stone dan...@fooishbar.org wrote:

 On 9 February 2015 at 10:49, Geert Uytterhoeven ge...@linux-m68k.org wrote:
  On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone dan...@fooishbar.org wrote:
  On 5 February 2015 at 11:35, One Thousand Gnomes
  gno...@lxorguk.ukuu.org.uk wrote:
  #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
 
  #endif
 
  around that and its sorted as an option everyone can leave off but the
  afflicted.
 
  Well, given all the distros will enable that, might as well be #if
  !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
 
  All distros on 1 out of 29 architectures?
 
 It's a fairly popular architecture.

I imagine most distros wouldn't enable it even on x86. It's an incredibly
obscure setup from the evidence of how long it took to get reported.

Most distributions don't support non PAE processors and other far more
common things 8)

Alan


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-09 Thread Daniel Stone

On 9 February 2015 at 10:49, Geert Uytterhoeven ge...@linux-m68k.org wrote:
 On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone dan...@fooishbar.org wrote:
 On 5 February 2015 at 11:35, One Thousand Gnomes
 gno...@lxorguk.ukuu.org.uk wrote:
 #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)

 #endif

 around that and its sorted as an option everyone can leave off but the
 afflicted.

 Well, given all the distros will enable that, might as well be #if
 !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).

 All distros on 1 out of 29 architectures?

It's a fairly popular architecture.

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-09 Thread Daniel Stone

On 5 February 2015 at 11:35, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
 If I'm not mistaken, that would be as simple as adding

 #define VT_BUF_HAVE_RW.
 #define scr_writew(val, addr) (*(addr) = (val))
 #define scr_readw(addr) (*(addr))

 to arch/x86/include/asm/vga.h.

 and stick an

 #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)

 #endif

 around that and its sorted as an option everyone can leave off but the
 afflicted.

Well, given all the distros will enable that, might as well be #if
!defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-05 Thread Geert Uytterhoeven

On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
 On Thu, 29 Jan 2015 15:40:33 -0800
 Linus Torvalds torva...@linux-foundation.org wrote:

 On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie airl...@redhat.com wrote:
 
  Linus, this came up a while back I finally got some confirmation
  that it fixes those servers.

 I'm certainly ok with this. which way should it go in? The users are:

  - drivers/tty/vt/vt.c (Greg KH, tty layer)

  - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)

 and it might make sense to have *some* indication of how much worse
 this makes fbcon performance in particular..

 For devices that have no hardware scrolling it used to be double digit
 percentages difference between 32 and 64bit when reading from the fb
 because the reads are not posted and the latency killed you. Writes - not
 so big a deal - but the bridge should combine them anyway. I imagine
 16bit read would be unprintably bad.

Fbcon uses scr_mem{cpy,move}w() for the VT buffer (characters + attributes)
only, not for the frame buffer data.
So the performance degradation should be minimal.

However, as this affects real VGA on x86 only, perhaps it can be fixed
in arch/x86/include/asm/vga.h instead of include/linux/vt_buffer.h, so
platforms not having VGA are not affected? We have these VT_BUF_*
and scr_*() abstractions for a reason...

If I'm not mistaken, that would be as simple as adding

#define VT_BUF_HAVE_RW.
#define scr_writew(val, addr) (*(addr) = (val))
#define scr_readw(addr) (*(addr))

to arch/x86/include/asm/vga.h.

If someone wants to put one of the bad VGA cards in a non-x86 PCI slot,
perhaps a few more architecture-specific asm/vga.h have to be updated:

$ git grep -w VT_BUF_HAVE_RW -- arch
arch/alpha/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/mips/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/powerpc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/sparc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/tile/include/asm/vga.h:#define VT_BUF_HAVE_RW

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-05 Thread One Thousand Gnomes

 If I'm not mistaken, that would be as simple as adding
 
 #define VT_BUF_HAVE_RW.
 #define scr_writew(val, addr) (*(addr) = (val))
 #define scr_readw(addr) (*(addr))
 
 to arch/x86/include/asm/vga.h.

and stick an

#if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)

#endif

around that and its sorted as an option everyone can leave off but the
afflicted.

Alan

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

2015-02-03 Thread One Thousand Gnomes

On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds torva...@linux-foundation.org wrote:

 On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie airl...@redhat.com wrote:
 
  Linus, this came up a while back I finally got some confirmation
  that it fixes those servers.
 
 I'm certainly ok with this. which way should it go in? The users are:
 
  - drivers/tty/vt/vt.c (Greg KH, tty layer)
 
  - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
 
 and it might make sense to have *some* indication of how much worse
 this makes fbcon performance in particular..

For devices that have no hardware scrolling it used to be double digit
percentages difference between 32 and 64bit when reading from the fb
because the reads are not posted and the latency killed you. Writes - not
so big a deal - but the bridge should combine them anyway. I imagine
16bit read would be unprintably bad.

Is it reads or writes that kill the card ?

Also note that switching to lots of small writes may break the 3Dfx
driver for the early 3Dfx PCI cards - they are really quite touchy about
how they are fed.

Unfortunately fbcon still matters for dumb EFI framebuffer fallbacks.

vgacon it doesn't matter (if it was too slow you could make vgacon as
fast as you want by only updating the off screen characters once per
vertical blank). fbcon that is a bit harder as you are allowed to
scribble on the display as well. You can't even check open/mmapped as you
can open, scribble and close.

Alan

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't gmake libdrm-2.4.59 on OmniOS

2015-02-03 Thread Emil Velikov

On 1 February 2015 at 01:03, CodeSwim OS Development
os-...@codeswim.com wrote:
I'm trying to build libdrm and have an issue when I gmake after
configuring. Steps to reproduce:

# uname -a
SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc

Where can one get a copy of OmniOS ? Free of charge of course :-P
But more seriously

From the massive log I can spot a few interesting things
- _FILE_OFFSET_BITS redefinition.
Autotools correctly detects and sets it set to 64 (as you've got a
32bit system/build), yet further down the gcc headers, it's already
set to 32. This won't break the build but will likely cause problems
at runtime.

- A ton of -Wparentheses warnings.
These should be safe - you might also want to silence them so that
serious issues are clearer.

- And last but not leask the missing _IOC symbol.
Gentoo people have a patch on the topic [1] - might be nice to clean
it up and upstream it.

Cheers,
Emil

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 23178 matches

Mail list logo