Hypnosis is a memory hog #586
Comments
|
BTW, if the allocation actually happens after setup() is called, this will already be in PSRAM for Mesmerizer, so no win - but if it's allocated before setup() - like as a global - then it will use base ram. |
|
Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number
way smaller than a frame buffer.) So it's really all coming from a similar
pool sooner or later,. Assuming it's inside a class that's getting newed
anyway.
The *real* solution here is to not allocate effects that aren't being
displayed. Things not in use shouldn't have a cost. But I know there's
resistance to that.
I'm a bit out of order right now and have a funeral coming up (not
mine).but if nobody beats me to it,. I'll take this one.
…On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> wrote:
BTW, if the allocation actually happens after setup() is called, this will
already be in PSRAM for Mesmerizer, so no win - but if it's allocated
before setup() - like as a global - then it will use base ram.
—
Reply to this email directly, view it on GitHub
<#586 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
|
It’s not currently a malloc. It’s static decl.
… On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote:
Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number
way smaller than a frame buffer.) So it's really all coming from a similar
pool sooner or later,. Assuming it's inside a class that's getting newed
anyway.
The *real* solution here is to not allocate effects that aren't being
displayed. Things not in use shouldn't have a cost. But I know there's
resistance to that.
I'm a bit out of order right now and have a funeral coming up (not
mine).but if nobody beats me to it,. I'll take this one.
On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***>
wrote:
> BTW, if the allocation actually happens after setup() is called, this will
> already be in PSRAM for Mesmerizer, so no win - but if it's allocated
> before setup() - like as a global - then it will use base ram.
>
> —
> Reply to this email directly, view it on GitHub
> <#586 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***
> com>
>
—
Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>.
You are receiving this because you authored the thread.
|
|
…but it could be contained inside a dynamically allocated object, and therefore be OK. But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK.
If you think there are effects that can contract their memory usage, we could just add an End() function that is called like Start(), and effects could manage their memory that way pretty easily. But I haven’t looked very hard yet!
- Dave
… On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote:
It’s not currently a malloc. It’s static decl.
> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote:
>
>
> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number
> way smaller than a frame buffer.) So it's really all coming from a similar
> pool sooner or later,. Assuming it's inside a class that's getting newed
> anyway.
>
> The *real* solution here is to not allocate effects that aren't being
> displayed. Things not in use shouldn't have a cost. But I know there's
> resistance to that.
>
> I'm a bit out of order right now and have a funeral coming up (not
> mine).but if nobody beats me to it,. I'll take this one.
>
> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***>
> wrote:
>
> > BTW, if the allocation actually happens after setup() is called, this will
> > already be in PSRAM for Mesmerizer, so no win - but if it's allocated
> > before setup() - like as a global - then it will use base ram.
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <#586 (comment)>,
> > or unsubscribe
> > <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE>
> > .
> > You are receiving this because you are subscribed to this thread.Message
> > ID: ***@***.***
> > com>
> >
> —
> Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>.
> You are receiving this because you authored the thread.
>
|
|
OK, I read the code :-). All of these things are constructed as a result of InitEffectsManager and hence they’ve got access to PSRAM. Non-issue, I think!
… On Jan 8, 2024, at 2:30 PM, Dave Plummer ***@***.***> wrote:
…but it could be contained inside a dynamically allocated object, and therefore be OK. But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK.
If you think there are effects that can contract their memory usage, we could just add an End() function that is called like Start(), and effects could manage their memory that way pretty easily. But I haven’t looked very hard yet!
- Dave
> On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote:
>
> It’s not currently a malloc. It’s static decl.
>
>> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote:
>>
>>
>> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number
>> way smaller than a frame buffer.) So it's really all coming from a similar
>> pool sooner or later,. Assuming it's inside a class that's getting newed
>> anyway.
>>
>> The *real* solution here is to not allocate effects that aren't being
>> displayed. Things not in use shouldn't have a cost. But I know there's
>> resistance to that.
>>
>> I'm a bit out of order right now and have a funeral coming up (not
>> mine).but if nobody beats me to it,. I'll take this one.
>>
>> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***>
>> wrote:
>>
>> > BTW, if the allocation actually happens after setup() is called, this will
>> > already be in PSRAM for Mesmerizer, so no win - but if it's allocated
>> > before setup() - like as a global - then it will use base ram.
>> >
>> > —
>> > Reply to this email directly, view it on GitHub
>> > <#586 (comment)>,
>> > or unsubscribe
>> > <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE>
>> > .
>> > You are receiving this because you are subscribed to this thread.Message
>> > ID: ***@***.***
>> > com>
>> >
>> —
>> Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>.
>> You are receiving this because you authored the thread.
>>
>
|
|
Sounds right. If it's inside the class, it's (sort of) dynamically
allocated - as a global ctor, I think. (That's the part I groused about.)
It'd be different if it was outside the class and a global, where it would
land in .data instead of on the heap. Or the other heap.
From memory (I'm AFK) I *thought* I cleaned all that kind of thing up from
its arduino-esque heritage when I modernized them, but I couldn't have
faked shock if I'd missed one or more. In their original form, all the
effects lived in separated executables (Atmega328, you know...) so
lifecyle of memory wasn't exactly a concern.
I do think we have more than a few matrix effects that allocate large-ish
things. I think life, for example, was one as was one of the fires. As a
broad measuring stick, grep for '[MAT_WIDTH][MAT_HEIGHT];' or maybe with an
explicit multiplication in declarations.
If that keeps all/most our allocations out of the arena all the time, jolly
good. I don't think I knew about start(), so if there are things we can
move from thectors, we should. If ther's someclever reference counting
voodoo we can do to not manually manage it, even better.
If there's something we can methodically do better, I'd even go back and
update "my" branch of effects that didn't make it so that anyone wanting to
manually bring those forward can benefit.
On Mon, Jan 8, 2024 at 4:34 PM David W Plummer ***@***.***>
wrote:
… OK, I read the code :-). All of these things are constructed as a result
of InitEffectsManager and hence they’ve got access to PSRAM. Non-issue, I
think!
> On Jan 8, 2024, at 2:30 PM, Dave Plummer ***@***.***> wrote:
>
> …but it could be contained inside a dynamically allocated object, and
therefore be OK. But I’m not fully cromulent on all the construction paths
and their timing. If they’re loaded dynamically by effects manager, and are
NOT instantiated in the table, then it’d be OK.
>
> If you think there are effects that can contract their memory usage, we
could just add an End() function that is called like Start(), and effects
could manage their memory that way pretty easily. But I haven’t looked very
hard yet!
>
> - Dave
>
>> On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote:
>>
>> It’s not currently a malloc. It’s static decl.
>>
>>> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote:
>>>
>>>
>>> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a
number
>>> way smaller than a frame buffer.) So it's really all coming from a
similar
>>> pool sooner or later,. Assuming it's inside a class that's getting
newed
>>> anyway.
>>>
>>> The *real* solution here is to not allocate effects that aren't being
>>> displayed. Things not in use shouldn't have a cost. But I know there's
>>> resistance to that.
>>>
>>> I'm a bit out of order right now and have a funeral coming up (not
>>> mine).but if nobody beats me to it,. I'll take this one.
>>>
>>> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***>
>>> wrote:
>>>
>>> > BTW, if the allocation actually happens after setup() is called,
this will
>>> > already be in PSRAM for Mesmerizer, so no win - but if it's
allocated
>>> > before setup() - like as a global - then it will use base ram.
>>> >
>>> > —
>>> > Reply to this email directly, view it on GitHub
>>> > <
#586 (comment)>,
>>> > or unsubscribe
>>> > <
https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE>
>>> > .
>>> > You are receiving this because you are subscribed to this
thread.Message
>>> > ID: ***@***.***
>>> > com>
>>> >
>>> —
>>> Reply to this email directly, view it on GitHub <
#586 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>.
>>> You are receiving this because you authored the thread.
>>>
>>
>
—
Reply to this email directly, view it on GitHub
<#586 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD324KMGGOTQ7O4MTCKTYNRYAZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHEZDOOJSHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Construct() and Destruct() could be called on Start() and End(), could they not? Then it would release most memory when not active.
I don’t see any large matrix-sized allocations in base memory… if you can find one, let me know!
_ Dave
… On Jan 8, 2024, at 3:05 PM, Robert Lipe ***@***.***> wrote:
Sounds right. If it's inside the class, it's (sort of) dynamically
allocated - as a global ctor, I think. (That's the part I groused about.)
It'd be different if it was outside the class and a global, where it would
land in .data instead of on the heap. Or the other heap.
From memory (I'm AFK) I *thought* I cleaned all that kind of thing up from
its arduino-esque heritage when I modernized them, but I couldn't have
faked shock if I'd missed one or more. In their original form, all the
effects lived in separated executables (Atmega328, you know...) so
lifecyle of memory wasn't exactly a concern.
I do think we have more than a few matrix effects that allocate large-ish
things. I think life, for example, was one as was one of the fires. As a
broad measuring stick, grep for '[MAT_WIDTH][MAT_HEIGHT];' or maybe with an
explicit multiplication in declarations.
If that keeps all/most our allocations out of the arena all the time, jolly
good. I don't think I knew about start(), so if there are things we can
move from thectors, we should. If ther's someclever reference counting
voodoo we can do to not manually manage it, even better.
If there's something we can methodically do better, I'd even go back and
update "my" branch of effects that didn't make it so that anyone wanting to
manually bring those forward can benefit.
On Mon, Jan 8, 2024 at 4:34 PM David W Plummer ***@***.***>
wrote:
> OK, I read the code :-). All of these things are constructed as a result
> of InitEffectsManager and hence they’ve got access to PSRAM. Non-issue, I
> think!
>
> > On Jan 8, 2024, at 2:30 PM, Dave Plummer ***@***.***> wrote:
> >
> > …but it could be contained inside a dynamically allocated object, and
> therefore be OK. But I’m not fully cromulent on all the construction paths
> and their timing. If they’re loaded dynamically by effects manager, and are
> NOT instantiated in the table, then it’d be OK.
> >
> > If you think there are effects that can contract their memory usage, we
> could just add an End() function that is called like Start(), and effects
> could manage their memory that way pretty easily. But I haven’t looked very
> hard yet!
> >
> > - Dave
> >
> >> On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote:
> >>
> >> It’s not currently a malloc. It’s static decl.
> >>
> >>> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote:
> >>>
> >>>
> >>> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a
> number
> >>> way smaller than a frame buffer.) So it's really all coming from a
> similar
> >>> pool sooner or later,. Assuming it's inside a class that's getting
> newed
> >>> anyway.
> >>>
> >>> The *real* solution here is to not allocate effects that aren't being
> >>> displayed. Things not in use shouldn't have a cost. But I know there's
> >>> resistance to that.
> >>>
> >>> I'm a bit out of order right now and have a funeral coming up (not
> >>> mine).but if nobody beats me to it,. I'll take this one.
> >>>
> >>> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***>
> >>> wrote:
> >>>
> >>> > BTW, if the allocation actually happens after setup() is called,
> this will
> >>> > already be in PSRAM for Mesmerizer, so no win - but if it's
> allocated
> >>> > before setup() - like as a global - then it will use base ram.
> >>> >
> >>> > —
> >>> > Reply to this email directly, view it on GitHub
> >>> > <
> #586 (comment)>,
>
> >>> > or unsubscribe
> >>> > <
> https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE>
>
> >>> > .
> >>> > You are receiving this because you are subscribed to this
> thread.Message
> >>> > ID: ***@***.***
> >>> > com>
> >>> >
> >>> —
> >>> Reply to this email directly, view it on GitHub <
> #586 (comment)>,
> or unsubscribe <
> https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>.
>
> >>> You are receiving this because you authored the thread.
> >>>
> >>
> >
>
> —
> Reply to this email directly, view it on GitHub
> <#586 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACCSD324KMGGOTQ7O4MTCKTYNRYAZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHEZDOOJSHA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF5IFS5K5TJHLWXTG73YNR3S5AVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHE2TSNZWG4>.
You are receiving this because you authored the thread.
|
Effects are constructed during the execution of
It's actually anything over 128 bytes. But considering the previous that shouldn't matter anyway.
The challenge with the destruct part is that we have no " |
|
On Tue, Jan 9, 2024, 7:55 AM Rutger van Bergen ***@***.***> wrote:
But I’m not fully cromulent on all the construction paths and their
timing. If they’re loaded dynamically by effects manager, and are NOT
instantiated in the table, then it’d be OK.
Effects are constructed during the execution of setup(), but pretty much
towards the end of its invocation. Also, effects are explicitly allocated
using psram_allocator.
The table that's put together in effects.cpp only contains the effect
factories; this means that in practice the table is a couple of small
lambdas for each effect in the list.
Any mallocs over, I think, 16 bytes already goes into psram.
It's actually anything over 128 bytes. But considering the previous that
shouldn't matter anyway.
That sounds cromulentier.
I wonder if psram_allicator is never actually. Called for anything < 128
bytes anyway. Is that a candidate for instrumentation in step 1 and then
removal a few days/weeks after that if no warnings fire?
Construct() and Destruct() could be called on Start() and End(), could they
not?
The challenge with the destruct part is that we have no "End()". An
effect is told to prepare itself for drawing through Start(), and then
told to draw frames through Draw(). It is *not* told when its time in the
spotlight has ended.
IMO, it's ok to not know when everything has ended, but to know when
another has started. We could destroy when calling visual mute, but that
probably makes visual turbulence when restarting. Would we satisfy Paretto
calling End() just before calling Start(), but only if the current effect
(current until a few milliseconds. Before that) is set?
It matters less that we may never have 0 that are Start()Ed than that we
have fewer than 2, Right?
We have scores of effects. Especially on Matrix, where we may have large
secondary rendering buffers or other per pixel data, this might add up -
literally doubly so for the 64*64 cases. Are multiple displays unique (e.g
128*128 canvas) or are they pixel mirrored? That, too, is probably a road
little traveled.
We don't KNOW, but I don't get the impression we have people running
thousands of strip pixels, but we. Should review that directory,. Too.
I got into a talk on Dave's most recent video with a guy that said he tried
to run 16*300 2812s, but then project supported only HUB75 then,. So he
moved on. I don't think we can actually run > 8 strips in any non-trivial
configuration on any esp32 because FastLed doesn't support the modern 16
channel. Parallel I/O mode in the new S3.
Let's not get into that. (That discussion had...issues.) Addressing the
matrix case to have at most one effect armed is likely a win for us.
—
… Reply to this email directly, view it on GitHub
<#586 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3ZFVD2OOKC6UOESGGTYNVD5BAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGA4DSNBSGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Unless I’m just inferring, you keep implying that there are lots of effects with base memory demands, but having looked, I’m dubious. I’ve been careful to allocate things dynamically from PSRAM in all my own effects, and have fixed most others. But like I said, if you KNOW about any, call it out so I can fix it. But call it out or move on, I’d say :-)
I have no had luck reducing the PSRAM allocation auto limit below 96, as WiFi has code that needs base memory but doesn’t spec it, so it gets PSRAM and chokes if you go to 64.
The practical limit of the number of LEDs you can control is a function of refresh rate, which I explain in the latest video. So haveing 16x300 LEDs would work, but (a) you’d have fewer buffers since they’re larger, and (b) the refresh rate will be terrible.
I run a 5000 LED strip on the Cabana, but it’s broken into four of a about 8x144 each
The umbrella shows that NDS can handle 8 parallel effects, and the tiki lamp can receive multiple channels over wifi, too. So that all works.
- Dave
… On Jan 9, 2024, at 9:11 AM, Robert Lipe ***@***.***> wrote:
We have scores of effects. Especially on Matrix, where we may have large
secondary rendering buffers or other per pixel data, this might add up -
literally doubly so for the 64*64 cases. Are multiple displays unique (e.g
128*128 canvas) or are they pixel mirrored? That, too, is probably a road
little traveled.
|
|
On Tue, Jan 9, 2024 at 12:10 PM David W Plummer ***@***.***>
wrote:
Unless I’m just inferring, you keep implying that there are lots of
effects with base memory demands, but having looked, I’m dubious. I’ve been
careful to allocate things dynamically from PSRAM in all my own effects,
and have fixed most others. But like I said, if you KNOW about any, call it
out so I can fix it. But call it out or move on, I’d say :-)
Some. Not lots. Now that I'm able to get to a computer, using the regex I
cited earlier, a starting place might include
PatternLife.h: bool alive[MATRIX_WIDTH][MATRIX_HEIGHT];
That should become a bitset, as I did for StrobeDiffusion
in 0dccb01. Life has a few others.
PatternSMHypnosis.h: } rMap[MATRIX_WIDTH][MATRIX_HEIGHT];
PatternSMRadialFire.h: byte XY_angle[MATRIX_WIDTH][MATRIX_HEIGHT];
PatternSMRadialFire.h: byte XY_radius[MATRIX_WIDTH][MATRIX_HEIGHT];
PatternSMRadialWave.h: } rMap[MATRIX_WIDTH][MATRIX_HEIGHT];
PatternSMRainbowTunnel.h: } rMap[MATRIX_WIDTH][MATRIX_HEIGHT];
There is a larger number holding local arrays for many hundreds
of trackingOBJECT_MAX_COUNT (100 * 5 floats, two ints, and a bool))
or SNAKE_LENGTH (64 * several arrrays) or [MAX_DIMENSION][MAX_DIMENSION];
(the largest of WIDTH, HEIGHT) and the various noise arrays were in the
thousands, IIRC.
Changing these from what's ultimately an operator new[] to populate the
effects objects to an actual operator new that's called when we come to
life.
Quit fixating on PSRAM vs. Base heap or even .data. My point is that we
have scores of effects objects and at any time, only one of them is
actually live. Whether it comes from this pocket or that pocket matters
(and we're finally now all agreeing that effects will come from the PSRAM
pocket) less than that MOST of it is not in use at any one time. We want to
add new effects, but if an effect has a non-trivial cost when not in use,
we have a scalability problem.
I have no had luck reducing the PSRAM allocation auto limit below 96, as
WiFi has code that needs base memory but doesn’t spec it, so it gets PSRAM
and chokes if you go to 64.
My 16 number was from memory. Offhand, I don't dislike 128. Keeping it
large enough to keep the Arduino Strings (few of our strings are 128) from
fragging that heap is probably a good idea anyway.
The practical limit of the number of LEDs you can control is a function of
refresh rate, which I explain in the latest video. So haveing 16x300 LEDs
would work, but (a) you’d have fewer buffers since they’re larger, and (b)
the refresh rate will be terrible.
I'm quite aware of the signalling rules for both HUB and WS. On the older
ESP32's, there are 8 RMT channels, but only 4 really work at once so
synchronization between the channels is janky. On newer ESP32s, there are
only 4 RMT channels and FastLED (which is still kind of deadlocked,
struggling with Arduino and ESP8266) doesn't support either the 16-channel
I2S mode or the 24-channel parallel "general gpio" mode while we're using
I2s for sound because we only have so many I2S controllers. So I think that
even with local effects (lots of bouncingballs or lasers or fireworks or
whatever) we'd fall back into bitbang mode on a bunch of those strips and
then fall into the collapse of the sun.
I see now that NightDriver caps the NUM_CHANNELS to 8 anyway, so this is
all rather a distraction. It was just opening the discussion that not all
arrays are in the HUB code; some might be in strip. A secondary point was
that we don't seem to have a lot of people fussing about limits of running
zillions of WS parts. Nobody's whining (enough to do anything about it)
that we can't control 24 channels on the hardware that supports that. I
think that crowd is just using other software...and probably something
closer to a Pi than an ESP32. Eight 2Ghz cores lets you get away with
murder.
Of all things, this dude was talking about building a clock, so I can't
imagine he needed much more than a 1Hz refresh anyway and I have no idea
why he needed enough pixels to be a "real" monitor. He used a different
project. I'd only been thinking about this after seeing the ESP32 page on a
project that's like FastLED:
https://github.com/Makuna/NeoPixelBus/wiki/ESP32-NeoMethods ... and
thinking about what a support horror that would be.
I run a 5000 LED strip on the Cabana, but it’s broken into four of a about
8x144 each
Are you really using 8 channels or is it like your umbrella where you're
just teeing one channel to DIN on multiple strips? (Not that your umbrella
isn't freakin' awesome.)
Can you run meteor on channel 0, fireworks on channel 2, particles on
channel 3, laser on 4, ... ? (Yeah, I get that would be custom and far from
something that's in the tree by default.)
The umbrella shows that NDS can handle 8 parallel effects, and the tiki
lamp can receive multiple channels over wifi, too. So that all works.
Well, it's one effect, just electrically connected to 8 strips, right?
// The "Tiki Fire Umbrella" project, with 8 channels
#define LED_PIN0 5 // Only one pin, it's routed to all
8 spokes. Independent turned out not to be that useful.
#define NUM_CHANNELS 1
I don't see any "real" projects in the tree that use NUM_CHANNELS to
anything but 1. (I'm sure you have projects that aren't in the tree. Me,
too.)
The "how many strips can we REALLY do" thing is a distraction. I'd much
rather use your valuable attention to think about the paper-cut problem of
effects taking up memory when they're simply not in use and may not even be
even shown. Let's think about that one more and forget the "angels on the
WS281x Data Out Pin" thing.
RJL
…
- Dave
> On Jan 9, 2024, at 9:11 AM, Robert Lipe ***@***.***> wrote:
>
> We have scores of effects. Especially on Matrix, where we may have large
> secondary rendering buffers or other per pixel data, this might add up -
> literally doubly so for the 64*64 cases. Are multiple displays unique
(e.g
> 128*128 canvas) or are they pixel mirrored? That, too, is probably a
road
> little traveled.
—
Reply to this email directly, view it on GitHub
<#586 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD32EELKX77UWJF3GILTYNWBXXAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGU2DMOJXGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Hypnosis effect has a static declaration of two bytes per pixel that go into base RAM. These should be dynamically allocated using PreferPSRAM or similar. The only catch is the [x][y] addressing in the Draw() code gets harder, but I think we need to reclaim the memory.
The text was updated successfully, but these errors were encountered: