Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

92 participants
7135 discussions

[PATCH net-next v5 0/3] net: devmem: allow rx-buf-size > PAGE_SIZE per binding

by Bobby Eshleman

Every devmem dmabuf binding hands the page_pool PAGE_SIZE niovs today. On NICs that consume one descriptor per netmem, this caps a single RX descriptor at PAGE_SIZE and burns CPU on buffer churn. In this series, we add a bind-time netlink attribute, NETDEV_A_DMABUF_RX_BUF_SIZE, that lets userspace request a larger niov size (power of two >= PAGE_SIZE). Drivers must opt in via queue_mgmt_ops.QCFG_RX_PAGE_SIZE. Measurements: Setup: kperf devmem RX/TX cuda, 4 flows, 64 MB messages, 60s, dctcp, num-rx-queues=4, dmabuf-rx/tx-size-mb=2048, 10 runs per niov size, mlx5. niov RX dev Gbps RX flow avg Gbps app sys % ----- ---------------- ----------------- ---------------- 4K 300.63 +/- 53.21 75.16 +/- 13.30 54.15 +/- 10.23 16K 321.35 +/- 28.20 80.34 +/- 7.05 41.05 +/- 8.87 32K 347.63 +/- 2.20 86.91 +/- 0.55 44.54 +/- 3.51 64K 332.11 +/- 14.26 83.03 +/- 3.56 35.47 +/- 3.11 RX app sys % drops ~19% from 4K to 64K. kperf support (not yet merged): https://github.com/facebookexperimental/kperf/commit/8837577f920876bce6986e… Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> --- Changes in v5: - removed unnecessary change from ssize_t to size_t (Mina) - removed '--------' lines in the commit message (Paolo) - removed commit msg about CONFIG_HUGETLB since that change was already merged - Link to v4: https://lore.kernel.org/r/20260701-tcpdm-large-niovs-v4-0-ca4654f37570@meta… Changes in v4: - ncdevmem: fix the possible overflow in ncdevmem (Sashiko) - drop the udmabuf patch because the fix is now already in net-next - silenced two pylint complaints in devmem_lib.py - Link to v3: https://lore.kernel.org/r/20260612-tcpdm-large-niovs-v3-0-a3b693e76fcb@meta… Changes in v3: - fix a bunch of non-reverse christmas tree declarations (Stan) - remove extra uint32 cast for getpagesize() (Stan) - remove overzealous strtoul checking (Stan) - remove value checks that the kernel already performs on rx_buf_size (Stan) - Link to v2: https://lore.kernel.org/r/20260611-tcpdm-large-niovs-v2-0-ee2bf15e7523@meta… Changes in v2: - Use NL_SET_ERR_MSG_FMT for sg alignment failure details (Stan) - Keep -E2BIG (not a direct ask, but seemed preferred, Stan) - Update udmabuf commit message and comments explaining why "one sg ent per folio" is useful (Christian) - Set/restore nr_hugepages in py harness (Stan) - Link to v1: https://lore.kernel.org/r/20260603-tcpdm-large-niovs-v1-0-f37a4ac6726c@meta… --- Bobby Eshleman (3): net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding selftests/net: ncdevmem: add -b option to set rx-buf-size on bind selftests/net: devmem.py: add check_rx_large_niov Documentation/netlink/specs/netdev.yaml | 8 +++ include/uapi/linux/netdev.h | 1 + net/core/devmem.c | 51 +++++++++++-------- net/core/devmem.h | 13 +++-- net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 19 ++++++- tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/drivers/net/hw/devmem.py | 12 ++++- .../testing/selftests/drivers/net/hw/devmem_lib.py | 59 +++++++++++++++++++++- tools/testing/selftests/drivers/net/hw/ncdevmem.c | 36 +++++++++++-- .../testing/selftests/drivers/net/hw/nk_devmem.py | 11 +++- 11 files changed, 178 insertions(+), 38 deletions(-) --- base-commit: 474cff6868129755cf889edf40d7f491729fc588 change-id: 20260602-tcpdm-large-niovs-56523a3a1077 Best regards, -- Bobby Eshleman <bobbyeshleman(a)meta.com>

2 hours, 24 minutes

[PATCH 7.1 0056/2077] dma-fence: Fix potential tracepoint null pointer dereferences

by Greg Kroah-Hartman

7.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> [ Upstream commit e94b9f01543cc6a83538c2c2cc645a424d3015ca ] Trace_dma_fence_signaled, trace_dma_fence_wait_end and trace_dma_fence_destroy can all currently dereference a null fence->ops pointer after it has been reset on fence signalling. Lets use the safe string getters for most tracepoints to avoid this class of a problem, while for the signal tracepoint we move it to before ops are cleared to avoid losing the driver and timeline name information. Apart from moving it we also need to add a new tracepoint class to bypass the safe name getters since the signaled bit is already set. For dma_fence_init we also need to use the new tracepoint class since the rcu read lock is not held there, and we can do the same for the enable signaling since there we are certain the fence cannot be signaled while we are holding the lock and have even validated the fence->ops. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Cc: Christian König <christian.koenig(a)amd.com> Cc: Philipp Stanner <phasta(a)kernel.org> Cc: Boris Brezillon <boris.brezillon(a)collabora.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Tvrtko Ursulin <tursulin(a)ursulin.net> Link: https://lore.kernel.org/r/20260415083207.40513-2-tvrtko.ursulin@igalia.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-fence.c | 3 ++- include/trace/events/dma_fence.h | 40 +++++++++++++++++++++++++++----- 2 files changed, 36 insertions(+), 7 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index a2aa82f4eedd49..b3bfa6943a8e13 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, &fence->flags))) return; + trace_dma_fence_signaled(fence); + /* * When neither a release nor a wait operation is specified set the ops * pointer to NULL to allow the fence structure to become independent @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, fence->timestamp = timestamp; set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); - trace_dma_fence_signaled(fence); list_for_each_entry_safe(cur, tmp, &cb_list, node) { INIT_LIST_HEAD(&cur->node); diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h index 3abba45c0601a4..5b10a9e06fb4ec 100644 --- a/include/trace/events/dma_fence.h +++ b/include/trace/events/dma_fence.h @@ -9,12 +9,40 @@ struct dma_fence; +DECLARE_EVENT_CLASS(dma_fence, + + TP_PROTO(struct dma_fence *fence), + + TP_ARGS(fence), + + TP_STRUCT__entry( + __string(driver, dma_fence_driver_name(fence)) + __string(timeline, dma_fence_timeline_name(fence)) + __field(unsigned int, context) + __field(unsigned int, seqno) + ), + + TP_fast_assign( + __assign_str(driver); + __assign_str(timeline); + __entry->context = fence->context; + __entry->seqno = fence->seqno; + ), + + TP_printk("driver=%s timeline=%s context=%u seqno=%u", + __get_str(driver), __get_str(timeline), __entry->context, + __entry->seqno) +); + /* * Safe only for call sites which are guaranteed to not race with fence - * signaling,holding the fence->lock and having checked for not signaled, or the - * signaling path itself. + * signaling, holding the fence->lock and having checked for not signaled, or + * the signaling path itself. + * + * TODO: Remove the need for this event class when drivers switch to independent + * fences. */ -DECLARE_EVENT_CLASS(dma_fence, +DECLARE_EVENT_CLASS(dma_fence_ops, TP_PROTO(struct dma_fence *fence), @@ -46,7 +74,7 @@ DEFINE_EVENT(dma_fence, dma_fence_emit, TP_ARGS(fence) ); -DEFINE_EVENT(dma_fence, dma_fence_init, +DEFINE_EVENT(dma_fence_ops, dma_fence_init, TP_PROTO(struct dma_fence *fence), @@ -60,14 +88,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, TP_ARGS(fence) ); -DEFINE_EVENT(dma_fence, dma_fence_enable_signal, +DEFINE_EVENT(dma_fence_ops, dma_fence_enable_signal, TP_PROTO(struct dma_fence *fence), TP_ARGS(fence) ); -DEFINE_EVENT(dma_fence, dma_fence_signaled, +DEFINE_EVENT(dma_fence_ops, dma_fence_signaled, TP_PROTO(struct dma_fence *fence), -- 2.53.0

5 hours, 37 minutes

[PATCH v3 0/2] drm/drm_crtc: dma_fence_ops fixes

by André Draszik

Hi, These patches fix two issues in the drm/drm_crtc driver. Initially I was hitting the BUG_ON() in a scenario as explained in the commit message of what is now the second patch in this series. After posting, sashiko.dev noticed another issue, that was previously masked by the now-removed BUG_ON(). Since we can't have a loud BUG() be replaced with silent data corruption or worse, I've also added a patch to address this issue highlighted by sashiko.dev. I believe its observation and analysis to be correct. Cheers, Andre' Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v3: - Philipp: - patch 1: update kerneldoc, add Fixes: - patch 2: shorten commit message - explicitly Cc: stable - collect tag - Link to v2: https://lore.kernel.org/r/20260708-linux-drm_crtc_fix2-v2-0-cf72be75d75a@li… Changes in v2: - add new patch 1 to address sashiko observation - original patch 1 becomes patch 2 - patch 2: - don't turn fence_to_crtc() into macro (Jani, Philipp) - update commit message to include reference to deprecated use of BUG - Link to v1: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@li… --- André Draszik (2): drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() drivers/gpu/drm/drm_crtc.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

9 hours, 13 minutes

Master the Beat: A Guide to Conquering Geometry Dash Lite

by xenogeneic.monkey.zmpr＠hidepost.net

In the vast and ever-expanding universe of mobile games, some titles manage to capture our attention with their deceptively simple premise and incredibly addictive gameplay. Among these gems, geometry dash lite stands out as a vibrant, challenging, and endlessly replayable experience. It's a game that will test your reflexes, your rhythm, and occasionally, your sanity, but ultimately reward you with an immense sense of accomplishment. If you've ever found yourself wondering about the captivating world of Geometry Dash Lite, or are looking to dive in for the first time, this guide is for you. https://geometrylitepc.com/ Introduction: The Rhythm of the Cube At its core, Geometry Dash Lite is a rhythm-based platformer. You control a small, customizable cube (or other geometric shapes you unlock later) as it automatically progresses through a series of levels filled with spikes, sawblades, moving platforms, and an array of other fiendish obstacles. Your only interaction is a simple tap or click – a tap makes your cube jump, and holding it down allows for continuous jumps or different movements depending on the game mode. The magic truly happens when this simple mechanic is perfectly synchronized with the pulsating electronic soundtrack that accompanies each level. Every jump, every dodge, every perilous leap feels intrinsically linked to the beat, transforming the game into a thrilling, high-octane dance. While the "Lite" version offers a taste of the full Geometry Dash experience, it's a fantastic starting point, providing several introductory levels and a glimpse into the game's creative potential. It’s also surprisingly robust for a free offering, giving players plenty of content to sink their teeth into before potentially exploring the full game. For those looking to experience this on a larger screen or with keyboard controls, you can even find versions of geometry dash lite for PC. Gameplay: A Symphony of Spikes and Jumps The gameplay of Geometry Dash Lite, while simple in its control scheme, is incredibly diverse in its execution. Levels are meticulously designed, often showcasing an almost artistic level of creativity in their layout and obstacle placement. Here’s a breakdown of what you can expect: The Cube: This is your primary form. A simple tap makes it jump. Holding down allows for multiple smaller jumps, crucial for navigating stair-like obstacles. The Ship: Upon entering a ship portal, your cube transforms into a small spacecraft. Now, holding down makes it fly upwards, and releasing makes it descend. Precision control is key here to weave through tight corridors. The Ball: The ball rolls automatically, and a tap reverses its gravity, allowing it to stick to the ceiling or floor. This mode requires quick judgment and timing. The UFO: Similar to the ship, but with a "flappy bird" like mechanic. Each tap provides a small burst of upward momentum, allowing for more controlled vertical movement. The Wave: This mode introduces diagonal movement. Holding down makes the wave move upwards at an angle, and releasing makes it move downwards. This is often considered one of the more challenging modes due to its unique trajectory. The Robot: Similar to the cube, but with variable jump heights. A short tap provides a small hop, while holding down allows for a much larger jump. The Spider: This mode instantly teleports your spider to the nearest solid surface with a tap, allowing for rapid vertical and horizontal traversal across ceilings and floors. Beyond these core transformations, levels often incorporate speed changes, gravity flips, mirror mode, and anti-gravity zones, constantly keeping you on your toes and forcing you to adapt your strategy on the fly. The visual style is characterized by bright, neon colors and geometric shapes, making each level a vibrant spectacle even amidst the constant threat of instant demise. Tips for the Aspiring Dash-er Conquering Geometry Dash Lite isn't just about fast reflexes; it's about learning, adapting, and developing a keen sense of rhythm. Here are some friendly tips to help you on your journey: 1. Start Slow (and be patient!): The Lite version offers introductory levels. Don't rush into the harder ones. Practice the basics, understand how each game mode feels, and build your confidence. Expect to fail, a lot. It’s part of the learning process! 2. Listen to the Music: This is perhaps the most crucial tip. The music isn't just background noise; it's a guide. Many jumps and movements are perfectly timed with the beat. Internalizing the rhythm will significantly improve your performance. 3. Practice Mode is Your Friend: Every level has a practice mode where you can place checkpoints. Use this extensively to break down difficult sections. Practice specific sequences until they become second nature. Don't be afraid to spam checkpoints in a tricky spot. 4. Learn from Your Deaths: Don't just get frustrated when you die. Take a moment to understand why you died. Was your jump too late? Did you hold down for too long? Each death is an opportunity to learn and refine your approach. 5. Focus on Small Segments: Instead of trying to perfect an entire level at once, focus on mastering small, manageable sections. Once you've got a segment down, try to link it with the next one. 6. Don't Overthink It: Sometimes, the best approach is to trust your instincts and the rhythm. Overthinking can lead to hesitation, which is often fatal in Geometry Dash. 7. Customize Your Icon: While purely aesthetic, having an icon you like can boost your motivation. Experiment with the different unlockable shapes and colors! 8. Take Breaks: Frustration is inevitable. If you find yourself getting angry or making more mistakes, step away from the game for a bit. Come back with fresh eyes and a calm mind. Conclusion: A Rewarding Challenge Geometry Dash Lite is more than just a game; it's an exercise in patience, persistence, and pattern recognition. It's a game that will push your limits, challenge your assumptions, and ultimately, provide a deeply satisfying sense of achievement when you finally conquer a level that once seemed impossible. Its vibrant aesthetics, infectious soundtrack, and deceptively simple controls make it accessible to anyone, yet its intricate level design offers endless depth for those willing to commit. So, if you're looking for a game that will test your reflexes, groove to a pumping beat, and reward your perseverance, then dive into the world of Geometry Dash Lite. You might just find your next obsession.

12 hours, 1 minute

Re: [PATCH v5 4/5] rust: Add dma_fence abstractions

by Philipp Stanner

On Fri, 2026-07-17 at 14:14 -0300, Daniel Almeida wrote: > > > > > > + try_pin_init!(Self { > > > > + // SAFETY: `dma_fence_context_alloc()` merely works on a global atomic. > > > > + // Parameter `1` is the number of contexts we want to allocate. > > > > + nr: unsafe { bindings::dma_fence_context_alloc(1) }, > > > > + seqno: AtomicU64::new(0), > > > > > > Do we really need to force a 0 here? i.e.: can’t we take the initial seqno > > > as an argument? > > > > We could. What would that be useful for? > > > On Mali, the hardware syncobj starts at 0. If you see a 0, is this the default > state, or should you signal seqno 0? > > This problem goes away if we can have seqnos starting at a custom value, like > 1. It seems like the C machinery also special-cases 0 in a few other places too. ACK. > > > > > Hm, no, we don't. > > > > For the most part that's irrelevant, since all critical components then > > only get set in new_fence(). Correct typization is enforced through T. > > > > The notable exception is the fence_ctx reference itself. > > > > What should we do about it? > > > > We could keep the fctx field as a MaybeUninit and set it later. Or we > > check through the fctx identifier number whether it's the correct one > > in new_fence(), but then new_fence() could fail with some error, and > > it's probably better to have it be completely fail-free. > > Agree about the fail-free part. > > The problem I see here is that new_fence() will use "seqno" and "nr" from > whatever context called new_fence(), but DriverFenceAllocation has some other > (possibly unrelated) context as its DriverFenceData::fctx. > > The lifetimes are apparently broken too, because 'a is the lifetime of the > context where new_fence_allocation was called, meaning that the context that > actually called new_fence() can drop, even though it provided the state for > dma_fence_init(). > > I guess this can be solved by moving new_fence() to impl DriverFenceAllocation? > That already has a context, and most importantly, the right context. Yes that is / was broken. Having the wrong fctx would cause wrong container_of() calls and therefore explode. Fixed it locally following your suggestion of creating fences on the allocation object. > > […] > > > > + > > > > +/// The receiving counterpart of a [`DriverFence`], designed to register callbacks > > > > +/// on, check the signalled state etc. A [`Fence`] cannot be signalled. > > > > +/// A [`Fence`] is always refcounted. > > > > > > I would explain this a tad better. > > > > What exactly? The refcounting? The dualism between DriverFence and > > Fence? :) > > For example, you say “a Fence cannot be signaled”. A person seeing this > code for the first time might ask why. Specially if they start by reading the > docs for Fence first. > > I think explaining a bit more about the DriverFence/Fence/refcounting as you > said is already enough to settle it. OK, I flesh that out a bit. > > > […] > > > > + let ret = unsafe { bindings::dma_fence_is_signaled(fence) }; > > > > + > > > > + // To guarantee that an API caller can 100% rely on the signalling being > > > > + // completed (i.e., all fence callbacks ran), we have to take the lock. > > > > + // > > > > + // The reason is that the C dma_fence backend currently does not carefully > > > > + // synchronize the `dma_fence_is_signaled()` function with the proper > > > > + // spinlock. This can lead to the function returning `true` while fence > > > > + // callbacks are still being executed. This can be mitigated by guarding > > > > + // the entire function with the spinlock. > > > > + // > > > > + // See commit c8a5d5ea3ba6a. > > > > + > > > > + // SAFETY: `fence` is valid because `self` is valid. `flag_ptr` is > > > > + // merely a pointer to an integer, which lives as long as this function. > > > > + unsafe { bindings::dma_fence_lock_irqsave(fence, flag_ptr) }; > > > > > > Shouldn’t this be before the “is_signaled” ffi call? Or is this > > > only about ensuring all callbacks have run? i.e.: is “ret” valid even > > > though it was computed before taking the lock? > > > > OK, this is where it gets ugly. > > > > So during the last weeks I've been struggling to get the C backend into > > better shape. One issue from my POV is that the C dma_fence spinlock > > does not protect the fence state; there is insistence that the lock > > shall only protect the callback list. > > > > The function dma_fence_is_signaled() has an unlocked fast path check: > > > > https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/dma-fence.h#… > > > > whereas setting of that bit is done under lock-protection: > > > > https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/dma-buf/dma-fence.… > > > > > > This can lead to funny races like in the commit mentioned in the > > comment block above (c8a5d5ea3ba6a). > > > > And it also leads to weird hacks like this: > > > > https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/gpu/drm/amd/amdgpu… > > > > > > Now, in principle I agree with you that a pattern like this: > > > > dma_fence_lock_irqsave(…); > > let signaled = dma_fence_is_signaled_locked(…); > > dma_fence_unlock_irqrestore(…); > > > > would be better. > > > > However, lengthy discussions with Christian seem to settle at the point > > where Christian sees the very strict requirement of never calling fence > > callbacks under lock protection, and where he views > > dma_fence_is_signaled_locked() as a broken function that should be > > removed. > > > > He's currently working on removing all bits where fence callbacks are > > invoked under lock protection: > > > > https://lore.kernel.org/dri-devel/20260624122917.2483-1-christian.koenig@am… > > > > There's been a ton of discussions and proposals about that in recent > > weeks > > > > https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/ > > https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or… > > > > > > So tl;dr: The weird code you're commenting on above ensures that > > > > a) the fence->ops->is_signaled() callback is not called under lock > > protection and > > b) taking and releasing the lock guarantees that all callbacks are > > really finished, i.e. they have run. > > > > > > (I continue to believe that setting the bit under lock protection and > > reading it without lock is fundamentally broken and needs to be fixed, > > but fixes are being rejected because of claimed performance regressions > > years ago when this was tried, because checking the bit is some sort of > > fast path check for.. parties that spin on dma_fence_is_signaled() ??) > > I see, there is a lot more context on this then. Can you merely add a comment > saying it’s ok to call dma_fence_is_signaled() without the locks? Otherwise > people might try to “fix” this down the line... I tried to make it clear with the comment above: // To guarantee that an API caller can 100% rely on the signalling being // completed (i.e., all fence callbacks ran), we have to take the lock. // // The reason is that the C dma_fence backend currently does not carefully // synchronize the `dma_fence_is_signaled()` function with the proper // spinlock. This can lead to the function returning `true` while fence // callbacks are still being executed. This can be mitigated by guarding // the entire function with the spinlock. // // See commit c8a5d5ea3ba6a. I can try to make it more explicit. Actually, I suppose with our design in Rust we would not actually need this lock-unlock, because we ensure that it does not matter whether a callback already ran. But since we don't know who will be working on this in 5 years, adding this or that exotic callback, or maybe registering callbacks on his own fence, I put this sequence there for robustness. So if the function returns true, you really know that all callbacks are gone forever. > > > > > > > > > > > > > > […] > > > > > > > > > > + /// The API user's data. This must either not need drop, or must delay its > > > > + /// drop by a grace period. It is essential that the data only performs > > > > + /// operations legal in atomic context in its [`Drop`] implementation. > > > > + #[pin] > > > > + data: T::FenceDataType, > > > > +} > > > > + > > > > > > > > […] > > > > > > + > > > > + // DriverFenceData is repr(C) and a Fence is its first member. > > > > > > > + let fence_data_ptr = fence_ptr as *mut DriverFenceData<'a, T>; > > > > > > Without a “CAST:” keyword, I think this will trigger the linter? > > > > > > > Didn't see a complaint from clippy nor compiler. > > I recommend the CAST thing anyways. It’s being adopted in other parts of the kernel > crate. I can write a CAST comment, no problem. Thx P.

12 hours, 8 minutes

Conquer the Canvas: A Beginner's Guide to Paper.io 2

by junior.kiwi.rhoh＠hidepost.net

If you've ever found yourself scrolling through mobile game recommendations, chances are you’ve stumbled upon the delightful world of .io games. These simple yet addictive multiplayer experiences often involve claiming territory, growing in size, and outsmarting opponents. Today, we're diving into one of the most charming iterations of this genre: Paper.io 2. https://paperio2free.com Introduction: The Art of Expansion Paper.io 2 is an incredibly accessible and surprisingly strategic game that will hook you from the first few minutes. Imagine a blank canvas, your digital playground. Your goal? To fill as much of it with your color as possible, while simultaneously fending off other players vying for the same real estate. It's a satisfying blend of quick reflexes and cunning territorial acquisition, perfect for a quick break or a longer gaming session. Gameplay: Drawing Your Empire The core gameplay of Paper.io 2 is elegantly straightforward. You control a small, colored square that moves across a large, open map. As you move, you leave a trail, and when you connect that trail back to your own already claimed territory, the enclosed area becomes yours. This is how you expand your domain. The catch? While you're drawing a trail outside your territory, you're vulnerable. If another player crosses your line before you connect it, you're eliminated. Conversely, you can eliminate other players by crossing their exposed trails. The game constantly balances offensive expansion with defensive awareness, creating a dynamic and engaging experience. There are also smaller, neutral blocks that appear, offering bonus points if you claim them, and other players' "ghosts" – their claimed territory without their active player, which can be claimed by others. Tips for Aspiring Conquerors: Start Small, Grow Big: Don't go for huge swathes of land right off the bat. Focus on securing smaller, manageable areas first to build a solid base. Large expeditions leave you exposed for longer. The Art of the Cut: Your primary weapon is the ability to cut off other players' lines. Pay attention to where others are expanding and look for opportunities to quickly cross their trail for an easy elimination. Protect Your Perimeter: Your existing territory acts as your safe zone. When you're making a move, always have an escape route back to your claimed land. Don't get trapped in a corner! Observe and Adapt: Look at the map. Are there aggressive players nearby? Is a section of the map relatively empty? Adjust your strategy based on the current situation. Sometimes a defensive play is better than a risky offensive one. Don't Be Afraid to Die (Initially): In the beginning, you'll likely be eliminated often. Don't get discouraged! Each elimination is a learning opportunity. Pay attention to how others defeat you and incorporate those lessons into your own playstyle. Conclusion: The Joy of Simple Domination Paper.io 2 is a fantastic example of a game that's easy to learn but offers surprising depth. Its minimalist design and intuitive controls make it accessible to everyone, while the competitive element keeps you coming back for more. Whether you're looking for a casual distraction or a challenging multiplayer experience, Paper.io 2 offers a rewarding journey of territorial conquest. So, fire it up, start drawing, and see if you can claim the largest slice of the canvas!

13 hours, 1 minute

Nongnong Alternative Guide: How to Find Profiles on Fiwfan

by Thomsanjackson605＠gmail.com

If you’re searching for a Thailand dating platform that feels easier to browse and more straightforward to use, a good nongnong alternative is often the first thing people look for. The idea is simple: you want to find real profiles quickly, filter what you care about, and spend less time scrolling through clutter. Fiwfan is positioned as a Thailand-focused dating directory where users can discover profiles based on location and preferences, then decide who to reach out to. Switching from nongnong to Fiwfan can feel appealing when you want a smoother “find-and-review” flow. Rather than hunting around for relevant details, you can start with the basics—like the area you’re interested in and the type of profile you want to see—and then open listings that look promising. In practice, this means faster browsing on mobile, clearer profile summaries, and a more organized way to compare options across different locations in Thailand. Here’s a practical guide to finding profiles on Fiwfan: First, start by setting your location preferences. If you’re based in Bangkok, Chiang Mai, Pattaya, Phuket, or another city, focus on the areas where you’re most likely to connect. Narrowing by region helps you avoid irrelevant listings and keeps your results more relevant to real life plans. Next, use the browsing filters available in the app experience. Look for options related to profile highlights, age range, and other user-facing details. The best strategy is to filter enough to reduce noise, but not so much that you miss good matches. Think of filters as “shortlisting tools,” not strict barriers. https://fiwfan.app/nongnong-alternative

13 hours, 13 minutes

Re: [RFC PATCH net-next 08/13] drm/amdkfd: add GPU instruction emitter and disassembler

by Andrew Lunn

On Mon, Jul 20, 2026 at 10:05:33PM +0200, Natalie Vock wrote: > On 7/19/26 19:58, Taehee Yoo wrote: > > Add the AMD GCN (gfx9/gfx10) instruction encoder used to build the GPU > > shaders that knod dispatches, plus a matching disassembler used for > > debugging the generated code. > > Is it really necessary to have a full-on compiler and disassembler in the > kernel driver? This patch is massive and I'm wondering how much benefit it > really provides. Is there really no way to move GPU compilation out of the > kernel, one way or another? Could you get acceptable perf with a static > shader that interprets BPF programs at runtime? Such a shader can be > compiled beforehand and just embedded into the kernel - there's prior art > there with the CWSR trap handler in amdkfd. > > In case you really, really need to compile the BPF to native ISA, could you > still have userspace take care of that in one way or another? There was a long and painful discussion about P4, and offloading it to hardware. The proponents of that wanted to do the compilation stage in user space to produce a binary blob, but it was hard to prove that the P4 passed to the kernel for software processing, and the binary blob passed to the hardware actually where the same. It opened up the path for closed source P4 where the kernel never got to see the actual P4 code. So it was not really offload, but kernel bypass. So having a compiler in the kernel is probably the correct way to go, if you want to be friendly to open source. The other option is to get the GPU to do the compilation itself, so you pass BPF byte codes to the GPU and it generates its own native code. I've no idea if that is possible, but clang can target OpenMP, so maybe it is possible to move this compiler into the GPU? Andrew

23 hours, 39 minutes

[PATCH v2 0/2] drm/drm_crtc: dma_fence_ops fixes

by André Draszik

Hi, These patches fix two issues in the drm/drm_crtc driver. Initially I was hitting the BUG_ON() in a scenario as explained in the commit message of what is now the second patch in this series. For the reasons outlines there, the BUG_ON() should just be removed. After posting, sashiko.dev noticed another issue, that was previously masked by the now-removed BUG_ON(). Since we can't have a loud BUG() be replaced with silent data corruption or worse, I've also added a patch to address this issue highlighted by sashiko.dev. I believe its observation and analysis to be correct. Cheers, Andre' Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v2: - add new patch 1 to address sashiko observation - original patch 1 becomes patch 2 - patch 2: - don't turn fence_to_crtc() into macro (Jani, Philipp) - update commit message to include reference to deprecated use of BUG - Link to v1: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@li… --- André Draszik (2): drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() drivers/gpu/drm/drm_crtc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474 change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

1 day, 8 hours

Slice Master: A Relaxing Game of Timing and Precision

by profound.cheetah.kect＠hidingmail.net

Some games are enjoyable because they are challenging, while others are fun because they are simple to understand and easy to pick up. Slice Master belongs to the second category. It offers a straightforward concept: control a moving blade and slice objects while avoiding obstacles. Although the rules are easy to learn, improving your accuracy and reaching higher scores can take patience. The game is suitable for short breaks, casual play, or anyone who enjoys timing-based challenges. Each level introduces new situations, making the experience feel fresh without overwhelming players with complicated instructions. https://slicemasterfree.com Gameplay The main goal is to guide the blade through each level and cut as many suitable objects as possible. In many stages, the blade moves automatically, while the player controls its direction by clicking, tapping, or pressing a key. The timing of each movement is important. Players need to watch the layout carefully. Some objects are safe to slice, while others may slow progress, end the round, or send the blade in an unexpected direction. Platforms, gaps, spikes, and other obstacles can make even a simple level surprisingly tricky. As you continue, the game often becomes a test of rhythm and reaction. Instead of rushing, it helps to observe the movement pattern and decide when to make the next input. The satisfying part comes from completing a sequence of clean cuts and reaching the goal with good control. Tips for Better Results First, focus on timing rather than speed. Moving too quickly can cause the blade to miss targets or hit an obstacle. Wait for the right opening, especially when several hazards appear close together. Second, learn from mistakes. If a level ends unexpectedly, think about what caused it. You may have jumped too early, approached an obstacle from the wrong angle, or overlooked a safe platform. Repeating the stage with that information can make the next attempt much easier. It is also useful to keep your movements small and deliberate. Sudden changes may be difficult to correct, while gentle adjustments give you more control. When a level contains multiple targets, consider the safest route instead of trying to slice everything immediately. Finally, take breaks when the game starts to feel frustrating. Returning with a clear mind often improves concentration and reaction time. Conclusion Slice Master is an accessible game built around simple controls, quick decisions, and satisfying progress. Its appeal comes from the balance between easy-to-understand gameplay and increasingly demanding levels. Whether you play for a few minutes or try to improve your best run, it offers a pleasant way to practice timing and precision. For players who enjoy casual challenges, Slice Master is worth experiencing. Just stay patient, watch the obstacles, and let each attempt teach you something new.

1 day, 11 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig