similar to: RFC: TTM extra bo space

Dynamically resizing the framebuffer on nv04 was like playing Russian roulette (and it often happened gratuitously) because it seems unable to scan out from buffers above 16MB. This patch splits the mappable VRAM into two chunks when that's the case, and makes the higher one to be used as well when applicable. Signed-off-by: Francisco Jerez <currojerez at riseup.net> ---

On Tue, Apr 16, 2019 at 12:05 PM Koenig, Christian <Christian.Koenig at amd.com> wrote: > > Am 15.04.19 um 21:17 schrieb Daniel Vetter: > > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > >> Hi > >> > >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: > >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200,

On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > Hi > > Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > > Hi, > > > >> If not for TTM, what would be the alternative? One VMA manager per > >> memory region per device? > > > > Depends pretty much on the device. > > > > The cirrus is a display device with

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

Thanks for the patch. Tested-by: Yannick Fertr? <yannick.fertre at st.com><mailto:yannick.fertre at st.com> BR Yannick Fertr? On 1/10/20 10:21 AM, Thomas Zimmermann wrote: The new callback get_scanout_position() reads the current location of the scanout process. The operation is currentyl located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in

I am receiving these errors when rebooting my system. Unmounting file systems: (1785) ERROR: unable to sendmsg, error=-101, Linux/ocfsipc.c, 394 (1785) ERROR: status = -999, Linux ocfsipc.c, 206 ocfs: Unmounting device (104,33) on rac1-priv1.collo.corp.net (node 2) (1785) ERROR: unable to sendmsg, error=-101, Linux/ocfsipc.c, 394 (1785) ERROR: status = -999, Linux/ocfsipc.c, 206 It

On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote: > The callback get_vblank_timestamp() is currently located in struct > drm_driver, but really belongs into struct drm_crtc_funcs. Add an > equivalent there. Driver will be converted in separate patches. > > The default implementation is drm_calc_vbltimestamp_from_scanoutpos(). > The patch adds

On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > new file mode 100644 > index 0000000..9455383 > --- /dev/null > +++ b/docs/specs/virtio-gpu.txt > @@ -0,0 +1,165 @@ > +virtio-gpu specification > +======================== This document refers to the implementation for structs and does not

On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > new file mode 100644 > index 0000000..9455383 > --- /dev/null > +++ b/docs/specs/virtio-gpu.txt > @@ -0,0 +1,165 @@ > +virtio-gpu specification > +======================== This document refers to the implementation for structs and does not

Am 15.04.19 um 21:17 schrieb Daniel Vetter: > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> Hi >> >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: >>>> Hi >>>> >>>> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com:

On Fri, 10 Jan 2020, Thomas Zimmermann <tzimmermann at suse.de> wrote: > The callback struct drm_driver.get_scanout_position() is deprecated in > favor of struct drm_crtc_helper_funcs.get_scanout_position(). > > i915 doesn't use CRTC helpers. The patch duplicates the caller > drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback > function is not

On 09/11/2014 09:09 AM, Gerd Hoffmann wrote: > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- > docs/specs/virtio-gpu.txt | 165 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 165 insertions(+) > create mode 100644 docs/specs/virtio-gpu.txt > > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > new file mode 100644

On 09/11/2014 09:09 AM, Gerd Hoffmann wrote: > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- > docs/specs/virtio-gpu.txt | 165 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 165 insertions(+) > create mode 100644 docs/specs/virtio-gpu.txt > > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > new file mode 100644

For now pixmaps will only be tiled if driver pixmaps are being used and we're told to with the NOUVEAU_CREATE_PIXMAP_TILED usage hint. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- src/nouveau_exa.c | 31 ++++++++++++++++++++----------- src/nv50_exa.c | 6 +++--- src/nv50_xv.c | 2 +- src/nv_proto.h | 2 +- src/nv_type.h | 1 + 5 files

On Fri, Nov 28, 2014 at 02:14:24PM +0900, Alexandre Courbot wrote: > On 11/28/2014 01:39 AM, Thierry Reding wrote: > >Tegra K1 and later use a GPU that can be driven by the Nouveau driver. > >But the GPU is a pure render node and has no display engine, hence the > >scanout needs to happen on the Tegra display hardware. The GPU and the > >display engine each have a

On Sun, 13 Sep 2009 20:06:59 -0700 (PDT) darktama at kemper.freedesktop.org (Ben Skeggs) wrote: > src/drmmode_display.c | 6 ++++++ > src/nv_driver.c | 2 ++ > 2 files changed, 8 insertions(+) > > New commits: > commit 6c045fc44783454180d7b3d00b5f25436bd5544e > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Sep 14 13:04:12 2009 +1000 >

In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You can pick this up at: https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)

On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: > On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > > In case anyone's curious about 30bpp framebuffer support, here's the > > current status: > > > > Kernel: > > > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > > and I've also written a

Hi There, I've been toying around with the code of rsync on and off for a while, and I had a thought that I would like some comments on. Its to do with very large files and disk space. One of the common uses of rsync is to use it as a backup program. A client connects to the rsync server, and sends over any changed files. If the client has very large files that have changed marginally,