No subject

up, this include the hashmap state cache that is in between the gl
state tracker and the driver. Then again that might be drowned out by
the sw vertex shader. Corbin tells me on IRC that the same applies for
r300g and the hotspots are preparing and emitting HW state, with no
hotspot within mesa or gallium, Corbin can you comment please? At
least it shows that the cso hashmap and state tracker doesn't cost
much and moving to it was a big win.

>> - Rich set of auxiliary code, much more modern than the Mesa code
>> (kind of like your GLSL compiler vs the old one). Among others, this
>> includes the draw module that by default executes vertex and geometry
>> shaders with LLVM.
>
> There are two things I find attractive about gallium, you nailed one of
> them:
>
> 1) LLVM backends for software
> 2) Not having to write texture upload/download/blit/etc. code, just the
> layout.
>
> Now, the layout's the part that we screw up the most, and you have to do
> it either way. =A0But the layout, at least as Intel does it, makes
> upload/download/copy tough, so not doing that part in the driver somehow
> would be nice (2.5kloc or so that's been copied around a few times).
> However, the fact that when I ask about performance nobody says "OMG the
> texture upload/download/copy/etc. support in gallium is so great and is
> way faster than anybody managed in classic because it catches all the
> corner cases" makes me really scared about it.

Okay here goes... The only work I did on classic mesa was on the
Unichrome texturing code and not much at that. Working with gallium
textures is for me much nicer I can't stress enough how awesome
immutable objects are to work with. At least from a driver writer
perspective and as AFAIK the immutable object approach has not caused
any performance regressions. You create the texture once and then
never have to care about it changing the size/format/levels further
down the road.

>
> I always wished that instead of gallium we had just got a reworked
> implementation of texture handling in Mesa.

But you get so much more. With Gallium being a water tight interface
we can insert different layers between the state trackers and drivers.
These include rbug the remote debugger. Trace the call tracers and
replayer. Galahad the sanity checker for debugging state trackers, in
Gallium we don't expect the drivers to do any validation of the
incoming state and any such error is regarded as a state tracker bug.
Heck you can even run a software rasterizer on top of your hardware
driver, which is nice when you want to rule other parts of the stack,
letting you remove large swaths of code form where the bug might be,
which includes all the nasty GL code.

But there is also the view of what you don't get in your driver. You
don't need to have any state validation since it should all be handled
by the state tracker as mentioned above. You don't need any dri code
since that is all handled by another state tracker that is shared
across all drivers. All you need to care about is the hardware code.

>
>> - Ability to get support for APIs other than OpenGL (e.g. the DDX
>> interface, OpenVG, with work on Cairo,
>
> These 3 only seem interesting to me once you've abstracted the hardware
> abstraction layer that you have to implement anyway, so that you want to
> talk to gallium to avoid the overhead of the abstraction layer ->
> abstraction layer translation. =A0Having written cairo on OpenGL and a
> partial implementation of X on OpenGL, if you can assume GLSL then
> OpenGL is a good interface for talking to the hardware. =A0If you can't
> assume shaders, well, gallium isn't an option anyway.
>
> I do not want to write assembly for cairo's gradients or new blend
> operators or whatever. =A0If your hardware abstraction layer doesn't give
> me a decent language to talk to in 2010, it sounds like failure.

I think Zack and Igor are the persons are the best to comment on using
the tgsi_ureg shader generator helper. But speaking from my experience
with it versus my various GLSL using projects. I found that when you
generating shader code on the fly ureg is nicer then inserting various
string snippets into glsl shader. We do have some duplication in this
case since st/x, st/vg and st/cairo implement pretty much the same
blending code and Igor is working on creating some tgsi 2d common
code.

However when you are not generating shaders on the fly and don't have
to deal with different workarounds just writing pure GLSL is of course
nicer.

>> OpenCL, video APIs) mostly for
>
> These two, on 965, want to use the media engine, so I don't see
> significant sharing to be had between a gallium OpenGL driver and a
> gallium media driver. =A0You'd share the batchbuffer code, maybe the
> buffer object handling, texture layout functions for inter-API
> interaction, what else? =A0Batchbuffers we've wanted to put into libdrm
> for years but never got around to it, and if we've got multiple things
> layouting textures, then we'd probably throw that into the shared lib
> instead of duping it, too.
>
> And, as far as video APIs, open-source codec guys tell me they want
> OpenCL or please go away. =A0Intel codec accel guys just write assembly b=
y
> hand like real men (wtf?) and stuff it in vaapi. =A0Neither of these soun=
d
> like video APIs on gallium to me. =A0(though please don't interpret this
> as me pushing vaapi. =A0The lack of a shipping gstreamer plugin for vaapi
> pretty much summarizes vaapi's relevance to me.)
>
>> - Sharing the code to support all the legacy features and weird corner
>> cases of OpenGL and not exposing the driver to them
>
> This is definitely something good, and meta.c's been mostly working for
> that in classic Mesa. =A0If we cleaned up renderbuffer handling so the
> window system FB vs FBOs weren't magic, then I'd be happy.

Cheers Jakob.