raphlinus

pub trait IntoRefs<'a, T: 'a> {
    type Iterator: Iterator<Item = &'a T>;

    fn into_refs(self) -> Self::Iterator;
}

impl<'a, T> IntoRefs<'a, T> for &'a [T] {
    type Iterator = std::slice::Iter<'a, T>;
    fn into_refs(self) -> Self::Iterator {
        self.into_iter()

raphlinus

use xi_unicode::LineBreakIterator;

use skribo::{AdvanceWidth, FontCollection, LayoutSession};

pub struct LayoutBuilder {
    text: String,
    default_font: FontCollection,
    default_size: f64,
    max_width: f64,
}

raphlinus

extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn widget(attr: TokenStream, item: TokenStream) -> TokenStream {
    r#"
    #[track_caller]
    fn answer() -> u32 {
        println!("{:?}", std::panic::Location::caller());
        42

raphlinus

// Fifth attempt at safe wrapper, this time using atomics to avoid race
// when dropped without holding GIL.
// User code is same as pyo3_mut_rc

mod safe_wrapper {
    use pyo3::Python;
    use std::sync::atomic::{AtomicPtr, Ordering};

    pub struct SafeWrapper<T>(*mut AtomicPtr<T>);

raphlinus

@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1

define i32 @main() #0 {
  %1 = alloca i32, align 4
  %i = alloca i32, align 4
  store i32 0, i32* %1
  call void @llvm.dbg.declare(metadata !{i32* %i}, metadata !13), !dbg !15
  store i32 0, i32* %i, align 4, !dbg !16
  br label %2, !dbg !16

raphlinus

layout	post
title	A sort-middle architecture for 2D graphics
date	2020-05-26 16:34:42 -0700
categories	rust graphics gpu

In my recent [piet-gpu update], I wrote that I was not satisfied with performance and teased a new approach. I'm happy to report that the new approach is looking very promising, and I'll describe it in some detail.

To recap, piet-gpu is a new high performance 2D rendering engine, currently a research protoype. While most 2D renderers fit the vector primitives into a GPU's rasterization pipeline, the brief for piet-gpu is to fully explore what's possible using the compute capabilities of modern GPU's. In short, it's a software renderer that is written to run efficiently on a highly parallel computer. Software rendering has been gaining more attention even for complex 3D scenes, as the traditional triangle-centric pipeline is less and less of a fit for high-end rendering. As a striking example, the new [Unreal 5] engine relies heavily on compute shaders for software rast

raphlinus

parsing time: 1.2863ms
flattening and encoding time: 1.8176ms
scene: 13239 elements
Element kernel time: 0.633ms
Binning kernel time: 0.166ms
Coarse kernel time: 0.133ms
Render kernel time: 0.001ms
start thread: 0
shared minimum element: 1
minimum element of this thread: 828

raphlinus

layout	post
title	Prefix sum on Vulkan
date	2020-04-21 11:29:42 -0800
categories	gpu

In this blog post are some initial explorations into implementing [prefix sum] on recent Vulkan. I have a rough first draft implementation which suggests that Vulkan is a viable platform for this work, but considerably more performance tuning and evaluation would be needed before I would be to claim it is competitive with CUDA. Even so, I'm posting this now, as the rough explorations may be interesting to some, and I'm not sure I'll have the time and energy to do that followup work any time soon.

Why prefix sum?

raphlinus

use kurbo::{CubicBez, ParamCurveArclen, Point};

fn randpt() -> Point {
    Point::new(rand::random(), rand::random())
}

fn randbez() -> CubicBez {
    CubicBez::new(randpt(), randpt(), randpt(), randpt())
}

raphlinus

• Writing for GPU involves breaking problems into primitives.

  • Some primitives can naturally run in parallel; this is the easy part.

  • Others are used to coordinate work between different threads.

  • An example of this is transpose of a square matrix bitmap. It is used in piet-gpu to assign work to tiles.

  • This post will examine the performance of that transpose task in detail.