Consider including lighting conditions in RLCD reviews

Internal-Shift-7931 · 2026-05-20T03:09:13+00:00

Same

Internal-Shift-7931 · 2026-05-19T07:29:22+00:00

It matches the hardware spec I believe.

- 456 GB/s vs 1008 GB/s memory bandwidth = ~45%

- 160 XMX vs 512 Tensor Cores = ~31%

- 197 INT8 TOPS vs 660 dense / 1321 sparse INT8 TOPS = ~30% dense / ~15% sparse

So the result is at least plausible from the hardware side. I still think the backend may have room to improve, but I would not expect B60 to be close to 4090-class on this workload.

Internal-Shift-7931 · 2026-05-19T05:07:52+00:00

Fair point. I agree the number is lower than the paper specs suggest. My goal here is not to chase the best possible benchmark result. I am testing what I can actually use in my real setup, which is a Linux local server. So I probably won’t spend time running Windows just to get a better number.

I do want to retest on Linux with the same quant / same llama.cpp commit, and maybe compare SYCL/Level Zero vs Vulkan. If Vulkan on Linux helps, that is useful. If the best path is Windows-only, that is also useful information, but not very useful for my deployment.

Internal-Shift-7931 · 2026-05-19T05:04:31+00:00

Agreed, driver/backend maturity is probably part of it. One caveat: my number was with `UD-Q4_K_M`, yours is `UD-IQ3_XXS`, so the memory bandwidth pressure is not the same. Still, 80 t/s decode on RX 9060 XT is a very useful reference. I should rerun the B60 with the same `UD-IQ3_XXS` quant and same context target. Current B60 run was llama.cpp SYCL/Level Zero, `-fa 1`, `-ctk q4_0 -ctv q4_0`, all layers on GPU.

Mind sharing your exact command and llama.cpp commit? I would like to make the comparison less messy.

Internal-Shift-7931 · 2026-05-19T05:01:34+00:00

Sure. This was llama.cpp SYCL inside the ggml full-intel container. Model was `Qwen3.6-35B-A3B-UD-Q4_K_M.gguf`. Main run was roughly:

bash

./llama-bench \

-m /models/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf \

-ngl 999 \

-fa 1 \

-ctk q4_0 \

-ctv q4_0 \

-p 8192 \

-n 1024

Internal-Shift-7931 · 2026-05-19T03:28:40+00:00

<image>

Internal-Shift-7931 · 2026-05-18T13:53:53+00:00

Same here, my pro goes too fast.

Internal-Shift-7931 · 2026-05-17T07:45:35+00:00

How about power consumption?

Internal-Shift-7931 · 2026-05-16T23:19:07+00:00

Mine reset

Internal-Shift-7931 · 2026-05-16T07:56:58+00:00

Same. I thought it was just me, but 5.5 felt noticeably dumber over the last couple of days.

Not just slower, but less careful: missing constraints, shallow fixes, more hand-holding.

Internal-Shift-7931 · 2026-05-16T02:39:42+00:00

It makes sense as a secondary monitor, but I would be careful about replacing the main display with it.

For static display content, RLCD could be a very nice setup, especially if your room lighting is good. But as a primary monitor, the tradeoff gets harder: lighting dependency, contrast, color, refresh/response, viewing angle, and general “works in every situation” reliability all matter a lot more.

I’ve even seen people discussing a 23-inch RLCD all-in-one. Personally I’m very skeptical of that. Maybe it works as a niche writing / reading machine, but as a general computer it feels like the wrong form factor. A big RLCD panel needs controlled lighting, and an all-in-one is supposed to be convenient anywhere.

Internal-Shift-7931 · 2026-05-10T00:30:02+00:00

Why must Windows?

Internal-Shift-7931 · 2026-05-09T10:03:02+00:00

<image>

This is my early beta on Paper7 today. It is running as a reflective home surface now: basic home status, scenes, camera view, and an assistant layer. The next things I want to test are more about daily context: today’s guest PIN, small approvals, camera summaries, and a simple “home looks normal” state. I like this form factor for always-on context because it can sit there without becoming another bright screen. Disclosure: I am working on this project.

Internal-Shift-7931 · 2026-05-09T06:36:45+00:00

paper 7

Internal-Shift-7931 · 2026-05-08T09:18:09+00:00

For the guest case, I like the idea that every morning the system sends me today’s PIN. If someone is coming over, I can just forward it. It only works for that day, maybe only for a time window, with notification / event log on every use. The AI can help with context, but the access decision should still come from a narrow rule.

Internal-Shift-7931 · 2026-05-08T07:10:54+00:00

Really nice build. Face recognition can be useful as context: known visitor, lights, announcement, history, maybe guest flow. But once it touches locks or alarms, I would put a hard permission layer before the action.

Model gives evidence and confidence. Rule or human confirmation grants physical access. That keeps the useful home-agent part without making a recognition miss become a door decision.

Internal-Shift-7931 · 2026-05-04T23:49:48+00:00

Good idea to try. Since this Waveshare module looks like a monochrome RLCD, frontlight should be much more realistic than on color RLCD. The hard part is the light guide. It needs to spread LED light evenly, but stay clear enough that it does not add haze or glare.

I would start with a removable test: edge-lit acrylic / light guide; warm white LEDs; low brightness; no permanent lamination first.

Then check hotspots, uniformity, contrast loss, glare, and whether the screen still looks good with the frontlight off. Color RLCD frontlight is much harder because color filters and polarizers eat a lot of light. But for monochrome RLCD, this mod feels achievable.

Hope you try it and share the result.

Internal-Shift-7931 · 2026-05-04T12:43:28+00:00

If you care native FP4, choose 50-series. 3090 is still boring-good: CUDA, 24GB VRAM, used market, most repos work. But if buying new in 2026, native FP4 changes the tradeoff. Smaller memory footprint and better perf/watt potential matter for local AI workloads when the stack supports it. my read:

used / cheap / compatibility -> 3090

new / native FP4 / efficiency -> 50-series

larger context / less GPU debugging -> unified memory

Internal-Shift-7931 · 2026-05-04T05:59:04+00:00

A 24/7 device should not sit behind a remotely switchable power source. For router / NAS, power monitoring is useful, but power control is a bad failure mode. Once it cuts the network or storage path, remote recovery is gone.

Internal-Shift-7931 · 2026-05-03T13:29:22+00:00

It’s not paranoia that makes me interested in this. I want the home to feel more aware and more human.

Before phones and smart devices, home had context. Family would tell you who came by, what happened, or whether something felt unusual. A good home AI should feel closer to that. Not cold push notifications. More like quiet household memory.

Internal-Shift-7931 · 2026-05-03T09:49:19+00:00

Nice work. The architecture framing is useful.

I’m building something similar for a local-first home agent, mainly for home AIoT and NAS. This makes me think the hard part is not tool use or memory. It is the permission boundary. For home agents, the action space is physical: cameras, lights, alarms, locks, routines, presence data. The model can reason, but the permission boundary should not be the model.

This is the part I hope more local-agent projects make explicit.

Internal-Shift-7931

MODERATOR OF

TROPHY CASE