ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<soreau>
sounds like a delicious pizza
<dcbaker>
Sounds like it's the kind of pizza you can't tell the difference between the pizza and the box
<soreau>
mmm.. cardboard
co1umbarius has joined #dri-devel
<ccr>
as long as there's enough cheese and garlic, even cardboard is fine
columbarius has quit [Ping timeout: 480 seconds]
Company has quit [Read error: No route to host]
Company has joined #dri-devel
jewins1 has joined #dri-devel
nchery has quit [Quit: Leaving]
jewins has quit [Ping timeout: 480 seconds]
jhweruyuw has quit [Remote host closed the connection]
<kaylie>
you sure that's fine?
<dcbaker>
Probably better for you than most fast food
hch12907 has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<haagch>
just one question, VK_EXT_display_control requires VK_KHR_DISPLAY, so I assume it will only work when used while controlling a display, and not when running in a window in X11?
<haagch>
could I expect VK_DISPLAY_EVENT_TYPE_FIRST_PIXEL_OUT_EXT to return something sensible when running in a window or should I not even bother?
<airlied>
the latter
<haagch>
fair enough
<haagch>
reading the spec also helps... This extension defines a set of utility functions for use with the VK_KHR_display and VK_KHR_display_swapchain extensions.
vivijim has quit [Ping timeout: 480 seconds]
<Kayden>
jekstrand: nice, R-b
rsripada has quit []
rsripada has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
Sumera[m] is now known as Sumera
Company has quit [Read error: Connection reset by peer]
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
ppascher has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom1 has quit [Read error: Connection reset by peer]
Luc has joined #dri-devel
idr has quit [Quit: Leaving]
Duke`` has joined #dri-devel
mranosta1 has quit []
Luc has quit [Remote host closed the connection]
tarceri has quit [Ping timeout: 480 seconds]
tarceri has joined #dri-devel
JohnnyonFlame has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
jewins1 has quit [Remote host closed the connection]
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tzimmermann has joined #dri-devel
itoral has joined #dri-devel
mlankhorst has joined #dri-devel
shashank1202 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mattrope has quit [Remote host closed the connection]
Danct12 has quit [Ping timeout: 480 seconds]
javierm has quit [Remote host closed the connection]
muhomor has joined #dri-devel
javierm has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
fxkamd has quit []
hch12907 has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
danvet has joined #dri-devel
bcarvalho_ has joined #dri-devel
bcarvalho has quit [Read error: Connection reset by peer]
Lyude has joined #dri-devel
Ahuj has joined #dri-devel
Lyude has quit []
frieder has joined #dri-devel
Lyude has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
rgallaispou has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
adjtm has quit [Quit: Leaving]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<mripard>
danvet: regarding the discussion we had yesterday about the scrambler state restoration, you mentioned you'd like a lock assertion. about which lock and in which function? connection_mutex in detect()?
shashank1202 has quit [Quit: Connection closed for inactivity]
bcarvalho_ has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
kmn has joined #dri-devel
lynxeye has joined #dri-devel
<vsyrjala>
mripard: btw in i915 we do a full modeset from hotplug if scdc settings are borked. initially i just rewrote the scdc regs but someone pointed out it's not really spec compliant behaviour
<pq>
HdkR, sorry, I've no idea what you're talking about re: free.
<mripard>
vsyrjala: so reusing the same mode?
<vsyrjala>
yeah, we just turn it off and on again
<vsyrjala>
it==crtc
pcercuei has joined #dri-devel
<mripard>
vsyrjala: do you know in which function that occurs?
<HdkR>
pq: When you're mixing allocators. Mixing what a library allocates versus the application allocates can be messy. Something like `xcb_poll_for_event` the pointer that is returned is expected to be passed to `free` rather than back in to the API
<vsyrjala>
mripard: intel_hdmi_reset_link()
<vsyrjala>
though i must admit the simple scdc frobbing approach did actually work on the lg tv i was testing it on. but as mentioned not entirely spec compliant so ended up using the big modeset hammer instead
<pq>
HdkR, off the top of my head, I can't recall a single instance of such in either libwayland-client or -server API. But if there are any, they are very likely documented.
<HdkR>
pq: Nice. That doubly confirms that the API in wayland is more sane in this regard :)
<mripard>
vsyrjala: awesome, thanks
<pq>
HdkR, sanity is the eye of the beholder, some people do not like callback architecture.
<mripard>
(it's also surprisingly straightforward, I was expecting something much more complex :))
<pq>
+in, +the - my fingers are slower than my thoughts
<HdkR>
pq: I'm sure once I'm thunking Wayland I'll be back to complain :D
elongbug has joined #dri-devel
gpuman has joined #dri-devel
pnowack has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
gpuman has quit [Remote host closed the connection]
gpuman has joined #dri-devel
<danvet>
vsyrjala, mripard maybe should have that as a helper, with ww_ctx wired up in detect_ctx it should all fit even when using probe helpers like vc4 does
<danvet>
mripard, it's modeset locks, since you need to protect against modesets
<danvet>
but also, we take them in probe helpers for you, otherwise there would be too many bugs
<mripard>
(also, can I merge the hotplug series for vc4 that implements it in detect, or would you prefer to have the helper first?)
<danvet>
mripard, I think your new helpers are fine, and the conversion to full modeset sits strictly on top
<danvet>
so imo merge that already
<danvet>
mripard, wrt your question
<danvet>
grabing the right drm_modest_lock and looking at ->state does not actually guarantee that you're in sync with hw state
<danvet>
which might anger your hw
<danvet>
because atomic can be committed asynchronously in a worker
<danvet>
so if you have a caller from different context which also touches hw state
<danvet>
you either need to have a spinlock, which both hw touching functions take
<danvet>
and a copy of relevant state protected by that spinlock, outside of existing atomic locks
<danvet>
or you need to get the other caller to essentially do a full atomic commit
<danvet>
which means dropped frame
<danvet>
which is probably not what you want for an app enabling/disabling audio on hdmi
<danvet>
hence why I recommended spinlock
<danvet>
ok so strictly speaking you can do the same trick as async plane commits, where you just wait for the previous commit to finish, and then punch in the new register values
<danvet>
that would avoid the dropped frame I think
<danvet>
maybe something we'd want to extract as a helper
<danvet>
something like drm_crtc_lock_and_sync or so, dunno
* danvet
should catch up on dri-devel and type this stuff there
slattann has joined #dri-devel
gpuman has quit []
<vsyrjala>
danvet: don't think we can use a helper in i915 because of bigjoiner hw vs. uapi state stuff
<mripard>
danvet: so we need one spinlock to avoid the audio and display paths from modifying the hardware registers at the same time, ok. I'm still not sure why we would need to protect our state copy by that same spinlock. Wouldn't a mutex that guard all display and audio functions enough there?
angerctl has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
<alyssa>
Is there a way to get at this from a Gallium driver?
<alyssa>
I have a bit corresponding to STATE_FB_PNTC_Y_TRANSFORM, so I don't need/want the NIR lowering.
angerctl has quit [Ping timeout: 480 seconds]
<alyssa>
oh, err, that /is/ accessible as sprite_coord_mode isn't it
<alyssa>
I thought that was only for point sprites but that also affects gl_PointCoord apparently?
<alyssa>
oh but that's only set if PointSprite is actually enabled.
<danvet>
mripard, because crtc->state isn't actually hw state
<danvet>
so either you read back actual hw state from registers
<danvet>
or you update in in your atomic_commit_tail functions under a spinlock in a sepearate copoy
<danvet>
*copy
<danvet>
->state is only the state that the hw will have once all pending atomic commits completed
<alyssa>
I guess I could make a CAP for "sprite_coord_mode affects gl_PointCoord even without point sprites" and then all should work
angerctl has joined #dri-devel
<alyssa>
I suspect a bunch of drivers could set that but I don't know if everyone can.
<alyssa>
robclark: It looks like Freedreno could implement that one just by deleting code
<alyssa>
Maybe this is worth spinning an RFC for
<alyssa>
(Don't force coord_mode=true in ir3_point_sprite, drop the coord_mode argument, and that's it)
slattann has quit []
<mripard>
danvet: I think I can't figure out the "threat model". Assuming we copy the current CRTC mode (it's all w'ere interested in in vc4) over in mode_set, what scenario would be broken that we need a spinlock to protect the copy of the mode?
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
<pcercuei>
Is there a simple program that shows how to do cross-device synchronization of dmabufs?
itoral has quit [Remote host closed the connection]
<dj-death>
jenatali: thanks a bunch for the quick rb
<jenatali>
dj-death: Thanks for the fix :)
leandrohrb0 has quit []
fahien24 has joined #dri-devel
leandrohrb3 has joined #dri-devel
padovan8 has joined #dri-devel
<mareko>
tracie doesn't show anything, I need to push a commit that changes line rasterization for radeonsi, which means I might have to disable the pipeline if I can't get the hashes
<dj-death>
jenatali: do you have a CI for clon12? just for checking that it compiles
<jenatali>
dj-death: The compiler is built and runs some unit tests as part of the Windows CI pipelines
<jenatali>
I don't currently have CI for the external runtime, but if I ever get time I'd love to set that up
<dj-death>
jenatali: okay thanks
thellstrom has joined #dri-devel
sneil_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sneil has quit [Ping timeout: 480 seconds]
<Venemo>
who is the release manager for the next mesa release 21.3? can we please have a GitLab milestone for this next release so we can mark MRs?
<Venemo>
ajax: thanks! I was unsure if I can simply create it on my own so I thought better to ask here
<ajax>
i think you can, in the sense that gitlab's Developer role has the power. and i think you may, in the sense that nobody's likely to object to making labels or milestones for pretty much anything.
<ajax>
with the caveat that an issue or an mr can only be on one milestone but could have N labels
JoshuaAshton has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sukbeom has quit [Remote host closed the connection]
sukbeom has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<jekstrand>
bnieuwenhuizen, hakzsam: Could one of you take a look at why https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045 is blowing up? Part of it is definitely the switch to VK_DECL helpers for to/from handle. Likely, RADV has some object that isn't actually a vk_object_base.
<jenatali>
dj-death: I see you took the WIP tag off !9156, does that mean I should start reviewing, or are you still planning to make bigger changes?
<dj-death>
jenatali: I think that's it for code moving
<dj-death>
jenatali: I think there will be a follow up to make clang/llvm detection better (and actually work on my ubuntu)
<dj-death>
jenatali: so if you have time please take a look :)
<jenatali>
dj-death: Cool, sounds good. I also really wanted to merge that with Clover's detection at some point, which is why I'd been trying to get Clover to build/work on Windows
<ajax>
wtf why is GALLIUM_THREAD=0 not working
nchery has joined #dri-devel
<MrCooper>
define "not working"
<ajax>
i run my program in gdb and it says [New Thread 0x7fffed76a640 (LWP 3637433)] at me a bunch of times.
<MrCooper>
there are many other threads, e.g. llvmpipe's rasterizer threads or shader compiler threads
<ajax>
and then later, i get an assert thrown, _and then_ gdb hits the breakpoint i set on xcb_present_pixmap, rather than stopping in the thread what asserted
<imirkin>
is it gallium or gallivm? should double-check
<MrCooper>
GALLIUM_THREAD is about the Gallium API thread only
<ajax>
and the xcb_present_pixmap's bt starts with clone() not main()
<ajax>
so... i confuse
<zmike>
that's the wsi thread
<zmike>
there's a separate env var for disabling that iirc
gawin has joined #dri-devel
<ajax>
MESA_STOP_THREADING_FFS=1
<zmike>
dj-death I think may remember?
<dj-death>
hmm... I don't sorry :(
* zmike
shakes fist
<HdkR>
If it is the vulkan WSI thread, force the present mode to not be fifo right?
<HdkR>
MESA_VK_WSI_PRESENT_MODE=immediate I guess?
<HdkR>
Or mailbox if immediate doesn't work
<Kayden>
there isn't a way to shut off threaded compilation either
<Kayden>
there's sync_compile=true but that just makes compiles synchronous - they're still done in threads.
<HdkR>
Is that the one that goes away if you lie to mesa and say there is only one host CPU core?
<MrCooper>
HdkR: AFAICT the thread is created for all present modes now with Xwayland
flibitijibibo has quit [Remote host closed the connection]
fxkamd has quit []
fxkamd has joined #dri-devel
<HdkR>
huh
flibitijibibo has joined #dri-devel
frieder_ has joined #dri-devel
frieder has quit [Read error: Connection reset by peer]
<jenatali>
jekstrand: For your image var mode change, are you trying to keep bisectability? I.e. do I need to merge microsoft/clc or microsoft/compiler changes into existing patches or can I just throw 'em on the end?
<jekstrand>
Trying to but for the microsoft stuff it's sort of a matter of how much you care
<jenatali>
I've used bisect a total of once so far, so eh
<jenatali>
I guess what I'm really wondering is, do I need to have 2 sets of patches, one which supports both images as uniform and image, so it can go before the switchover, and one which cleans it up to only expect image after the switchover... or something like that
<gawin>
mareko: do you perhaps have an idea why r300 is (only) able to load 2d textures on n-th try? I've been playing with r481 for a week, at first all 2d textures were off, yesterday xfce menu's panel got background, today xonotic's menu started working
<ajax>
gawin: happen to know a mesa version where it did work?
<gawin>
gonna try to bisect tonight, but looks like really old bug
<jekstrand>
jenatali: If you're ok with breaking and then switching, that's fine with me.
<alyssa>
It has never been clear to me if negative stride is an intentional architectural feature or just a side effect of 32-bit adders
<imirkin>
HdkR: er, right ...
<ajax>
fun fact, xserver's fb code handles it correctly, and Xglx actually used that feature
<urja>
i assume it just happened (also, it's an effect of any bit adders as longs as they're twos complement)
<alyssa>
(I mean. Suppport for signed stride is architecturally guaranteed but why.)
jhweruyuw has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
<ajax>
probably to make y-invert easy ;)
JohnnyonFlame has joined #dri-devel
mlankhorst has joined #dri-devel
<jenatali>
jekstrand: Do your RT BVH kernels use images?
<jenatali>
jekstrand: Moving image vars from uniform to image breaks the usage of lower_vars_to_explicit_types that we use for figuring out how to lay out the kernel args in a buffer, no storage is allocated for the images... Guess I just need to add all the images to the end
<jekstrand>
jenatali: No, they don't
<jekstrand>
jenatali: Look at what I did for clover
<jenatali>
Alright, I'll take a look
<jekstrand>
jenatali: Basically, for each image var, I create a uniform
<jekstrand>
Which better maps to what's actually going on anyway
<jenatali>
Oh, ok, that's what I do with format queries already
<jenatali>
Maybe that's all I actually need, let me look closer. It's been a while
ngcortes has joined #dri-devel
<jekstrand>
No worries
<jenatali>
Ok yeah I don't need anything there. Maybe I just need to re-order things so those uniforms are created before the lower_vars_to_explicit_types
<jekstrand>
Yup
<jekstrand>
to_explicit_types assigns the memory offsets so you need all your vars there when you call it.
<jenatali>
Yeah, I need to refactor this then so we always create these uniforms (just so the runtime always has a spot to write the format/order) before that lowering
slattann has quit []
<mareko>
daniels: thanks, that helps
<mareko>
gawin: r300 is pretty much unmaintained and untested
<alyssa>
gawin: thanks for stepping up to maintain r300
<ajax>
i like how envvars.tst doesn't document $DRI_PRIME
<ajax>
sigh
<ajax>
do i really need to stick an rv370 in gitlab runner so people don't have the excuse
<daniels>
mareko: nice :) please ping me directly if anything else comes up
enilflah has joined #dri-devel
* soreau
still has the ol' P4 rig with RV350 in the closet
Ahuj has quit [Ping timeout: 480 seconds]
<soreau>
maybe could revive it as a project
* airlied
wonders if r500 are in better shape, I have a possibly working rv530 laptop still :-P
<airlied>
Test run totals: Passed: 313914/926085 (33.9%) Failed: 0/926085 (0.0%) Not supported: 612171/926085 (66.1%) Warnings: 0/926085 (0.0%) Waived: 0/926085 (0.0%)
<ajax>
not too shabby!
<airlied>
that is in theory a vk 1.2 complaint lavapipe, once I land a couple of patches and CTS lands a few fixes
<HdkR>
\o/
<Kayden>
\o/
<airlied>
pmulhrsw to the rescue for all your 8-bit filtering needs
<kisak>
congrats
<ajax>
oh word, you fixed the aos filtering thing?
<ajax>
where's my review hammer
<airlied>
fixed for ssse3 and above
<HdkR>
pmulhrsw is a good one. I emulate it with 5-9 instructions :D
<airlied>
should probably disable aos opts on linear on anything that doesn't have that instr
<ajax>
ssse3 is... core 2 but not core? sure, fine.
<HdkR>
Might need a bit of unfudging of AArch64-isms :P
<airlied>
probably still faster to use the aos path with emulated than soa anyways
<ajax>
seems like ssse3 also corresponds with gen4? ish?
rasterman has quit [Quit: Gettin' stinky!]
<gawin>
alyssa: let's wait with such powerful statement for first meaningful patch ;)
orbea1 has joined #dri-devel
orbea1 has quit []
orbea1 has joined #dri-devel
orbea1 has quit []
orbea1 has joined #dri-devel
orbea1 has quit []
orbea has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
<jenatali>
jekstrand: Heads up, I'm pushing the microsoft/clc patch to your image branch, pick it up before the next time you rebase
Bennett has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
adjtm has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Ping timeout: 480 seconds]
shashank1202 has quit [Quit: Connection closed for inactivity]
<jekstrand>
jenatali: ok
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
ybogdano_ has joined #dri-devel
ybogdano_ has quit []
ybogdano has joined #dri-devel
nchery is now known as Guest1248
Guest1248 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
pnowack has quit [Quit: pnowack]
nchery has quit [Quit: Leaving]
Gue___________________________ has joined #dri-devel
Gue___________________________ has left #dri-devel [#dri-devel]
kokoz has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
macromorgan has quit [Quit: Leaving]
gouchi has quit [Remote host closed the connection]
nchery has joined #dri-devel
<HdkR>
There's a paradigm inside of xcb that I'm seeing that I can't find documentation on. There a wackload of functions that return an array, a length, and an end. eg: xcb_depth_visuals, xcb_depth_visuals_length, xcb_depth_visuals_end
<HdkR>
I'm currently assuming that this pointer returned, from say xcb_depth_visuals, isn't owned by the application, and isn't expected for the application to free?
<HdkR>
There's so little prior art using these that it's difficult to tell
<HdkR>
As far as I can tell xcb is returning pointers to some internal arrays that the application is reading from
mbrost has quit [Ping timeout: 480 seconds]
<HdkR>
Also the fact that these aren't const qualified means the chance of an application changing some internal state is higher
<ajax>
xcb is perhaps becoming less of my favorite api, the more i use it
<HdkR>
As someone that is currently going through the entire xcb API and its extensions. Yes.
<ajax>
i really enjoyed the argument i had recently with one of the former xcb maintainers about how xcb_generate_id is a terrible design choice
<imirkin>
i bet that went over well
<ajax>
the expression where i'm from is "like a lead balloon"
<alyssa>
that wouldn't.. oh
<HdkR>
What even happens on wraparound?
<imirkin>
i'll have to keep that one in my back pocket
<imirkin>
to throw at an opportune moment
<ajax>
HdkR: what happens when you read the end of the range is xcb_generate_id throws an XC-MISC request at the server asking it to please hand back a range of unused XIDs
<ajax>
and blocks until it returns
<ajax>
now it takes the io lock while doing that, great
<ajax>
but, some other thread can have done xcb_generate_id _before_ you did the xc-misc request
<HdkR>
Which also means that any event can block, since literally everything gets an id?
<HdkR>
oh, races, nice
<ajax>
and the server's reply can include that other thread's generated xid since it hasn't yet seen the create_whatever req from that thread
<ajax>
which means literally every caller of xcb_generate_id has to be prepared to loop on BadIDChoice
<ajax>
which is: fucking stupid
<HdkR>
...yay
<ajax>
the response i got was that this is intrinsic to xcb's design and callers have to come up with some convention for handling it
<ajax>
the point that fucking libX11 itself does not adhere to such a convention apparently went unnoticed
<ajax>
forgive the colorful language but come _on_
<ajax>
oh, that too. if you're implementing a traditional xlib client library - like libGL - in terms of xcb, it's your responsibility to sync xcb's internal state into xlib before you return to your caller
<ajax>
definitely well documented, that
<ajax>
(consider what NextRequest() does, and that the canonical source of that number is in xcb not xlib)
<imirkin>
all i can say is ... i'm thankful you're around to sort this bs out :)
<HdkR>
Agreed. I'll stick to the easy stuff. Like ABI boundary data marshalling :P
<ajax>
it's not that threads are hard, you just have to decide to care
* alyssa
is ready to just Not for the duration of the night
gawin has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mranostaj has joined #dri-devel
pcercuei has quit [Quit: dodo]
camus1 has joined #dri-devel
gawin has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<kusma>
alyssa:: Haha, the negative stride thing is a feature I'm responsible for. It's an intentional thing, and it didn't work on Utgard, because not all bits are respected on the stride there...
<kusma>
It's to avoid having a gazillion flip bits all over the place that needs to be tracked and updated correctly, while making the framebuffer flipping robust (identical rasterization patterns for the backbuffer and FBOs, for instance...)
gawin has quit [Ping timeout: 480 seconds]
Bennett has quit []
iive has quit []
nehsou^ has joined #dri-devel
<alyssa>
kusma: That was you?! :-p
<alyssa>
And yet the DDK still has to emit piles of lowering code for gl_*Coord..
<anholt_>
ajax: getting some non-radeonsi radeon coverage in ci, even with a manual button, would be a big help for me for !8044
<anholt_>
Somewhere on my todo list is grab a card out of a bin and see if I can boot one of these desktops laying around. but I think they're mostly in bad shape.
<anholt_>
alternately: if someone can find me interesting boards running on 12v @ 2a, we've got options.