orc issueshttps://gitlab.freedesktop.org/gstreamer/orc/-/issues2024-01-26T09:26:16Zhttps://gitlab.freedesktop.org/gstreamer/orc/-/issues/1Improve SELinux support by introducing subdirs and by changing the order of t...2024-01-26T09:26:16ZBugzilla Migration UserImprove SELinux support by introducing subdirs and by changing the order of the intermediate file locations## Submitted by Fabian Deutsch
**[Link to original bug (#735871)](https://bugzilla.gnome.org/show_bug.cgi?id=735871)**
## Description
This bug also exists here:
https://bugs.freedesktop.org/show_bug.cgi?id=41446
To help writi...## Submitted by Fabian Deutsch
**[Link to original bug (#735871)](https://bugzilla.gnome.org/show_bug.cgi?id=735871)**
## Description
This bug also exists here:
https://bugs.freedesktop.org/show_bug.cgi?id=41446
To help writing selinux rules for orc two changes are introduced:
1. Use a subdir for intermediate files
2. Change the order of potential locations for the intermediate files
The attached patches add this functionality.https://gitlab.freedesktop.org/gstreamer/orc/-/issues/4REGRESSION: parameter loading undefined behaviour - Severely distorted sound ...2024-01-26T09:26:16ZBugzilla Migration UserREGRESSION: parameter loading undefined behaviour - Severely distorted sound on changing volume of stream in pulseaudio## Submitted by Alain Kalker
**[Link to original bug (#742271)](https://bugzilla.gnome.org/show_bug.cgi?id=742271)**
## Description
Created attachment 293666
Arch linux build script for building orc from git
Using Arch Linux ...## Submitted by Alain Kalker
**[Link to original bug (#742271)](https://bugzilla.gnome.org/show_bug.cgi?id=742271)**
## Description
Created attachment 293666
Arch linux build script for building orc from git
Using Arch Linux x86_64 with pulseaudio 5.0-1, orc 0.4.23-1, I'm getting severely distorted audio after I change the volume of a stream, even by just a little.
Steps to reproduce
$ pulseaudio -k
$ # restart pulseaudio if it doesn't start automatically on first use
$ man man | espeak # Generate some audio, varying dynamics.
In pavucontrol, move the volume slider for the espeak application stream just a little.
Actual result: severely distorted audio (almost like white noise, barely discernible speech from espeak).
Expected result: clear audio for reasonable volume settings.
The problem does not occur for orc 0.4.22 .
Building an Arch linux package of orc from git[1], I was able to bisect the problem to this first bad commit:
http://cgit.freedesktop.org/gstreamer/orc/commit/?id=a62eefc1dc716046d99aacec208cfdfe42dadb34
Suspecting a breaking ABI change (because of the added struct members), I rebuilt and reinstalled pulseaudio[2], but to no avail, sound remains distorted.
[1]: See attached PKGBUILD.orc-git
[2]: See attached PKGBUILD.pulseaudio
**Attachment 293666**, "Arch linux build script for building orc from git":
[PKGBUILD.orc-git](/uploads/6af834327c7463b9991ae237d6d05992/PKGBUILD.orc-git)https://gitlab.freedesktop.org/gstreamer/orc/-/issues/5ORC compiler is disabled on the iOS devices2024-01-26T09:26:16ZBugzilla Migration UserORC compiler is disabled on the iOS devices## Submitted by Denis
**[Link to original bug (#742843)](https://bugzilla.gnome.org/show_bug.cgi?id=742843)**
## Description
Here’s the ORC output in log. Init stage:
ORC: INFO: orcdebug.c(70): void _orc_debug_init()(): orc-0.4...## Submitted by Denis
**[Link to original bug (#742843)](https://bugzilla.gnome.org/show_bug.cgi?id=742843)**
## Description
Here’s the ORC output in log. Init stage:
ORC: INFO: orcdebug.c(70): void _orc_debug_init()(): orc-0.4.23.1 debug init
ORC: INFO: orcprogram-neon.c(129): void orc_neon_init()(): marking neon backend non-executable
and then there’s continuous warnings like this one during the pipeline execution:
ORC: WARNING: orccompiler.c(392): OrcCompileResult orc_program_compile_full(OrcProgram *, OrcTarget *, unsigned int)(): program orc_combine4_12xn_u8 failed to compile, reason: Compilation disabled, using emulation
There’s nothing more specific about why NEON is disabled but tracing with debugger shows that orc_arm_get_cpu_flags in orccpu-arm.c has practically no executable code for IOS (one branch is #if'd for linux only and one for Android-only) and will always return 0 (which means no NEON support).
Verified on iPad 3rd gen and iPad mini 1st gen.
If i apply a hack to orc_arm_get_cpu_flags to return NEON flag support ORC compiler is enabled and works well on the iPad mini 1st gen. On the iPad 3rd gen i’m getting segfaults from different gstreamer->orc bridges like video_orc_chroma_up_v2_u8 (videoscale plugin), video_test_src_orc_splat_u32 (videotestsrc) etc.
per hw info iPad 3rd get uses A5x chip while iPad mini (1st gen) uses A5 so that’s really strange why orc works ok with 2nd but not with 1st.
Example stack trace for the iPad 3 segfault:
```
#0 0x02ec8e90 in 0x02ec8e90 ()
#1 0x003d7138 in video_test_src_orc_splat_u32 at /Users/D/cerbero/sources/ios_universal/armv7/gst-plugins-base-1.0-static-1.5/gst/videotestsrc/tmp-orc.c:215
#2 0x003d71fc in gst_video_test_src_smpte at /Users/D/cerbero/sources/ios_universal/armv7/gst-plugins-base-1.0-static-1.5/gst/videotestsrc/videotestsrc.c:350
#3 0x003d6c9a in gst_video_test_src_fill at /Users/D/cerbero/sources/ios_universal/armv7/gst-plugins-base-1.0-static-1.5/gst/videotestsrc/gstvideotestsrc.c:951
#4 0x00a60a80 in gst_base_src_default_create at /Users/D/cerbero/sources/ios_universal/armv7/gstreamer-1.0-1.5/libs/gst/base/gstbasesrc.c:1482
#5 0x00a5d0ae in gst_base_src_get_range at /Users/D/cerbero/sources/ios_universal/armv7/gstreamer-1.0-1.5/libs/gst/base/gstbasesrc.c:2455
#6 0x00a5c8de in gst_base_src_loop at /Users/D/cerbero/sources/ios_universal/armv7/gstreamer-1.0-1.5/libs/gst/base/gstbasesrc.c:2731
#7 0x00acaeec in gst_task_func at /Users/D/cerbero/sources/ios_universal/armv7/gstreamer-1.0-1.5/gst/gsttask.c:316
#8 0x0093f26c in g_thread_pool_thread_proxy at /Users/D/cerbero/sources/ios_universal/armv7/glib-2.42.0/glib/gthreadpool.c:307
#9 0x00942156 in g_thread_proxy at /Users/D/cerbero/sources/ios_universal/armv7/glib-2.42.0/glib/gthread.c:764
#10 0x38502e66 in _pthread_body ()
#11 0x38502dda in _pthread_start ()
```
Variables for frame 1:
d1 guint8 * "" 0x03181000
p1 int -2139034625 -2139034625
n int 91 91
_ex OrcExecutor
program OrcProgram * NULL 0x00000000
n int 91 91
counter1 int 108279884 108279884
counter2 int 460800 460800
counter3 int 16 16
arrays void *[64]
params int [64]
accumulators int [4]
ex OrcExecutor * NULL 0x00000000
program OrcProgram * NULL
n int
counter1 int
counter2 int
counter3 int
arrays void *[64]
params int [64]
accumulators int [4]
func void (*)(OrcExecutor *) NULL
p OrcProgram * NULL
Code
void
video_test_src_orc_splat_u32 (guint8 * ORC_RESTRICT d1, int p1, int n)
{
OrcExecutor _ex, *ex = &_ex;
static volatile int p_inited = 0;
static OrcCode *c = 0;
void (*func) (OrcExecutor *);
if (!p_inited) {
orc_once_mutex_lock ();
if (!p_inited) {
OrcProgram *p;
#if 1
static const orc_uint8 bc[] = {
1, 9, 28, 118, 105, 100, 101, 111, 95, 116, 101, 115, 116, 95, 115, 114,
99, 95, 111, 114, 99, 95, 115, 112, 108, 97, 116, 95, 117, 51, 50, 11,
4, 4, 16, 4, 128, 0, 24, 2, 0,
};
p = orc_program_new_from_static_bytecode (bc);
orc_program_set_backup_function (p, _backup_video_test_src_orc_splat_u32);
#else
p = orc_program_new ();
orc_program_set_name (p, "video_test_src_orc_splat_u32");
orc_program_set_backup_function (p, _backup_video_test_src_orc_splat_u32);
orc_program_add_destination (p, 4, "d1");
orc_program_add_parameter (p, 4, "p1");
orc_program_append_2 (p, "storel", 0, ORC_VAR_D1, ORC_VAR_P1, ORC_VAR_D1, ORC_VAR_D1);
#endif
orc_program_compile (p);
c = orc_program_take_code (p);
orc_program_free (p);
}
p_inited = TRUE;
orc_once_mutex_unlock ();
}
ex->arrays[ORC_VAR_A2] = c;
ex->program = 0;
ex->n = n;
ex->arrays[ORC_VAR_D1] = d1;
ex->params[ORC_VAR_P1] = p1;
func = c->exec;
func (ex); <---------------- SEGFAUL HERE
}
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/orc/-/issues/7div255 implementation is incorrect2024-01-26T09:26:16ZBugzilla Migration Userdiv255 implementation is incorrect## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#746247)](https://bugzilla.gnome.org/show_bug.cgi?id=746247)**
## Description
Created attachment 299452
test div255 app
div255 implements this algorithm everywhe...## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#746247)](https://bugzilla.gnome.org/show_bug.cgi?id=746247)**
## Description
Created attachment 299452
test div255 app
div255 implements this algorithm everywhere:
d = (s + 128 + (s+128)>>8) >> 8
which produces a result that is off-by-one for roughly half the 0..65535 input range.
A correct implementation is:
d = (s + 1 + (s >> 8)) >> 8
Test python app, and a fix which implements the new algorithm attached.
**Attachment 299452**, "test div255 app":
[test-div255.py](/uploads/d2adb744c6b931ba2fa31e1957d8ffc4/test-div255.py)
### See also
* [Bug 796846](https://bugzilla.gnome.org/show_bug.cgi?id=796846)https://gitlab.freedesktop.org/gstreamer/orc/-/issues/12orc_memcpy() slower than memcpy()2024-01-26T09:26:17ZBugzilla Migration Userorc_memcpy() slower than memcpy()## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#769259)](https://bugzilla.gnome.org/show_bug.cgi?id=769259)**
## Description
Created attachment 332264
memcpy_speed.diff
With attached patch for making the me...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#769259)](https://bugzilla.gnome.org/show_bug.cgi?id=769259)**
## Description
Created attachment 332264
memcpy_speed.diff
With attached patch for making the memcpy performance test in orc output something meaningful (actual size | time for one iteration with orc | with libc), orc_memcpy() is e.g. about 35% slower than memcpy() on 5MB.
This is on Linux with a "Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz" and glibc 2.22. Similar reports on Windows though.
When putting the output to a file ("data") you can plot this with gnuplot:
> plot "data" using 1:2 t "orc" with lines, "data" using 1:3 t "libc" with lines
See also attached plot from me
**Patch 332264**, "memcpy_speed.diff":
[memcpy_speed.diff](/uploads/2a4bc2c11006712572854e1c31a6c51b/memcpy_speed.diff)
### See also
* #13 https://gitlab.freedesktop.org/gstreamer/orc/-/issues/24ORC code generation for Rust2024-01-26T09:26:17ZAbdul RehmanORC code generation for RustFor anyone interested in writing gstreamer plugins purely in Rust, I think it would be good to have ORC support directly in Rust.For anyone interested in writing gstreamer plugins purely in Rust, I think it would be good to have ORC support directly in Rust.https://gitlab.freedesktop.org/gstreamer/orc/-/issues/29liborc: add OpenPOWER ppc64 support2024-01-26T09:26:17ZDaniel Pocockliborc: add OpenPOWER ppc64 supportBackground:
liborc: a JIT compiler that will at run-time take orc code (in some byte format) and generate machine code for the architecture in question on the fly and then execute that whenever there's a function call
https://gstreamer.f...Background:
liborc: a JIT compiler that will at run-time take orc code (in some byte format) and generate machine code for the architecture in question on the fly and then execute that whenever there's a function call
https://gstreamer.freedesktop.org/projects/orc.html
There is growing interest in the OpenPOWER architecture.
IBM is currently offering bounties to developers who will port free software projects to OpenPOWER
Extending liborc to support translation of orc code to OpenPOWER ISA appears to be a prime candidate for a bounty.
A bounty was offered for similar work in ffmpeg libswscale and a developer has provided a solution for that
https://www.bountysource.com/issues/34315232-power8-vsx-vectorization-libswscale-input-c
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1585056463-7934-1-git-send-email-pestov.vyach@yandex.ru/https://gitlab.freedesktop.org/gstreamer/orc/-/issues/38Add support for Windows ARM64 backend2021-09-28T14:28:50ZSeungha Yangseungha@centricular.comAdd support for Windows ARM64 backendRelated MR: https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/60Related MR: https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/60https://gitlab.freedesktop.org/gstreamer/orc/-/issues/48How/where to output artifacts of OrcCode?2024-01-31T13:03:31ZamysparkHow/where to output artifacts of OrcCode?Hey all!
`exec_opcodes_sys` (post !116) generates .S and .bin in the working directory, which for Meson is the build root. These files are intended for A/B testing the Orc and GCC/Clang codegen of the test cases.
But there are further ...Hey all!
`exec_opcodes_sys` (post !116) generates .S and .bin in the working directory, which for Meson is the build root. These files are intended for A/B testing the Orc and GCC/Clang codegen of the test cases.
But there are further cases, for instance all callers of `orc_gcc_compiler`, which have not been touched at all.
We should figure out:
- how best to enable/disable the artifact generation
- the output directoryhttps://gitlab.freedesktop.org/gstreamer/orc/-/issues/49Increase the unrolling depth for AVX+2023-12-26T10:03:30ZamysparkIncrease the unrolling depth for AVX+Hey all,
As requested in https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/111#note_2220110
I'm filing this issue to analyse how best to increase the `unroll_shift` parameter for the
AVX backend.
This is because the tests a...Hey all,
As requested in https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/111#note_2220110
I'm filing this issue to analyse how best to increase the `unroll_shift` parameter for the
AVX backend.
This is because the tests added in !136 do not tolerate a higher unrolling value (they
fail register assignment), which is also the state of `orc_quantdequant3_s16` in 32-bit
AVX. This latter example also fails to build with the C backend altogether under the
same circumstances.https://gitlab.freedesktop.org/gstreamer/orc/-/issues/50Cover all opcodes by tests2023-12-26T10:59:47ZSebastian DrögeCover all opcodes by testsThe following discussion from !111 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/111#note_2218565): (+3 comments)
> Looks generally good. I didn't go through...The following discussion from !111 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/111#note_2218565): (+3 comments)
> Looks generally good. I didn't go through all the rules but as they pass the comparison against the C implementations of the opcodes I assume they're at least giving the correct results :)
>
> Rules coverage between SSE and AVX is the same btw? And are there any opcodes missing?https://gitlab.freedesktop.org/gstreamer/orc/-/issues/52Implement `ldreslinb` and `convsssql` for SSE/AVX2024-02-01T12:10:32ZSebastian DrögeImplement `ldreslinb` and `convsssql` for SSE/AVXhttps://gitlab.freedesktop.org/gstreamer/orc/-/issues/53RFC: Plugins support2024-01-18T13:10:14ZJorge ZapataRFC: Plugins supportORC has support for extending the current opcodes externally through `orc_opcode_register_static`, an example can be found at `examples/volscale.c`. The problem is that orcc won't generate such new opcodes (for obvious reasons) and every...ORC has support for extending the current opcodes externally through `orc_opcode_register_static`, an example can be found at `examples/volscale.c`. The problem is that orcc won't generate such new opcodes (for obvious reasons) and everything has to be done programmatically instead of the generic file based .orc mechanism. My impression is that ORC extensibility is still premature, but I'd like to understand what would be the preferable way.
Doing a simple plugin loading system is easy, but given that ORC does not depend on GLib the work to be done is kind of repetitive and complex for corner cases (Windows for example).
So, does a plugin system would be desirable? Are there any restrictions to bring GLib dependency?https://gitlab.freedesktop.org/gstreamer/orc/-/issues/54Document on how to contribute a new target2024-01-22T10:12:03ZJorge ZapataDocument on how to contribute a new targetNow that ORC has a CONTRIBUTING.md file, and that a lot of excellent work has been done to add AVX support, it will be good to enhance the document with a brief explanation of what is required to add a new target, including the modificat...Now that ORC has a CONTRIBUTING.md file, and that a lot of excellent work has been done to add AVX support, it will be good to enhance the document with a brief explanation of what is required to add a new target, including the modification of generate_xml_table.c. This will help us update the target table at https://gstreamer.pages.freedesktop.org/orc/docs/latest/orc-opcodes.html. If a target has poor coverage, it should be include too to know where to improve ORC.https://gitlab.freedesktop.org/gstreamer/orc/-/issues/55RFC: Refactor how accumulators are handled2024-01-18T13:36:50ZJorge ZapataRFC: Refactor how accumulators are handledCurrently in Orc, accumulators are handled as special opcodes. Such opcodes have the flag `ORC_STATIC_OPCODE_ACCUMULATOR` https://gitlab.freedesktop.org/gstreamer/orc/-/blob/main/orc/orcopcode.h#L28 and the current logic is:
1. The accu...Currently in Orc, accumulators are handled as special opcodes. Such opcodes have the flag `ORC_STATIC_OPCODE_ACCUMULATOR` https://gitlab.freedesktop.org/gstreamer/orc/-/blob/main/orc/orcopcode.h#L28 and the current logic is:
1. The accumulators always end up adding the current accumulator value to the actual opcode operation
2. In case a different kind of operation to accumulate is needed, a new opcode has to be created for that particular case
3. The initial value of the accumulators is always set to zero (through pxor, for example)
4. Given that the accumulator is added at every loop iteration, and the operation is always an addition, loop_shifts (partial data processing) are not a problem, adding zero does not alter the final value.
The opcodes `accw`, `accl` and `accsadubl` are the current accumulator opcodes.
My actual requirement is to implement a `maxf` accumulator, that is, do a `maxf` for an array of floats, accumulate the maximum value and keep it. The approach would be to do the same as point 2 above. Create a new opcode like `accmaxf` and change the conditions of point 3 and point 4 to handle partial data processing and initialize the data with `MINF` instead of 0.
Now, I think this will pollute Orc with more opcodes where the actual operation of the accumulation (the `maxf`) already exists. My proposal would be to just use regular opcodes as accumulator setters.
1. Add a new flag to mark opcodes that can accumulate, something like `ORC_STATIC_OPCODE_CAN_ACCUMULATE` (actually commutative operations).
2. Add a sanity check that when using an opcode into a destination variable that is an accumulator, force to make src arg1 also the same variable, i.e `a1 = a1 + s1`
3. Pass the initial value of the accumulator as part of the OrcExecutor, similar to the current situation of storing the value, but loading it too.
4. At each loop iteration (depending on the loop shift), correctly blend the initial accumulator value with the actual parameter to use. That means, if the initial value is 1 1 1 1 (double words on SSE, because of a multiplication) and the loop shift only holds 4 bytes of data (one double word), blend the value to be 1 1 1 X.
5. Out of every loop, re-use the same opcode to reduce the vector into a single value.
Of course all of that, maintaining compatibility with old `acc*` based opcodes. All of that is already implemented in https://gitlab.freedesktop.org/turran/orc/-/compare/main...accumulators?from_project_id=1360&straight=false with backwards compatibility and without breaking any test.
Please, let me know your thoughts.
PS: I sincerely think that a refactoring in Orc is needed, adding new features is complicated. I can manage that, but need the maintainers opinion on this topic. Maybe I should create another issue to discuss there?https://gitlab.freedesktop.org/gstreamer/orc/-/issues/67PulseAudio orc code crashes in emulation mode2024-03-22T13:29:39ZArun RaghavanPulseAudio orc code crashes in emulation modeReproducible in both 0.4.33 and master in the PulseAudio tree with:
```
ORC_DEBUG=99 ORC_CODE=debug,emulate CK_FORK=no meson test cpu-volume-test
```
Backtrace:
```
#0 0x00007ffff7810cd3 in orc_executor_emulate (ex=0x7fffffffb830) at...Reproducible in both 0.4.33 and master in the PulseAudio tree with:
```
ORC_DEBUG=99 ORC_CODE=debug,emulate CK_FORK=no meson test cpu-volume-test
```
Backtrace:
```
#0 0x00007ffff7810cd3 in orc_executor_emulate (ex=0x7fffffffb830) at ../subprojects/orc/orc/orcexecutor.c:320
#1 0x00007ffff7e04b82 in pa_volume_s16ne_orc_2ch (d1=0x7fffffffcc5e, p1=180444461064589, n=510) at src/pulsecore/svolume-orc-gen.c:551
#2 0x00007ffff7e8e189 in pa_volume_s16ne_orc (samples=0x7fffffffcc5e, volumes=0x7fffffffbbc0, channels=2, length=2040) at ../src/pulsecore/svolume_orc.c:38
#3 0x0000000000401592 in run_volume_test (func=0x7ffff7e8e130 <pa_volume_s16ne_orc>, orig_func=0x7ffff7e82470 <pa_volume_s16ne_sse2>, align=1, channels=2, correct=true, perf=false) at ../src/tests/cpu-volume-test.c:74
#4 0x000000000040207e in svolume_orc_test_fn (_i=0) at ../src/tests/cpu-volume-test.c:211
#5 0x00007ffff7dbd943 in tcase_run_tfun_nofork (sr=sr@entry=0x406680, tc=tc@entry=0x406420, tfun=tfun@entry=0x406630, i=i@entry=0) at /usr/src/debug/check-0.15.2-10.fc39.x86_64/src/check_run.c:420
#6 0x00007ffff7dbdf75 in srunner_iterate_tcase_tfuns (tc=0x406420, sr=<optimized out>) at /usr/src/debug/check-0.15.2-10.fc39.x86_64/src/check_run.c:263
#7 srunner_run_tcase (tc=0x406420, sr=0x406680) at /usr/src/debug/check-0.15.2-10.fc39.x86_64/src/check_run.c:402
#8 srunner_iterate_suites (print_mode=<optimized out>, exclude_tags=0x0, include_tags=0x0, tcname=<optimized out>, sname=0x0, sr=0x406680) at /usr/src/debug/check-0.15.2-10.fc39.x86_64/src/check_run.c:222
#9 srunner_run_tagged (sr=0x406680, sname=0x0, tcname=<optimized out>, include_tags=0x0, exclude_tags=0x0, print_mode=<optimized out>) at /usr/src/debug/check-0.15.2-10.fc39.x86_64/src/check_run.c:814
#10 0x00000000004021da in main (argc=1, argv=0x7fffffffd8a8) at ../src/tests/cpu-volume-test.c:241
```