Bug 89624 - Drivers, Gallium/legacy swrast glDrawPixels differences
Summary: Drivers, Gallium/legacy swrast glDrawPixels differences
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/llvmpipe (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-18 03:07 UTC by Dan Sebald
Modified: 2019-09-18 18:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Illustration of legacy driver behavior for glDrawPixels (9.39 KB, image/png)
2015-03-18 03:09 UTC, Dan Sebald
Details
Illustration of Gallium driver behavior for glDrawPixels (5.35 KB, image/png)
2015-03-18 03:10 UTC, Dan Sebald
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Sebald 2015-03-18 03:07:54 UTC
In the following two bug reports:

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

I discussed some artifacts concerning pixels at or beyond GL_MAX_TEXTURE_SIZE in the input image.  In the first bug report I attached a patch that fixes the vertical lines in legacy swrast.  In the second I simply noted that Gallium swrast limits the image, and I think it wouldn't be too difficult to correct that.

Here I want to point out the subtle difference between legacy swrast (post patch in bug #89586) and the Gallium swrast using images with only 20 x 20 input pixels.

For legacy swrast, the attached image Screenshot-differences_legacy_swrast-annotated.png shows how the scaled image can extend past the edge of the boundary in the x-dimension, or not (and it never falls short of the boundary).  On the other hand, the image will fall short of boundary in the y-dimension, or not (and it never extends past).  I'm guessing this behavior has to do with xfactor > 0 and yfactor < 0.

For Gallium swrast, the attached image Screenshot-differences_gallium-annotated.png illustrates that scaled image aligns with the x-dimension edge (an it always seems to do so).  However, the image can extend past the bottom in the y-dimension, or not (and it seems to never fall short).

Since these two behaviors are different, as subtle as it may be, at least one of them has a bug.  I suspect that both of them might have a flaw as far as precisely following OpenGl standard.  It's interesting that the x-dimension for the Gallium driver seems most consistent.

Granted, the axis box itself may not be exact, so to say exactly what the bug is at this stage is premature, but at least the behavior of the axis box should be the same when all that is varied is the graphics driver and not the application binary.
Comment 1 Dan Sebald 2015-03-18 03:09:00 UTC
Created attachment 114412 [details]
Illustration of legacy driver behavior for glDrawPixels
Comment 2 Dan Sebald 2015-03-18 03:10:36 UTC
Created attachment 114413 [details]
Illustration of Gallium driver behavior for glDrawPixels
Comment 3 Dan Sebald 2015-03-18 16:41:08 UTC
Taking a second look at the Gallium driver PNG, I'm wondering if my original assessment is correct, i.e., that the scaled image in the frame buffer is extending past the bottom in the y-dimension.  The edges seem to align, while perhaps it is just that the axis box drawn around the image has a missing pixel in the lower right corner for some scalings.  If that is the case, perhaps it is only the legacy driver that is inconsistent, with regard to glDrawPixels.
Comment 4 Dan Sebald 2015-03-31 18:08:51 UTC
The attached images aren't very precise.  There is a Piglit test here:

https://bugs.freedesktop.org/attachment.cgi?id=114711

that might be more helpful.  The difference between the following two illustrations (i.e., that narrow green line in images 1,1 and 1,3) might be a lead:

Legacy:
https://bugs.freedesktop.org/attachment.cgi?id=114713

Gallium:
https://bugs.freedesktop.org/attachment.cgi?id=114715
Comment 5 GitLab Migration User 2019-09-18 18:31:42 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/233.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.