[Mesa-dev] [Bug 89586] Drivers/DRI/swrast

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Mar 16 23:32:14 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=89586

--- Comment #9 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Dan Sebald from comment #8)
> I cloned the piglit repository and will see if I can write a program.  It
> shouldn't be difficult once I figure out the source tree organization, but
> it might take me a couple days.

Basically the way it works is... find a simple test, and copy it. I recently
wrote tests/spec/ext_polygon_offset_clamp/*.c -- iirc 2 tests, both very
simple. Not sure when glPixelZoom came about, but it would probably go into
tests/spec/gl-1.0 or gl-2.0 or whatever. Add it to the CMakeFile.gl.txt and
you're good to go -- rerun 'cmake .' and then you should be able to do 'make
your-great-test-name'. Feel free to ask for help if you get stuck... it's all a
bit annoying as it uses cmake. At least waffle has made it to most distro's
packaging systems by now.

> 
> I see the transition happening away from swrast to Gallium, but I'm guessing
> linux bundles might still be relying on swrast as I know the other folks who
> mentioned the lines keep their systems more up-to-date.  There is also at
> least one driver in Gallium that will fall back on swrast under certain
> circumstances.

No. Gallium drivers can't fall back on swrast. There is a 'draw' module which
is used by a few drivers though to handle some (or all, in case of i915g)
vertex shader matters. Note that there's a lot of confusion with the 'swrast'
name, since the gallium software renderers can also be called swrast, and there
are 2 of them.

> 
> I was just in the process of creating a bug report for a related type of
> problem in the Gallium driver for glPixelZoom.  However, the Gallium
> organization isn't so straightforward and I've not yet figured out exactly
> which code gets run via Gallium.  Whatever is compiled is also named
> swrast_dri.so in the lib/gallium subdirectory, but it is clearly a different
> implementation of pixel zoom.  (Only the first 8192 pixels zoomed appear in
> the image while the rest is background-color, in both x and y dimensions. 
> So I can't tell if there are dropped pixels in that case just yet.)  I will
> look through softpipe and llvmpipe for the source code.

Take a look at src/mesa/state_tracker/st_cb_drawpixels.c. This is the "state
tracker" which is effectively an adapter between the OpenGL and Gallium APIs.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150317/b3637396/attachment.html>


More information about the mesa-dev mailing list