Bug#882980: It works, thanks a lot

[Sergey Sharybin]

Hi,

Nice to hear the issue is solved for you!

Wouldn't really consider this a bug, we are switching to Occlusion
Queries selection mode by default for Blender 2.8x.

On Wed, 29 Nov 2017 11:26:05 +0100 Christian Combes
 wrote:
> Hi,
>
> I went to - Blender User Preferences - System - Selection and I switched
> the  "Automatic" - option to "OpenGL Occlusion Queries" and it works fine
> for me. I have tried with the official build Blender 2.79 and the latest
> build from November 29.
>
> Really thanks for your skills, it was quiet annoying to work with this
> problem
>
> Have a nice day, Chris

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#882980: blender: 3d view artifacts when selecting vertices, edges or faces

[Sergey Sharybin]

Hi,

Please try various values for "Window Draw Method" and "Selection" in
User Preferences -> System. Preferred windows draw method is Triple
Buffer, so start with explicitly using that instead of Automatic. And
see if any selection method makes things to work.

If that doesn't help, please test with official builds from
blender.org and see if the issue happens there.

If possible, it also worth testing if latest drivers from NVidia for
your GPU makes a difference.

Regards,
Sergey Sharybin

On Tue, 28 Nov 2017 11:34:49 +0100 Chris <chris.com...@gmail.com> wrote:
> Source: blender
> Severity: normal
>
> Dear Maintainer,
>
> When in 3d view I select a vertice, or edge or face, little squares come out 
> on the objet, displaying
> the foreground through the object.
> When I move the 3D view, artifacts disappear.
>
> Thanks, have a nice day.
>
> -- System Information:
> Debian Release: 9.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> NVIDIA UNIX x86_64 Kernel Module  375.82-1~deb9u1 (I have tried too the 
> Backport driver 375.82-9~bpo9+1)
> GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18)
>
> Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
>

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#843490: blender: Movie clip editor does not update video view when playing (fixed in 2.78)

[Sergey Sharybin]

Hi,

Several questions to understand thing a bit more:

- Does this issue happen with any video? (try exporting shor mkv file
from blender and opening it back in clip editor)
- Does this issue happen with factory settings (File -> Load Factory Settings) ?
- Does this issue happen with blender 2.77 from blender.org site [1]
- When you say it works in 2.78. do you refer to 2.78 release from blender.org?

[1] download.blender.org/release/Blender2.77

-- 
With best regards, Sergey Sharybin

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#843425: Fwd: Bug#843425: blender doesn't optimize for amd64 defaults

[Sergey Sharybin]

Hi again, and sorry for too much noise..

I've checked the compiler output of i386 build of blender from [1] and
there's such status print:

-- SSE and SSE2 optimizations are DISABLED!

Meaning, there's no SSE/SSE2 global optimization of i386 builds of
Blender in Debian already (thanks to Matteo i guess :)

Is there anything else here to be solved?

[1] https://buildd.debian.org/status/package.php?p=blender

On Mon, Nov 7, 2016 at 10:52 AM, Sergey Sharybin <ser...@blender.org> wrote:
> Ah, it's Pemtium 4 where SSE2 first arrived, for a moment thought it's
> Pentium Pro. My bad..
>
> So for both i386 and i686 SSE2 requirement is not valid.
>
> Currently in Blender upstream we detect SSE/SSE2 flags based on
> current CPU. Meaning, if you're builing on i686 CPU Blender should
> already have global SSE2 optimization disabled. If CPU on the builder
> machine supports SSE2 we can still force SSE/SSE2 optimization to be
> off by passing `-DSUPPORT_SSE_BUILD=OFF -DSUPPORT_SSE2_BUILD=OFF` to
> CMake.
>
> On Mon, Nov 7, 2016 at 10:40 AM, Matthias Klose <d...@debian.org> wrote:
>> On 07.11.2016 10:32, Sergey Sharybin wrote:
>>> Hi,
>>>
>>> Afraid the reply to #843425 was only delivered to the BTS and not easily
>>> visible to you guys.
>>>
>>> Here's the full reply, same as [1]. Just so you know :)
>>>
>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843425#10
>>>
>>>
>>> -- Forwarded message --
>>> From: Sergey Sharybin <ser...@blender.org>
>>> Date: Mon, Nov 7, 2016 at 9:50 AM
>>> Subject: Bug#843425: blender doesn't optimize for amd64 defaults
>>> To: 843...@bugs.debian.org
>>>
>>>
>>> Hi,
>>>
>>> From the report it's not fully clear what parts Blender those CFLAGS
>>> are referencing to, but because it's all within a context of #843379 i
>>> would guess we are talking about Cycles kernel here (Cycles is the
>>> render engine we use in Blender).
>>>
>>> In this case you're partially correct: we are mainly ignoring default
>>> CFLAGS but we compile 6 different CPU kernels, optimized for various
>>> microarchitectures ("native" - no SSE2 on i686 / SSE2 on amd64, forced
>>> SSE2, SSE3, SSE4.1, AVX and AVX2). Then during runtime we detect
>>> current CPU microarchitecture and invoke kernel with highest
>>> capabilities allowed on the current processor.
>>>
>>> This is the only way we can guarantee optimal render times on amd64.
>>> Keep in mind, AVX2 can render similar scene like 2x faster than simple
>>> SSE2. This is something we can not ignore for our users.
>>
>> well, the GCC issue was opened with a RC severity, so I assumed that 
>> everything
>> was built using these flags. The assumption of amd64 having SSE2 enabled by
>> defaults is valid.
>>
>>> That being said, if you have some tricky setup where we do not detect
>>> capabilities correctly and Cycles tries to use unsupported kernel and
>>> runs into ILLEGAL INSTRUCTION i'll be happy to look into and solve
>>> that from our end.
>>>
>>> Now, about forcing microarchitecture in rest of Blender. We do require
>>> SSE2 on amd64 and i686, but that should be all fine as far as i know
>>> (amd64 always have SSE2, 32bit builds will disable SSE2 automatically
>>> if current CPU does not support it).
>>
>> For Debian it is not ok to assume SSE2 on the i386 architecture.
>>
>> Matthias
>>
>
> --
> With best regards, Sergey Sharybin



-- 
With best regards, Sergey Sharybin

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#843425: Fwd: Bug#843425: blender doesn't optimize for amd64 defaults

[Sergey Sharybin]

Ah, it's Pemtium 4 where SSE2 first arrived, for a moment thought it's
Pentium Pro. My bad..

So for both i386 and i686 SSE2 requirement is not valid.

Currently in Blender upstream we detect SSE/SSE2 flags based on
current CPU. Meaning, if you're builing on i686 CPU Blender should
already have global SSE2 optimization disabled. If CPU on the builder
machine supports SSE2 we can still force SSE/SSE2 optimization to be
off by passing `-DSUPPORT_SSE_BUILD=OFF -DSUPPORT_SSE2_BUILD=OFF` to
CMake.

On Mon, Nov 7, 2016 at 10:40 AM, Matthias Klose <d...@debian.org> wrote:
> On 07.11.2016 10:32, Sergey Sharybin wrote:
>> Hi,
>>
>> Afraid the reply to #843425 was only delivered to the BTS and not easily
>> visible to you guys.
>>
>> Here's the full reply, same as [1]. Just so you know :)
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843425#10
>>
>>
>> -- Forwarded message --
>> From: Sergey Sharybin <ser...@blender.org>
>> Date: Mon, Nov 7, 2016 at 9:50 AM
>> Subject: Bug#843425: blender doesn't optimize for amd64 defaults
>> To: 843...@bugs.debian.org
>>
>>
>> Hi,
>>
>> From the report it's not fully clear what parts Blender those CFLAGS
>> are referencing to, but because it's all within a context of #843379 i
>> would guess we are talking about Cycles kernel here (Cycles is the
>> render engine we use in Blender).
>>
>> In this case you're partially correct: we are mainly ignoring default
>> CFLAGS but we compile 6 different CPU kernels, optimized for various
>> microarchitectures ("native" - no SSE2 on i686 / SSE2 on amd64, forced
>> SSE2, SSE3, SSE4.1, AVX and AVX2). Then during runtime we detect
>> current CPU microarchitecture and invoke kernel with highest
>> capabilities allowed on the current processor.
>>
>> This is the only way we can guarantee optimal render times on amd64.
>> Keep in mind, AVX2 can render similar scene like 2x faster than simple
>> SSE2. This is something we can not ignore for our users.
>
> well, the GCC issue was opened with a RC severity, so I assumed that 
> everything
> was built using these flags. The assumption of amd64 having SSE2 enabled by
> defaults is valid.
>
>> That being said, if you have some tricky setup where we do not detect
>> capabilities correctly and Cycles tries to use unsupported kernel and
>> runs into ILLEGAL INSTRUCTION i'll be happy to look into and solve
>> that from our end.
>>
>> Now, about forcing microarchitecture in rest of Blender. We do require
>> SSE2 on amd64 and i686, but that should be all fine as far as i know
>> (amd64 always have SSE2, 32bit builds will disable SSE2 automatically
>> if current CPU does not support it).
>
> For Debian it is not ok to assume SSE2 on the i386 architecture.
>
> Matthias
>

-- 
With best regards, Sergey Sharybin

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#843425: blender doesn't optimize for amd64 defaults

[Sergey Sharybin]

Hi,

>From the report it's not fully clear what parts Blender those CFLAGS
are referencing to, but because it's all within a context of #843379 i
would guess we are talking about Cycles kernel here (Cycles is the
render engine we use in Blender).

In this case you're partially correct: we are mainly ignoring default
CFLAGS but we compile 6 different CPU kernels, optimized for various
microarchitectures ("native" - no SSE2 on i686 / SSE2 on amd64, forced
SSE2, SSE3, SSE4.1, AVX and AVX2). Then during runtime we detect
current CPU microarchitecture and invoke kernel with highest
capabilities allowed on the current processor.

This is the only way we can guarantee optimal render times on amd64.
Keep in mind, AVX2 can render similar scene like 2x faster than simple
SSE2. This is something we can not ignore for our users.

That being said, if you have some tricky setup where we do not detect
capabilities correctly and Cycles tries to use unsupported kernel and
runs into ILLEGAL INSTRUCTION i'll be happy to look into and solve
that from our end.

Now, about forcing microarchitecture in rest of Blender. We do require
SSE2 on amd64 and i686, but that should be all fine as far as i know
(amd64 always have SSE2, 32bit builds will disable SSE2 automatically
if current CPU does not support it).

-- 
With best regards, Sergey Sharybin

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#783983: blender: VSE stretches video segments and uses incorrect video starting point

[Sergey Sharybin]

Hi,

This is likely due to official builds using FFmpeg and Debian's builds
using Libav library to handle video files.

It'll be cool if upstream Blender supported both Libav and FFmpeg version
at the same level, but it might also be simply a bug in Libav.. In order to
investigate this further it'll help a lot having exact files which
demonstrates the issue.

On Fri, 1 May 2015 16:08:17 -0400 sudo...@ninthfloor.org wrote:
 Package: blender
 Version: 2.72.b+dfsg0-3
 Severity: important

 Dear Maintainer,

 this was not an issue in wheezy but it is in jessie and experimental.
 the 2.74 binaries from blender.org do work.

 to reproduce the first aspect of this bug, select the video editing mode
 and add a long movie. increase the end point of playback range to 30
 at the bottom of the screen. (this is the maximum.) then zoom out on the
 clips using the middle scroll wheel. then drag the green line over the
 clips and watch the playback in the upper right hand corner.

 what i expected to see was the full movie playing at a fast pace. what i
 saw was a shorter clip playing back (rather quickly) instead. if you
 click the play button, the video continues from that point at normal
 speed, which makes sense i guess. i'm not sure what happens when
 rendering from this state.

 the other bug occurs when opening a blender file from the wheezy or
 blender.org version of blender in the jessie (or experimental) version
 of blender. opening the file in blender.org's version works.

 in those files, i see the same issue as above, however i also see that
 the soft cuts points (i haven't tested hard cuts) seem to be ignored.
 even if a clip started from the middle of a movie in wheezy, it
 incorrectly starts from the beginning in the VSE when using jessie's
 version of blender. if i render that video, the starting point of the
 video clip is incorrect. audio seems to be unaffected.

 thanks for all of your hard work, dear maintainer!
 -Andrew


 -- System Information:
 Debian Release: 8.0
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable'), (350,
'experimental'), (350, 'unstable')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 Versions of packages blender depends on:
 ii  blender-data  2.72.b+dfsg0-3
 ii  fonts-droid   1:4.4.4r2-6
 ii  libavcodec56  6:11.3-1
 ii  libavdevice55 6:11.3-1
 ii  libavformat56 6:11.3-1
 ii  libavutil54   6:11.3-1
 ii  libboost-date-time1.55.0  1.55.0+dfsg-3
 ii  libboost-filesystem1.55.0 1.55.0+dfsg-3
 ii  libboost-locale1.55.0 1.55.0+dfsg-3
 ii  libboost-regex1.55.0  1.55.0+dfsg-3
 ii  libboost-system1.55.0 1.55.0+dfsg-3
 ii  libboost-thread1.55.0 1.55.0+dfsg-3
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#771042: blender: Blender crashes while rendering with cycles

[Sergey Sharybin]

Hi,

Still wasn't able to reproduce the issue, but made some changes which
could potentially solve this bug.

The was caused by some devices (such as CUDA) allocating memory from
single thread, when other devices (such as CPU) could allocate memory
from several threads, screwing up the memory statistics.

Here's a patch committed to the upstream:
https://developer.blender.org/rBed935ae5adf8d676bb002380d4f46a288c6572d0

Even if it doesn't fix this particular bug it's nice to have it anyway.

-- 
With best regards, Sergey Sharybin

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures

[Sergey Sharybin]

Hi again,

Commited patch to support more platforms to our trunk
(http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=43716)
Hope it'll help make more users and platform maintainers happier,
thanks to Kevin for it.

I don't have sparc platform at all, so seeing error log would help a
lot. Maybe build errors from build servers can be browsed by external
users?

On Thu, Jan 26, 2012 at 2:31 PM, Matteo F. Vescovi mfv.deb...@gmail.com wrote:

 Hi!


 On 25/01/2012 21:05, Kevin Roy wrote:

 As far as I and others have tested the patch, builds are now ok on ARM
 and KFreeBSD. I'm not sure on others but debian buildd servers will tell
 us :) .


 It builds fine even on ia64... it has been tested last night.
 But actually it doesn't build on sparc machines :-(

 Let's see how the buildd-situation evolves.

 Cheers.

 --
 Matteo F. Vescovi
 Debian Sponsored Maintainer
 e-mail: mfv.deb...@gmail.com
 GnuPG KeyID: 83B2CF7A




--
With best regards, Sergey Sharybin



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures

[Sergey Sharybin]

Ok, looked through logs. Commited fix (rev43718 in our svn trunk)
which should make some platforms work nicer (at least fix currently
reported compilation errors). This should help on spark, s390x, s390,
mips platforms.

Still can see some issues related on REG_EIP and mcontext_t things.
Not sure if that build errors happens with 0011-fix_FTBFS_with_libmv
applied?

Also think error of hurd-i386 should be fixed. At least this function
has got valid return value in current trunk.

Probably compilation error on powerpc is also fixed in svn rev43719.

Would be nice to check for updated build logs after all this my changes.

-- 
With best regards, Sergey Sharybin



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures

[Sergey Sharybin]

Hi,

We've got quite the same error with FreeBSD support. Attached patch
should fix this issue.

If it will still fail, would be helpful to have config.h generated by
configure script of glog itself (which can be found here
http://code.google.com/p/google-glog/). But if proposed patch will
work fine, it can be commited to trunk.

--
With best regards, Sergey Sharybin
Index: extern/libmv/third_party/glog/src/config_linux.h
===
--- extern/libmv/third_party/glog/src/config_linux.h	(revision 43691)
+++ extern/libmv/third_party/glog/src/config_linux.h	(working copy)
@@ -133,6 +133,8 @@
 /* How to access the PC from a struct ucontext */
 #if defined(_M_X64) || defined(__amd64__) || defined(__x86_64__)
   #define PC_FROM_UCONTEXT uc_mcontext.gregs[REG_RIP]
+#elif defined(IA64)
+  #undef PC_FROM_UCONTEXT
 #else
   #define PC_FROM_UCONTEXT uc_mcontext.gregs[REG_EIP]
 #endif
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures

[Sergey Sharybin]

Hi,

Good patch, don't think mine is needed to be added (the same changes
are already made). Don't have access to non-i386/amd64 machines, but
0011-fix_FTBFS_with_libmv.patch looks fine and if it's indeed resolves
build issues i would be happy to commit it to blender's trunk.

On Wed, Jan 25, 2012 at 11:40 PM, Kevin Roy kin...@gmail.com wrote:
 I think the patch 0011-fix_FTBFS_with_libmv [1] in git will cover
 configs other than i386/amd64 but in doubt, could you look at it and
 tell me if yours is need to be added?

-- 
With best regards, Sergey Sharybin



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers