Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
6th January 2017, 00:22 | #41 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
The GitHub project contains 3 sample filters
https://github.com/mysteryx93/AvsFil...oadImageNet.cs https://github.com/mysteryx93/AvsFil...leSampleNet.cs https://github.com/mysteryx93/AvsFil...rProcessNet.cs |
24th February 2017, 01:50 | #42 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
I just saw this: MONO supports SIMD instructions on both x86 and x64.
http://www.mono-project.com/news/201...meric-vectors/ but then it adds the MONO dependency. Not ideal, but it's an option. |
1st March 2017, 02:00 | #43 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Mono? What for? Let's start from the very begging, 'cause maybe I didn't get this right. (I mean, maybe I didn't understand what you are trying to do/achieve). If you write and compile filters using C and C++ you have access to SIMD, but the problem is that you need to know at compile time which instructions are available on your target machine. You need to be certain that the instructions in your binary are available on the target processor, but this is where a managed language’s JIT compiler is well placed. C# (thanks to the .NET Framework) code is compiled to an intermediate language called "Common Intermediate Language" (CIL, aka Microsoft Intermediate Language, MSIL), which is deployed to the target machine. When a program written in C# is loaded, the local .NET JIT compiler compiles the CIL to native code. The advantage is that the JIT compiler knows exactly what type of CPU the target machine has and so it can make full use of all instruction sets available to it. Besides, the application’s performance will improve in the future without ever being rebuilt and re-deployed. When future processors with larger SIMD registers become available JIT will be able to make full use them. The simplest and recommended way to use SIMD is via the classes and static methods in the System.Numerics namespace and you need at least version 4.1.0.0 of the System.Numerics and System.Numerics.Vectors assemblies. Anyway, let's stop talking about programs now. In this topic we are talking about avisynth filters that are going to run via a sort of "compatibility layer" which will make C# codes available in C++, like a "wrapper" - as you said before - which is the AVS filternet, so performance-wise it will be slower than native C++ filters, no matter what. So, the question is: what are you trying to do/achieve with SIMD? (I mean, this is not a critic at all, I'm just trying to understand, 'cause I love C#).
Last edited by FranceBB; 1st March 2017 at 02:08. |
1st March 2017, 03:31 | #44 | Link |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
No, you don't need to know which instruction sets are available at compile time with C/C++, basically you compile everything (even tho some might not be supported on your target machine) you have and use the cpuid instruction and detect the available best instruction set on the target machine at runtime and call the version of functions that were implemented with the detected best available instruction set dynamically.
|
1st March 2017, 16:15 | #45 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
I'm still exploring what can be done with C#, because I'm a C# programmer and have no interest in learning assembly.
For a utility filter like MP_Pipeline, C# could do an excellent job -- and pass the video clips as input and output instead of ignoring the input. If SIMD instructions become available, then it would also become possible to do video processing filters. It may still be a bit slower than C++, but on the plus side, the development time would be much shorter, and the maintenance would be much easier. We have a whole bunch of C++ plugins that are old and have never been maintained/updated, although many of the most useful ones are being upgraded for Avisynth+ x64. This is not about whether C# or C++ is best. This discussion is simply about what can be done with C# and Avisynth. The .NET Framework now has SIMD support, but only for x64. Avisynth filters need to work both with x86 and x64. MONO apparently does that, but I wouldn't want to create that dependency for users. |
1st March 2017, 17:27 | #46 | Link | ||
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
Quote:
Code:
//C++ 14 auto CPU = CPUFeatures{}; //yep, like the "var" feature in C#, you don't need to manually specify the variable types anymore in modern C++ //it's actually ok to just program in modern C++ like how you program in Python //you don't have to care about types (auto and decltype), manual garbage collection (replaced by smart pointers) and tons of ugly shit inherited from C if (CPU.sse2) blah else if (CPU.avx) blah else if (CPU.blah) blah else blah Quote:
simply pointing out that some people have been misunderstanding C++ like how they assumed runtime hardware detection would be a problem in C++ C++17 is coming soon and they still have C++98 or even C in their mind and that's why they still have so much "fear" over C++ Last edited by feisty2; 1st March 2017 at 17:30. |
||
1st March 2017, 17:59 | #47 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
I think c# better for gui things, not for complex tasks like mp_pipeline
MysteryX, you say you will make AVSEdit work in x64 before, I think this better than mess with mpp in c#
__________________
See My Avisynth Stuff |
2nd March 2017, 16:44 | #48 | Link | |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
But that still doesn't write any assembly. Even if dealing with that challenge I hadn't seen, one must still learn to write assembly and write assembly code for the various CPU infrastructures. |
|
2nd March 2017, 16:54 | #49 | Link | |
Registered User
Join Date: Jun 2012
Location: Ibiza, Spain
Posts: 321
|
Quote:
|
|
3rd March 2017, 02:20 | #50 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Quote:
Quote:
Anyway, we are talking about avisynth filters here; that's a whole different scenario. |
||
3rd March 2017, 23:02 | #51 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
There are lots of C++ programs that auto-detect your CPU type and add assembly optimizations accordingly. FFMPEG and x264 are full of such optimizations.
It depends on how the code is structured and how the optimizations are implemented. There are other projects that require a different DLL per CPU type -- which is the case when you use compiler optimizations. |
3rd March 2017, 23:20 | #52 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
It depends. The Intel C/C++ compiler for example has an automatic CPU dispatcher, no need to build multiple binaries.
__________________
Groucho's Avisynth Stuff |
21st March 2017, 23:21 | #53 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
AvsFilterNet v1.0.3 is ready!
What's new: - Fixed crash when an expection is thrown - Can now initialize filter without child - Fixed the code of LoadImageNet sample - Added LoadAllPlugins sample that calls LoadPlugin and then calls the function - Compiled with Visual Studio 2017 |
22nd March 2017, 17:04 | #54 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
AvsFilterNet v1.0.4 is ready!
What's new: - Error messages no longer include full stack trace - Overriding GetFrame function is now optional |
Tags |
.net, avisynth, filter |
Thread Tools | Search this Thread |
Display Modes | |
|
|