Re: [Nouveau] [PATCH] instmem/gk20a: exclusively acquire instobjs

2015-11-04 Thread Ben Skeggs 
On 10/26/2015 03:54 PM, Alexandre Courbot wrote:
> Although I would not have expected this to happen, we seem to run into
> race conditions if instobjs are accessed concurrently. Use a global lock
> for safety.
I wouldn't expect this to be an issue either.

Before merging such a large hammer of a fix, I'd strongly prefer to see
at least a better justification for why this is happening rather than
potentially papering over a larger issue.

Ben.

> 
> Signed-off-by: Alexandre Courbot 
> ---
>  drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
> b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> index fc419bb8eab7..d015633b8edd 100644
> --- a/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> +++ b/drm/nouveau/nvkm/subdev/instmem/gk20a.c
> @@ -92,6 +92,7 @@ struct gk20a_instmem {
>  
>   /* protects vaddr_* and gk20a_instobj::vaddr* */
>   spinlock_t lock;
> + unsigned long flags;
>  
>   /* CPU mappings LRU */
>   unsigned int vaddr_use;
> @@ -188,12 +189,11 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>   struct gk20a_instobj *node = gk20a_instobj(memory);
>   struct gk20a_instmem *imem = node->imem;
>   struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
> - const u64 size = nvkm_memory_size(memory);
> - unsigned long flags;
> + u64 size;
>  
>   nvkm_ltc_flush(ltc);
>  
> - spin_lock_irqsave(>lock, flags);
> + spin_lock_irqsave(>lock, imem->flags);
>  
>   if (node->vaddr) {
>   /* remove us from the LRU list since we cannot be unmapped */
> @@ -202,6 +202,8 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>   goto out;
>   }
>  
> + size = nvkm_memory_size(memory);
> +
>   /* try to free some address space if we reached the limit */
>   gk20a_instmem_vaddr_gc(imem, size);
>  
> @@ -218,8 +220,6 @@ gk20a_instobj_acquire(struct nvkm_memory *memory)
>  imem->vaddr_use, imem->vaddr_max);
>  
>  out:
> - spin_unlock_irqrestore(>lock, flags);
> -
>   return node->vaddr;
>  }
>  
> @@ -229,14 +229,11 @@ gk20a_instobj_release(struct nvkm_memory *memory)
>   struct gk20a_instobj *node = gk20a_instobj(memory);
>   struct gk20a_instmem *imem = node->imem;
>   struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
> - unsigned long flags;
> -
> - spin_lock_irqsave(>lock, flags);
>  
>   /* add ourselves to the LRU list so our CPU mapping can be freed */
>   list_add_tail(>vaddr_node, >vaddr_lru);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + spin_unlock_irqrestore(>lock, imem->flags);
>  
>   wmb();
>   nvkm_ltc_invalidate(ltc);
> 



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] instmem/gk20a: exclusively acquire instobjs

2015-11-04 Thread Alexandre Courbot 
On Thu, Nov 5, 2015 at 6:19 AM, Ben Skeggs  wrote:
> On 10/26/2015 03:54 PM, Alexandre Courbot wrote:
>> Although I would not have expected this to happen, we seem to run into
>> race conditions if instobjs are accessed concurrently. Use a global lock
>> for safety.
> I wouldn't expect this to be an issue either.
>
> Before merging such a large hammer of a fix, I'd strongly prefer to see
> at least a better justification for why this is happening rather than
> potentially papering over a larger issue.

I was afraid you would say that. ;)

But you're right. I am really busy with lots of stuff but will try to
rootcause this more precisely...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] nvkm: add/remove 0's to make 7 (or 9)-nibble constants use 8 nibbles

2015-11-04 Thread Ilia Mirkin 
Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 2 +-
 drm/nouveau/nvkm/subdev/fb/ramgk104.c | 8 
 drm/nouveau/nvkm/subdev/therm/nv40.c  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nvkm/engine/gr/ctxgk20a.c 
b/drm/nouveau/nvkm/engine/gr/ctxgk20a.c
index ddaa16a..ad0a6cf 100644
--- a/drm/nouveau/nvkm/engine/gr/ctxgk20a.c
+++ b/drm/nouveau/nvkm/engine/gr/ctxgk20a.c
@@ -55,7 +55,7 @@ gk20a_grctx_generate_main(struct gf100_gr *gr, struct 
gf100_grctx *info)
 
gk104_grctx_generate_rop_active_fbps(gr);
 
-   nvkm_mask(device, 0x5044b0, 0x800, 0x800);
+   nvkm_mask(device, 0x5044b0, 0x0800, 0x0800);
 
gf100_gr_wait_idle(gr);
 
diff --git a/drm/nouveau/nvkm/subdev/fb/ramgk104.c 
b/drm/nouveau/nvkm/subdev/fb/ramgk104.c
index 0d20563..2614365 100644
--- a/drm/nouveau/nvkm/subdev/fb/ramgk104.c
+++ b/drm/nouveau/nvkm/subdev/fb/ramgk104.c
@@ -216,11 +216,11 @@ r1373f4_fini(struct gk104_ramfuc *fuc)
ram_wr32(fuc, 0x1373ec, tmp | (v1 << 16));
ram_mask(fuc, 0x1373f0, (~ram->mode & 3), 0x);
if (ram->mode == 2) {
-   ram_mask(fuc, 0x1373f4, 0x0003, 0x2);
-   ram_mask(fuc, 0x1373f4, 0x1100, 0x0);
+   ram_mask(fuc, 0x1373f4, 0x0003, 0x0002);
+   ram_mask(fuc, 0x1373f4, 0x1100, 0x);
} else {
-   ram_mask(fuc, 0x1373f4, 0x0003, 0x1);
-   ram_mask(fuc, 0x1373f4, 0x0001, 0x0);
+   ram_mask(fuc, 0x1373f4, 0x0003, 0x0001);
+   ram_mask(fuc, 0x1373f4, 0x0001, 0x);
}
ram_mask(fuc, 0x10f800, 0x0030, (v0 ^ v1) << 4);
 }
diff --git a/drm/nouveau/nvkm/subdev/therm/nv40.c 
b/drm/nouveau/nvkm/subdev/therm/nv40.c
index 6326fdc..2c92ffb 100644
--- a/drm/nouveau/nvkm/subdev/therm/nv40.c
+++ b/drm/nouveau/nvkm/subdev/therm/nv40.c
@@ -107,7 +107,7 @@ nv40_fan_pwm_ctrl(struct nvkm_therm *therm, int line, bool 
enable)
 {
struct nvkm_subdev *subdev = >subdev;
struct nvkm_device *device = subdev->device;
-   u32 mask = enable ? 0x8000 : 0x000;
+   u32 mask = enable ? 0x8000 : 0x;
if  (line == 2) nvkm_mask(device, 0x0010f0, 0x8000, mask);
else if (line == 9) nvkm_mask(device, 0x0015f4, 0x8000, mask);
else {
-- 
2.4.10

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] HDMI pixel clock limits

2015-11-04 Thread Ilia Mirkin 
In the meanwhile we're pushing out a change that just blanket allows
225MHz on Fermi and 297MHz on Kepler, with a kernel option override
available. At least one GF106 user claims to have working 297MHz with
proprietary drivers (and with nouveau in presence of the patches):

https://bugs.freedesktop.org/show_bug.cgi?id=91236

Having an accurate way to auto-detect this would be ideal though, as
higher bandwidth monitors are becoming more ubiquitous.

  -ilia


On Mon, Oct 26, 2015 at 1:35 PM, Ilia Mirkin  wrote:
> Hello,
>
> Various HDMI versions enable higher and higher pixel clocks. However
> individual GPUs are not required to support the maximum pixel clock
> supported by the spec in order to be compliant. It appears that some
> GPUs max out at 225MHz while others at 297MHz (while others still, I
> assume, are limited to 165MHz, esp among the older ones).
>
> We've been unable to find this in the VBIOS (I had a thought that it
> was in the table pointed to by the 'T' table, but we have a
> counterexample to that). Could you suggest a way to find this
> information either from the VBIOS or based on the GPU? Are there
> differences between regular HDMI and DP -> HDMI (passive)?
>
> This is becoming more and more relevant as 2560x1440/3840x2160
> displays are become more common, while (dual-link) DVI-D is on its way
> out.
>
> Thanks,
>
>   -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NOUVEAU(0): DRI3 on EXA enabled

2015-11-04 Thread poma 
On 04.11.2015 11:57, Martin Peres wrote:
> On 02/11/15 08:28, poma wrote:
>> An interesting results.
>>
>> DRI2:
>>
>> $ vblank_mode=0 glxgears
>> ATTENTION: default value of option vblank_mode overridden by environment.
>> 6321 frames in 5.0 seconds = 1264.103 FPS
>> 6380 frames in 5.0 seconds = 1275.943 FPS
>> 6369 frames in 5.0 seconds = 1273.629 FPS
>> 6377 frames in 5.0 seconds = 1275.322 FPS
>> 6387 frames in 5.0 seconds = 1277.330 FPS
>> 6407 frames in 5.0 seconds = 1281.337 FPS
>> 6381 frames in 5.0 seconds = 1276.053 FPS
>> 6410 frames in 5.0 seconds = 1281.855 FPS
>> 6405 frames in 5.0 seconds = 1280.905 FPS
>> 6378 frames in 5.0 seconds = 1275.599 FPS
>> ^C
>>
>> ~
>>
>> DRI3:
>>
>> $ cat /etc/X11/xorg.conf.d/nouveau-dri3.conf
>> Section "Device"
>>  Identifier  "Videocard0"
>>  Driver  "nouveau"
>>  Option  "DRI" "3"
>> EndSection
>>
>> $ grep DRI3 /var/log/Xorg.0.log
>> [ 4367.417] (II) NOUVEAU(0): DRI3 on EXA enabled
> 
> For the record, the only acceptable way of checking for DRI3 is to run 
> the program with LIBGL_DEBUG=verbose. Any other solution is wrong.
> 


- DRI2:

[  3210.736] (II) Loading sub module "dri2"
[  3210.736] (II) LoadModule: "dri2"
[  3210.736] (II) Module "dri2" already built-in
[  3210.736] (==) NOUVEAU(0): Allowed maximum DRI level 2.
[  3210.877] (II) NOUVEAU(0): [DRI2] Setup complete
[  3210.894] (II) GLX: Initialized DRI2 GL provider for screen 0


$ LIBGL_DEBUG=verbose vblank_mode=0 glxgears
libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so
ATTENTION: default value of option vblank_mode overridden by environment.
libGL: Using DRI2 for screen 0
6231 frames in 5.0 seconds = 1246.081 FPS
6387 frames in 5.0 seconds = 1277.312 FPS
6421 frames in 5.0 seconds = 1284.023 FPS
6375 frames in 5.0 seconds = 1274.905 FPS
6399 frames in 5.0 seconds = 1279.609 FPS
6440 frames in 5.0 seconds = 1287.837 FPS
6371 frames in 5.0 seconds = 1274.142 FPS
6397 frames in 5.0 seconds = 1279.245 FPS
6429 frames in 5.0 seconds = 1285.668 FPS
6371 frames in 5.0 seconds = 1274.177 FPS
^C

~

- DRI3:

[  3750.992] (II) Loading sub module "dri2"
[  3750.992] (II) LoadModule: "dri2"
[  3750.992] (II) Module "dri2" already built-in
[  3750.992] (**) NOUVEAU(0): Option "DRI" "3"
[  3750.992] (**) NOUVEAU(0): Allowed maximum DRI level 3.
[  3751.128] (II) NOUVEAU(0): [DRI2] Setup complete
[  3751.128] (II) NOUVEAU(0): DRI3 on EXA enabled
[  3751.145] (II) GLX: Initialized DRI2 GL provider for screen 0


$ LIBGL_DEBUG=verbose vblank_mode=0 glxgears
libGL: pci id for fd 4: 10de:06e4, driver nouveau
libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so
ATTENTION: default value of option vblank_mode overridden by environment.
libGL: Using DRI3 for screen 0
7261 frames in 5.0 seconds = 1452.136 FPS
7353 frames in 5.0 seconds = 1470.404 FPS
7354 frames in 5.0 seconds = 1470.652 FPS
7385 frames in 5.0 seconds = 1476.916 FPS
7337 frames in 5.0 seconds = 1467.380 FPS
7344 frames in 5.0 seconds = 1468.661 FPS
7360 frames in 5.0 seconds = 1471.951 FPS
7327 frames in 5.0 seconds = 1465.211 FPS
7345 frames in 5.0 seconds = 1468.992 FPS
7371 frames in 5.0 seconds = 1474.112 FPS
^C

~

$ xfwm4 --version
This is xfwm4 version 4.12.3git.20150825 (revision 20150825) for Xfce 4.12
Released under the terms of the GNU General Public License.
Compiled against GTK+-2.24.28, using GTK+-2.24.28.

Build configuration and supported features:
- Startup notification support: Yes
- XSync support:Yes
- Render support:   Yes
- Xrandr support:   Yes
- Xpresent support: Yes
- Embedded compositor:  Yes
- Epoxy support:No


$ xfconf-query --channel xfwm4 --property /general/use_compositing
true


SW:
xorg-x11-drv-nouveau-1.0.12-0.3.fc22.x86_64
xorg-x11-server-Xorg-1.17.3-1.fc22.x86_64
mesa-dri-drivers-10.6.9-1.20151008.fc22.x86_64
libdrm-2.4.61-3.fc22.x86_64
libXpresent-1.0.0-1.fc22.x86_64
xfwm4-4.12.3-15.1.xpresent.nv34.git20150825.fc22.x86_64


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Ilia Mirkin 
On Wed, Nov 4, 2015 at 3:38 AM, C Bergström  wrote:
> To bring this conversation back on track - where would someone start
> *exactly* to port this to another OS? What kernel dependencies are
> there?

drivers/gpu/drm/nouveau/{nvkm,nvif,usif} can be dropped in wholesale
with just a small handful of shims and helper functions. This is the
code that presents the GPU's internals in a fairly generation-agnostic
way, and also provides some high-level functionality.

drivers/gpu/drm/nouveau/* needs to be ported to the other OS's
infrastructure. If the OS also has a port of linux's DRM and TTM
infrastructures, a lot of that will be able to be taken wholesale.
This is the code that interacts with the core above. Decodes ioctls,
manages memory, performs kernel-side modesetting, etc.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Martin Peres 



On 04/11/15 10:38, C Bergström wrote:

On Wed, Nov 4, 2015 at 3:33 PM, Martin Peres  wrote:

On 04/11/15 09:08, cbergst...@pathscale.com wrote:

Is anyone actually and or actively working on this?
Github.com/pathscale/pscnv is totally bitrot but waaay more portable base.
Nouveau made hard Linux assumptions that will be difficult to overcome
afaik.


As pointed out by Ilia, this is not true anymore. Nouveau can also partially
run in the userspace, the hard dependencies on Linux have been abstracted.

Also, pscnv does not support the newest GPUs and receives no further
development because everything it provided is now provided by Nouveau.

I did mention pscnv was bitrot, but I'm not yet convinced that some of
the key things which are implemented in nouveau were done to a
comparable level of quality (would need to evaluate and don't have
time/interest)
---
To bring this conversation back on track - where would someone start
*exactly* to port this to another OS? What kernel dependencies are
there?


This needs to be ported to the other OS, along with drm and ttm (which I 
believe have already been ported to all the BSDs):

http://cgit.freedesktop.org/~darktama/nouveau/tree/lib/include/nvif/os.h
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread C Bergström 
On Wed, Nov 4, 2015 at 3:33 PM, Martin Peres  wrote:
> On 04/11/15 09:08, cbergst...@pathscale.com wrote:
>
> Is anyone actually and or actively working on this?
> Github.com/pathscale/pscnv is totally bitrot but waaay more portable base.
> Nouveau made hard Linux assumptions that will be difficult to overcome
> afaik.
>
>
> As pointed out by Ilia, this is not true anymore. Nouveau can also partially
> run in the userspace, the hard dependencies on Linux have been abstracted.
>
> Also, pscnv does not support the newest GPUs and receives no further
> development because everything it provided is now provided by Nouveau.

I did mention pscnv was bitrot, but I'm not yet convinced that some of
the key things which are implemented in nouveau were done to a
comparable level of quality (would need to evaluate and don't have
time/interest)
---
To bring this conversation back on track - where would someone start
*exactly* to port this to another OS? What kernel dependencies are
there?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help

2015-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70354

--- Comment #88 from Julien Isorce  ---
(In reply to Ilia Mirkin from comment #87)
> (In reply to Julien Isorce from comment #86)
> > I only tested with patch+workaround, but maybe "patch" is enough. I can try
> > to confirm tomorrow. Thx!
> 
> Please do -- the workaround is necessary for a fraction of users. We're
> unsure when it's safe to enable.

I confirm the workaround "options nouveau config=War00C800_0=1" is required
too.

You can find the two lspci outputs in comment #75 and #81 (mine).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Martin Peres 

On 04/11/15 09:08, cbergst...@pathscale.com wrote:
Is anyone actually and or actively working on this? 
Github.com/pathscale/pscnv is totally bitrot but waaay more portable 
base. Nouveau made hard Linux assumptions that will be difficult to 
overcome afaik.


As pointed out by Ilia, this is not true anymore. Nouveau can also 
partially run in the userspace, the hard dependencies on Linux have been 
abstracted.


Also, pscnv does not support the newest GPUs and receives no further 
development because everything it provided is now provided by Nouveau.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92307] G98/GM206: WARNING: ... at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()

2015-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=92307

--- Comment #8 from poma  ---
(In reply to poma from comment #7)
> FTR procedure:
> 
> $ uname -r
> 4.3.0-0.rc6.git2.1.fc24.x86_64
> 
> $ git clone git://people.freedesktop.org/~darktama/nouveau
> $ cd nouveau/drm/
> $ make
> $ su
> 
> # cp nouveau/nouveau.ko /usr/lib/modules/$(uname -r)/updates/
> # depmod
> # dracut --kver $(uname -r) -f
> # systemctl reboot


Update to commit f787ef9

nouveau/drm/nouveau/nouveau_drm.c:935:24: error: ‘drm_vblank_no_hw_counter’
undeclared here (not in a function)
  .get_vblank_counter = drm_vblank_no_hw_counter,
^

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Pierre Moreau 
Wasn't there some work being done by François Tigeot or Jean-Sébastien Pédron
to port Nouveau to DragonFlyBSD/FreeBSD? Or at least they were talking about 
porting it
at XDC 2014, no idea what the current status is.

Pierre

PS: Looking at François' slides from this year XDC, it seems there isn't much
progress about it.


On 10:44 AM - Nov 04 2015, Martin Peres wrote:
> 
> 
> On 04/11/15 10:38, C Bergström wrote:
> >On Wed, Nov 4, 2015 at 3:33 PM, Martin Peres  wrote:
> >>On 04/11/15 09:08, cbergst...@pathscale.com wrote:
> >>
> >>Is anyone actually and or actively working on this?
> >>Github.com/pathscale/pscnv is totally bitrot but waaay more portable base.
> >>Nouveau made hard Linux assumptions that will be difficult to overcome
> >>afaik.
> >>
> >>
> >>As pointed out by Ilia, this is not true anymore. Nouveau can also partially
> >>run in the userspace, the hard dependencies on Linux have been abstracted.
> >>
> >>Also, pscnv does not support the newest GPUs and receives no further
> >>development because everything it provided is now provided by Nouveau.
> >I did mention pscnv was bitrot, but I'm not yet convinced that some of
> >the key things which are implemented in nouveau were done to a
> >comparable level of quality (would need to evaluate and don't have
> >time/interest)
> >---
> >To bring this conversation back on track - where would someone start
> >*exactly* to port this to another OS? What kernel dependencies are
> >there?
> 
> This needs to be ported to the other OS, along with drm and ttm (which I
> believe have already been ported to all the BSDs):
> http://cgit.freedesktop.org/~darktama/nouveau/tree/lib/include/nvif/os.h
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Martin Peres 

On 04/11/15 11:58, Pierre Moreau wrote:

Wasn't there some work being done by François Tigeot or Jean-Sébastien Pédron
to port Nouveau to DragonFlyBSD/FreeBSD? Or at least they were talking about 
porting it
at XDC 2014, no idea what the current status is.


From what they said, they never really cared about nvidia because 
nvidia provides a binary driver that works, unlike intel and amd.


I guess it will come some day!
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NOUVEAU(0): DRI3 on EXA enabled

2015-11-04 Thread Martin Peres 

On 02/11/15 08:28, poma wrote:

An interesting results.

DRI2:

$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
6321 frames in 5.0 seconds = 1264.103 FPS
6380 frames in 5.0 seconds = 1275.943 FPS
6369 frames in 5.0 seconds = 1273.629 FPS
6377 frames in 5.0 seconds = 1275.322 FPS
6387 frames in 5.0 seconds = 1277.330 FPS
6407 frames in 5.0 seconds = 1281.337 FPS
6381 frames in 5.0 seconds = 1276.053 FPS
6410 frames in 5.0 seconds = 1281.855 FPS
6405 frames in 5.0 seconds = 1280.905 FPS
6378 frames in 5.0 seconds = 1275.599 FPS
^C

~

DRI3:

$ cat /etc/X11/xorg.conf.d/nouveau-dri3.conf
Section "Device"
Identifier  "Videocard0"
Driver  "nouveau"
Option  "DRI" "3"
EndSection

$ grep DRI3 /var/log/Xorg.0.log
[ 4367.417] (II) NOUVEAU(0): DRI3 on EXA enabled


For the record, the only acceptable way of checking for DRI3 is to run 
the program with LIBGL_DEBUG=verbose. Any other solution is wrong.


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Jean-Sébastien Pédron 
On 04.11.2015 11:56, Martin Peres wrote:
> From what they said, they never really cared about nvidia because nvidia
> provides a binary driver that works, unlike intel and amd.

They provide a binary driver for FreeBSD only. DragonFly and other BSDs
don't have that luxury.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

2015-11-04 Thread Jean-Sébastien Pédron 
On 04.11.2015 10:58, Pierre Moreau wrote:
> Wasn't there some work being done by François Tigeot or Jean-Sébastien Pédron
> to port Nouveau to DragonFlyBSD/FreeBSD? Or at least they were talking about 
> porting it
> at XDC 2014, no idea what the current status is.
> 
> Pierre
> 
> PS: Looking at François' slides from this year XDC, it seems there isn't much
> progress about it.

Hi!

Pierre, you're right, and the same applies to FreeBSD: nobody started to
work on this.

I will let François comment for DragonFly, but on FreeBSD, our problem
is that the diff with Linux was too large to do an easy port of a
driver. This was fixed in DRM core earlier this year, and I'm about to
finish an update to i915 which is the last part to finally have a small
diff with Linux. At that point our entire DRM subsystem will correspond
to Linux 3.8 (minus dma-buf).

At that point, it will be far easier to contribute to FreeBSD. As Martin
said, TTM is already ported so I believe everything is in place to port
Nouveau.

In the coming months, the goal will be to bring our DRM subsystem to
match Linux 3.9 then 3.10, etc. I personnally have no plan to work on
Nouveau for the time being because the i915 and Radeon drivers are
enough to keep me busy. However, we would welcome any contributions!
People are asking about this on a regular basis, so please contact me if
you are willing to work on this.

Soon, we'll see Tux proudly holding a trident in the logo! :)

(Don't get me wrong, I love the current logo)

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau