[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #46 from GitLab Migration User --- -- 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/316. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Timothy Arceri changed: What|Removed |Added Component|Other |Drivers/DRI/swrast -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114599|0 |1 is obsolete|| --- Comment #45 from Dan Sebald --- Created attachment 114715 --> https://bugs.freedesktop.org/attachment.cgi?id=114715&action=edit swrast Gallium with patch Piglit test images -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114598|0 |1 is obsolete|| --- Comment #44 from Dan Sebald --- Created attachment 114714 --> https://bugs.freedesktop.org/attachment.cgi?id=114714&action=edit swrast Gallium Piglit test images -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114597|0 |1 is obsolete|| --- Comment #43 from Dan Sebald --- Created attachment 114713 --> https://bugs.freedesktop.org/attachment.cgi?id=114713&action=edit swrast legacy with patch Piglit test images -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114596|0 |1 is obsolete|| --- Comment #42 from Dan Sebald --- Created attachment 114712 --> https://bugs.freedesktop.org/attachment.cgi?id=114712&action=edit swrast legacy Piglit test images -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114619|0 |1 is obsolete|| --- Comment #41 from Dan Sebald --- Created attachment 114711 --> https://bugs.freedesktop.org/attachment.cgi?id=114711&action=edit Piglit pixelzoom test suite An update to test results after making some modifications to SWRAST legacy changeset and the Piglit gl-1.0-pixelzoom tests: (1) swrast-legacy: The repository legacy swrast_dri.so driver for which my system and others is using and exibits vertical lines. (2) swrast-legacy-patch: The legacy swrast_dri.co patched with the changeset I originally attached to this bug report. (3) swrast-gallium: The repository Gallium/llvm swrast_dri.so driver. (4) swrast-gallium-patch: The Gallium swrast_dri.co patched by removing the line of code that limits the size of the image. TEST (1) (2) (3) (4) positive monotonic x fail pass fail fail positive edge xfail pass fail fail positive over/underrun x fail pass pass pass negative monotonic x pass pass fail pass negative edge xfail pass fail fail negative over/underrun x fail pass pass pass positive monotonic y fail pass fail fail positive edge yfail pass fail fail positive over/underrun y fail pass pass pass negative monotonic y pass pass fail pass negative edge ypass pass fail fail negative over/underrun y fail pass pass pass -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114342|0 |1 is obsolete|| --- Comment #40 from Dan Sebald --- Created attachment 114710 --> https://bugs.freedesktop.org/attachment.cgi?id=114710&action=edit Changeset to fix vertical lines and fine tune positive_unzoom_x() and negative_unzoom_x() Attached is an update to the SWRAST legacy changeset. With this change, the driver passes all tests in Piglit gl-1.0-pixelzoom check. The main addition to the changeset over the last changeset is the inclusion of a tolerance for the ceil() and floor() functions. The issue is that with single precision float division and multiplication the formula (xz - xr) / xfactor can be off by a fair amount, on the order of 10e-5. I printed out some numbers the driver was using in cases there the gl-1.0-pixelzoom alternating-line test was failing. The numbers agree exactly with this example result: octave:3> single(53)/single(400) * single(400) ans = 52.961853027 I put in a tolerance of 0.4 on the rounding functions. By my very rough estimate, I think it is possible to scale input images with dimension of about 100,000 down to typical screen sizes without the added tolerance causing its own sort of artifact. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #39 from Ilia Mirkin --- (In reply to Dan Sebald from comment #38) > I can experiment with some of the C "next nearest number" routines and get a > feeling for the ULP. Thanks. FWIW I think you're going way overboard with this. BTW, the proper way to submit tests (and any other patches), is by mailing them to the relevant list (pig...@lists.freedesktop.org in this case). -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #38 from Dan Sebald --- 0.1 tolerance is rather large (I'm guessing that applies to normalized numbers). In this case the discrepancy doesn't come close to that big. I looked up ARB_shader_precision and I'm seeing tolerance on the order of 2 to 3 units of the last place, generally, with a factor larger tolerance (16 ULP) for the pow() function. Division is the source of the error in xfactor, which has 2.5 ULP tolerance. I can experiment with some of the C "next nearest number" routines and get a feeling for the ULP. Thanks. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #37 from Ilia Mirkin --- (In reply to Dan Sebald from comment #36) > What is the general thought regarding floating point numerical issues and > the OpenGL formulas? In early GLSL versions, floating point accuracy was supposed to be to within 0.1 (i.e. pretty huge errors were allowable). However if the hw were to start introducing such errors left and right, it'd wreak huge havoc... with ARB_shader_precision (part of GL 4.1), it specifies these things fairly precisely. Not sure how that carries over to the glPixelZoom-style formulas. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #36 from Dan Sebald --- What is the general thought regarding floating point numerical issues and the OpenGL formulas? The reason the swrast-legacy driver is failing one the Piglit pixelzoom tests is that this computation: c1 = imageX + (GLint) ceil((spanX + spanWidth - imageX) * ctx->Pixel.ZoomX); has numerical issues when ctx->Pixel.ZoomX is fractional and negative. (Sign isn't at the heart of the issue, the fact it is fractional is, i.e., -1 < ctx->Pixel.ZoomX < 0.) A few example numbers work out as follows (this is part of the succession of smaller filled rectangles test): span.x=160 span.end=400 (c0=-0.00 c1=-119.08)=>(-0.00,-119.00) span.x=160 span.end=400 (c0=-0.00 c1=-117.92)=>(-0.00,-117.00) span.x=160 span.end=400 (c0=-0.00 c1=-116.92)=>(-0.00,-116.00) span.x=160 span.end=400 (c0=-0.00 c1=-116.00)=>(-0.00,-116.00) Note how there are two end columns that are shorter than they should be, and the scaling here isn't very drastic, 1/2.5. Is there anything about the OpenGL standard that allows for, say, a band of numerical tolerance for ceil and floor operations? Or is it supposed to be that formulas consider GLfloat xfactor and yfactor as though they are real numbers, i.e., need exactness? I can make all the swrast tests pass if I put some tolerance in for the ceiling function. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114591|0 |1 is obsolete|| --- Comment #35 from Dan Sebald --- Created attachment 114619 --> https://bugs.freedesktop.org/attachment.cgi?id=114619&action=edit Piglit pixelzoom test suite Attached is an update to the piglit glPixelZoom()/glDrawPixels() tests. I've added a red background before the tests are run so that it's obvious when the driver hasn't written to the frame buffer. I also fixed a bug in the over/underrun tests. I won't update the summary of images right now. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114594|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114595|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114592|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114593|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #34 from Dan Sebald --- Created attachment 114599 --> https://bugs.freedesktop.org/attachment.cgi?id=114599&action=edit swrast Gallium with patch Piglit test images SWRAST_DRI.SO GALLIUM PATCH By making that simple change in src/mesa/state_tracker/st_cb_drawpixels.c that allows the driver to proceed if the input image size is greater than GL_MAX_TEXTURE_SIZE, I've found that the Gallium driver will complete the monotonic image grandients and generally looks good except for the last pixel (line) missing for both positive X and Y tests. Again, this is just an initial investigation, so we aren't sure yet whether there is a shortcoming in the test algorithm, or whether the Gallium driver might not be meeting the OpenGL standard for glDrawPixels exactly, e.g., a boundary condition isn't being satisfy such as pixel centers on the left or bottom box boundary are considered in the box. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #33 from Dan Sebald --- Created attachment 114598 --> https://bugs.freedesktop.org/attachment.cgi?id=114598&action=edit swrast Gallium Piglit test images SWRAST_DRI.SO GALLIUM The test images illustrate how the Gallium/LLVM driver is not displaying anything beyond the GL_MAX_TEXTURE_SIZE boundary of the input image. For all four monotonicity tests, only the darker portion of the gradient appears and from there it is the last draw/render that remains in the frame buffer. E.g., the Positive Monotonicity Y image still has the vertical alternating lines from the Negative Over/Underrun X test. It's no wonder all the monotonicity and edge tests fail. But the good news is that for input images with sizes less than GL_MAX_TEXTURE_SIZE, the Gallium driver is accurate for scaling. That's very nice. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #32 from Dan Sebald --- Created attachment 114597 --> https://bugs.freedesktop.org/attachment.cgi?id=114597&action=edit swrast legacy with patch Piglit test images SWRAST_DRI.SO LEGACY PATCH With the Mesa changeset I attached to this bug report, the legacy driver now produces good results as far as the monotonicity tests. The vertical lines due to the GL_MAX_TEXTURE_SIZE boundary are gone in the X direction, and the positive Y-gradient image no longer has a missing last pixel (line). So that is making progress. However, it's clear that the changeset has solved the issue with glDrawPixels not scaling precisely, and I still don't see why the positive X/Y over/underrun tests are failing--the associated images look correct. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #31 from Dan Sebald --- Created attachment 114596 --> https://bugs.freedesktop.org/attachment.cgi?id=114596&action=edit swrast legacy Piglit test images SWRAST_DRI.SO LEGACY This is the current repository version of the legacy swrast driver. The first image (upper left corner) shows the original problem I and others had experienced: vertical lines due to dropped pixels associated with GL_MAX_TEXTURE_SIZE transition. Interestingly, this doesn't happen when xfactor is negative (one of the "pass" tests). The Y-direction exhibits a good gradient ramp, except for the very last pixel in the positive direction, which is missing (look for the dark line near the top of the window), so this test fails for reasons different than in the X direction. The positive over/underrun with magnification X test actually looks good, and I don't know why the test is failing. These things can be looked at in greater detail later. The other three over/underrun tests in the X direction clearly show that glDrawPixels isn't zooming to the right scale. This is the other potential bug I've wondered about. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #30 from Dan Sebald --- Created attachment 114595 --> https://bugs.freedesktop.org/attachment.cgi?id=114595&action=edit swrast Gallium with patch Piglit test images SWRAST_DRI.SO GALLIUM PATCH By making that simple change in src/mesa/state_tracker/st_cb_drawpixels.c that allows the driver to proceed if the input image size is greater than GL_MAX_TEXTURE_SIZE, I've found that the Gallium driver will complete the monotonic image grandients and generally looks good except for the last pixel (line) missing for both positive X and Y tests. Again, this is just an initial investigation, so we aren't sure yet whether there is a shortcoming in the test algorithm, or whether the Gallium driver might not be meeting the OpenGL standard for glDrawPixels() exactly, e.g., a boundary condition isn't being satisfied such as pixel centers on the left or bottom box boundary are considered in the box. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #29 from Dan Sebald --- Created attachment 114594 --> https://bugs.freedesktop.org/attachment.cgi?id=114594&action=edit swrast Gallium Piglit test images SWRAST_DRI.SO GALLIUM The test images illustrate how the Gallium/LLVM driver is not displaying anything beyond the GL_MAX_TEXTURE_SIZE boundary of the input image. For all four monotonicity tests, only the darker portion of the gradient appears and from there it is the last draw/render that remains in the frame buffer. E.g., the Positive Monotonicity Y image still has the vertical alternating lines from the Negative Over/Underrun X test. It's no wonder all the monotonicity and edge tests fail. But the good news is that for input images with sizes less than GL_MAX_TEXTURE_SIZE, the Gallium driver is accurate for scaling. That's very nice. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #28 from Dan Sebald --- Created attachment 114593 --> https://bugs.freedesktop.org/attachment.cgi?id=114593&action=edit swrast legacy with patch Piglit test images SWRAST_DRI.SO LEGACY PATCH With the Mesa changeset I attached to this bug report, the legacy driver now produces good results as far as the monotonicity tests. The vertical lines due to the GL_MAX_TEXTURE_SIZE boundary are gone in the X direction, and the positive Y-gradient image no longer has a missing last pixel (line). So that is making progress. However, it's clear that the changeset has solved the issue with glDrawPixels not scaling precisely, and I still don't see why the positive X/Y over/underrun tests are failing--the associated images look correct. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #27 from Dan Sebald --- Created attachment 114592 --> https://bugs.freedesktop.org/attachment.cgi?id=114592&action=edit swrast legacy Piglit test images SWRAST_DRI.SO LEGACY This is the current repository version of the legacy swrast driver. The first image (upper left corner) shows the original problem I and others had experienced: vertical lines due to dropped pixels associated with GL_MAX_TEXTURE_SIZE transition. Interestingly, this doesn't happen when xfactor is negative (one of the "pass" tests). The Y-direction exhibits a good gradient ramp, except for the very last pixel in the positive direction, which is missing (look for the dark line near the top of the window), so this test fails for reasons different than in the X direction. The positive over/underrun with magnification X test actually looks good, and I don't know why the test is failing. These things can be looked at in greater detail later. The other three over/underrun tests in the X direction clearly show that glDrawPixels isn't zooming to the right scale. This is the other potential bug I've wondered about. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #26 from Dan Sebald --- Created attachment 114591 --> https://bugs.freedesktop.org/attachment.cgi?id=114591&action=edit Piglit pixelzoom test suite See https://bugs.freedesktop.org/show_bug.cgi?id=89586#c25 for a description of this changeset. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #25 from Dan Sebald --- I will attach an initial attempt at a Piglit test suite for glPixelZoom() in combination with glDrawPixels(). I tried (but failed) to set something up in which if a test fails the associated image is displayed for a couple seconds, but there is no good way in the framework of creating a delay. As with modern design for program flow, there shouldn't be any type of linear pause. Given that, it would take a bit to make registered callback functions work to recursively called tests because of the way the piglit_display is defined. Changing that is too much work/modification for this new test. Not even sure that is worth doing because big delays in rendering are usually a nuisance. The thing to do would be making each test a separate rendering, but that could be a lot of C files. In any case, if there is a failure, one has to manually pre-compile out most of the code, i.e., #if 0 .. #endif to make the failed test the last image displayed. For now, I've done that and assembled the images in PNG files for convenience. Originally I had put the test in tests/general/zoom-pixels.c to complement tests/general/draw-pixels.c, then moved it to where I.M. suggested, tests/spec/gl-1.0/pixelzoom.c. I've created several tests, and I attempted to make them specific yet not too specific (such as matching exact expected values) as to not cause any false negatives due to numerical effects. The tests are: 1) Monotonicity: With an input image in which one dimension is 2.5 times GL_MAX_TEXTURE_SIZE there is a ramp function for the RGB components of RGBA. Hence the output image should be a ramp. If it isn't, then that is a failure. This will catch the type of problem I originally ran across in which vertical lines are appearing in the image due to dropped pixels. This test is done for both x and y dimensions and for both positive and negative scaling factors. 2) Exact value at the edge: Using the OpenGL formulas, I derived the needed scaling factors to make the last pixel of the input image correspond to the last pixel of the output image. With that same ramp image from the previous test, the last pixel of the ramp is 1.0, so the last pixel of the output should be 1.0. Formulas are slightly different for positive and negative scaling. We can discuss whether this test is accurate. (More later.) 3) Scaling over or underrun: One thing I want to test is what I'm calling "overrun" or "underrun", which means that the output image falls one pixel too long or one pixel too short of its expected size. This effect can often be seen when resizing the output image (e.g., using the mouse to resize a window via a corner). That is, for some non-whole number numerator/divisor scalings, it might be that the pixel zoom indeces aren't working out right because of some inexact formula (e.g., the problems I saw in the original problem for swrast-legacy). What this test does is draw successive rectangles using an input image all of the same intensity but decrementing the zoom width or height and alternating the input image intensity. The residue left for each iteration is a single line, so when the process nears the end, the result is a framebuffer image of alternating lines. If that isn't correct, then for some zoom factor along the way there was a mistake. This is done for both directions, both postive and negative scaling factors and both magnification and condensation... I've had to put a small tolerance in the test for pixel values in the over/underrun tests. Does it work that the driver sets the value as close to, say, 0.25 as possible, and then returns what the actual value is? E.g., say the driver is 7 bits, so the resolution is 1/2^7. (Incidently, every driver returns an exact value for 1.0?) OK, please give this test suite a try and let me know what you think. I'm sure adjustments need to be made, and we can discuss the validity of the tests with regard to the OpenGL standard formulas, and refine them if warranted. Here is a summary of the results I'm currently seeing and a few comments. I've made screen captures and assembled the results into collective bitmaps so there aren't so many individual files. The four different drivers are as follows: (1) swrast-legacy: The repository legacy swrast_dri.so driver for which my system and others is using and exibits vertical lines. (2) swrast-legacy-patch: The legacy swrast_dri.co patched with the changeset I originally attached to this bug report. (3) swrast-gallium: The repository Gallium/llvm swrast_dri.so driver. (4) swrast-gallium-patch: The Gallium swrast_dri.co patched by removing the line of code that limits the size of the image. TEST (1) (2) (3) (4) positive monotonic x fail pass fail fail positive edge xfail pass fail fail positive over/underrun x fail fail pass pass negative monotonic x pass
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #24 from Dan Sebald ---
Yes, Gallium version works:
[sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
bin/ext_polygon_offset_clamp-draw
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau
PIGLIT: {"subtest": {"negative clamp" : "pass"}}
PIGLIT: {"subtest": {"positive clamp" : "pass"}}
I see a green rectangle in the display. Thanks.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #23 from Ilia Mirkin ---
(In reply to Dan Sebald from comment #22)
> glxinfo indicates GLX Version 1.4.
Not really relevant... I was looking for the version of X to determine the
general age of the system, as well as what libglx shipped with it.
>
> I did find some tests that work without the GLX_ARB_create_context error.
> There seems to be no correlation with 1.0, 2.0, etc. For example, this one
> works:
>
> [sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
> bin/gl-2.1-pbo
> libGL error: unable to load driver: nouveau_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: nouveau
> PIGLIT: {"subtest": {"test_sanity" : "pass"}}
> PIGLIT: {"subtest": {"test_draw_pixels" : "pass"}}
> PIGLIT: {"subtest": {"test_pixel_map" : "pass"}}
> PIGLIT: {"subtest": {"test_bitmap" : "pass"}}
> PIGLIT: {"subtest": {"test_tex_image" : "pass"}}
> PIGLIT: {"subtest": {"test_tex_sub_image" : "pass"}}
> PIGLIT: {"subtest": {"test_polygon_stip" : "pass"}}
> PIGLIT: {"subtest": {"test_error_handling" : "pass"}}
>
> while most others don't. The only thing that stands out is that in the C
> files for this test is a main() definition and in that definition there
> appears to be GLUT creating the context.
Probably, yeah. piglit is old. The nice thing about waffle is that it works on
all platforms. Except, apparently, really old ones that don't have
GLX_ARB_create_context.
> The example
> ext_polygon_offset_clamp-draw has no main so I assume that is worked out via
> #include "piglit-util-gl.h" and Waffles.
>
> But you'd want me to write a glPixelZoom test with the Waffles framework, so
> I've made the change you suggested to glx_config.c and the program proceeds,
> but for some reason this particular test is failing:
>
> [sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
> bin/ext_polygon_offset_clamp-draw
> libGL error: unable to load driver: nouveau_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: nouveau
> Test requires GL_EXT_polygon_offset_clamp
> PIGLIT: {"result": "skip" }
>
> However, I believe GL_EXT_polygon_offset_clamp is in the library:
>
> [sebald@ waffle]$ grep GL_EXT_polygon_offset_clamp ~/local/lib/dri/*
> Binary file /home/sebald/local/lib/dri/kms_swrast_dri.so matches
> Binary file /home/sebald/local/lib/dri/r200_dri.so matches
> Binary file /home/sebald/local/lib/dri/radeon_dri.so matches
> Binary file /home/sebald/local/lib/dri/swrast_dri.so matches
>
> Eh, at this point it's too much hacking to try and resolve anything. I'll
> just put together some kind of test that is in the Waffle framework as best
> as possible and still compiles on my system, then let you or someone else
> refine the build aspects of it.
As I had mentioned earlier, swrast doesn't support the extension. You'll note
that glxinfo won't list it under OpenGL extensions. llvmpipe should support it
though. (As do all DX10-level GPUs supported by mesa.)
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #22 from Dan Sebald ---
glxinfo indicates GLX Version 1.4.
I did find some tests that work without the GLX_ARB_create_context error.
There seems to be no correlation with 1.0, 2.0, etc. For example, this one
works:
[sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
bin/gl-2.1-pbo
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau
PIGLIT: {"subtest": {"test_sanity" : "pass"}}
PIGLIT: {"subtest": {"test_draw_pixels" : "pass"}}
PIGLIT: {"subtest": {"test_pixel_map" : "pass"}}
PIGLIT: {"subtest": {"test_bitmap" : "pass"}}
PIGLIT: {"subtest": {"test_tex_image" : "pass"}}
PIGLIT: {"subtest": {"test_tex_sub_image" : "pass"}}
PIGLIT: {"subtest": {"test_polygon_stip" : "pass"}}
PIGLIT: {"subtest": {"test_error_handling" : "pass"}}
while most others don't. The only thing that stands out is that in the C files
for this test is a main() definition and in that definition there appears to be
GLUT creating the context. The example ext_polygon_offset_clamp-draw has no
main so I assume that is worked out via #include "piglit-util-gl.h" and
Waffles.
But you'd want me to write a glPixelZoom test with the Waffles framework, so
I've made the change you suggested to glx_config.c and the program proceeds,
but for some reason this particular test is failing:
[sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
bin/ext_polygon_offset_clamp-draw
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau
Test requires GL_EXT_polygon_offset_clamp
PIGLIT: {"result": "skip" }
However, I believe GL_EXT_polygon_offset_clamp is in the library:
[sebald@ waffle]$ grep GL_EXT_polygon_offset_clamp ~/local/lib/dri/*
Binary file /home/sebald/local/lib/dri/kms_swrast_dri.so matches
Binary file /home/sebald/local/lib/dri/r200_dri.so matches
Binary file /home/sebald/local/lib/dri/radeon_dri.so matches
Binary file /home/sebald/local/lib/dri/swrast_dri.so matches
Eh, at this point it's too much hacking to try and resolve anything. I'll just
put together some kind of test that is in the Waffle framework as best as
possible and still compiles on my system, then let you or someone else refine
the build aspects of it.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #21 from Ilia Mirkin --- (In reply to Dan Sebald from comment #19) > I've tried variations on the include and library directories but not much > luck. Remade Waffles in /usr/local/lib64. I did get the local version of [...] > WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required in > order to request an OpenGL version not equal to the default value 1.0 Or alternatively just pick a different test. Like bin/gl-1.0-. Those should request a 1.0 context and waffle should be perfectly happy. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #20 from Ilia Mirkin ---
(In reply to Dan Sebald from comment #19)
> I've tried variations on the include and library directories but not much
> luck. Remade Waffles in /usr/local/lib64. I did get the local version of
> Mesa library in the test programs:
>
> [sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
> bin/ext_polygon_offset_clamp-draw
> libGL error: unable to load driver: nouveau_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: nouveau
> piglit: error: waffle_config_choose failed due to
> WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required in
> order to request an OpenGL version not equal to the default value 1.0
> piglit: error: Failed to create waffle_config for OpenGL 2.1 Compatibility
> Context
> piglit: info: Failed to create any GL context
> PIGLIT: {"result": "skip" }
>
> as evidenced by the attempt to load nouveau_dri.so. However, I think maybe
> my X11 is too old for Waffles. I've not upgraded since the demise of Gnome
> 2 series. FWIW, I looked at glxinfo and see no GLX_ARB_create_context in
> any of the library lists.
FYI, MATE is carrying on the Gnome2 banner (http://mate-desktop.org/). What
version of X are you using? Do you have glx loaded? (In _very_ old versions of
X, you had to explicitly say 'Load "glx"' in the config.)
Just edit the waffle code to remove that stupid check, it's likely BS:
https://github.com/waffle-gl/waffle/blob/master/src/waffle/glx/glx_config.c#L73
if (!wcore_config_attrs_version_eq(attrs, 10) &&
!dpy->ARB_create_context) {
Make that say like
if (wcore_config_attrs_version_ge(attrs, 30) && !dpy->ARB_create_context)
If anything else fails in that function, just remove that check... it should
work out.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #19 from Dan Sebald ---
I've tried variations on the include and library directories but not much luck.
Remade Waffles in /usr/local/lib64. I did get the local version of Mesa
library in the test programs:
[sebald@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64
bin/ext_polygon_offset_clamp-draw
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: nouveau
piglit: error: waffle_config_choose failed due to
WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required in
order to request an OpenGL version not equal to the default value 1.0
piglit: error: Failed to create waffle_config for OpenGL 2.1 Compatibility
Context
piglit: info: Failed to create any GL context
PIGLIT: {"result": "skip" }
as evidenced by the attempt to load nouveau_dri.so. However, I think maybe my
X11 is too old for Waffles. I've not upgraded since the demise of Gnome 2
series. FWIW, I looked at glxinfo and see no GLX_ARB_create_context in any of
the library lists.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #18 from Dan Sebald --- Oh, that's right. Somehow I have to build or run the piglit tests using the local build of Mesa (which is repository-up-to-date), i.e., what is accomplished with PKG_CONFIG_PATH=/home/sebald/local/pkgconfig ./configure otherwise. (I've left the distro version of Mesa intact for fear changing that will have a major consequence on apps on my system.) I'm trying to get the local library recognized, no luck but I'll keep trying... " Too late now, but you were looking for PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:/usr/lib/pkgconfig" " I thought that /usr/local is a directory that is automatically searched. In any case, maybe I could use that to get the library recognized. But it is cmake... oh, PKG_CONFIG_PATH= appears to work with ccmake . as well. Ah, now that compiles quickly. The first time around building piglit was showing all kinds of green and red comments. However, I'm getting the same error. I don't think the local version of libGL.so is being used still. There is no package definition in ~/local/lib/pkgconfig for libGL. I think I have enough to keep me going here. Thanks. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #17 from Ilia Mirkin ---
(In reply to Ian Romanick from comment #16)
> (In reply to Ilia Mirkin from comment #15)
> > (In reply to Dan Sebald from comment #13)
> > > OK, thanks. I'll just run the executable binaries then:
> > >
> > > [sebald@ piglit]$ bin/ext_polygon_offset_clamp-draw
> > > piglit: error: waffle_config_choose failed due to
> > > WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required
> > > in
> > > order to request an OpenGL version not equal to the default value 1.0
> > > piglit: error: Failed to create waffle_config for OpenGL 2.1 Compatibility
> > > Context
> > > piglit: info: Failed to create any GL context
> > > PIGLIT: {"result": "skip" }
> > >
> > > I'll look into this problem later today. I suppose I missed a build
> > > switch
> > > somewhere along the way.
> >
> > As the error says, you appear to be missing GLX_ARB_create_context, and that
> > particular test requires GL 2.1... are you running this on X? Can you
>
> GLX_ARB_create_context should not be necessary for an OpenGL 2.1 context...
> since OpenGL 2.1 predates that extension by many years. If that test asks
> for something less than 3.0, Waffle should create the context then check the
> version.
Yeah that's what would make sense to me too, but I'm just reading the error
output here :)
https://github.com/waffle-gl/waffle/blob/master/src/waffle/glx/glx_config.c#L72
Seems like the context creation logic should handle it just fine:
https://github.com/waffle-gl/waffle/blob/master/src/waffle/glx/glx_context.c#L164
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #16 from Ian Romanick ---
(In reply to Ilia Mirkin from comment #15)
> (In reply to Dan Sebald from comment #13)
> > OK, thanks. I'll just run the executable binaries then:
> >
> > [sebald@ piglit]$ bin/ext_polygon_offset_clamp-draw
> > piglit: error: waffle_config_choose failed due to
> > WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required in
> > order to request an OpenGL version not equal to the default value 1.0
> > piglit: error: Failed to create waffle_config for OpenGL 2.1 Compatibility
> > Context
> > piglit: info: Failed to create any GL context
> > PIGLIT: {"result": "skip" }
> >
> > I'll look into this problem later today. I suppose I missed a build switch
> > somewhere along the way.
>
> As the error says, you appear to be missing GLX_ARB_create_context, and that
> particular test requires GL 2.1... are you running this on X? Can you
GLX_ARB_create_context should not be necessary for an OpenGL 2.1 context...
since OpenGL 2.1 predates that extension by many years. If that test asks for
something less than 3.0, Waffle should create the context then check the
version.
> provide the output of 'glxinfo' with any LD_LIBRARY_PATH's that you use to
> run the tests? [Also, the classic swrast doesn't have support for that
> extension, so you won't get too far if that's what you're testing... either
> softpipe or llvmpipe should have it though. Or pick a different test.]
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #15 from Ilia Mirkin ---
(In reply to Dan Sebald from comment #13)
> OK, thanks. I'll just run the executable binaries then:
>
> [sebald@ piglit]$ bin/ext_polygon_offset_clamp-draw
> piglit: error: waffle_config_choose failed due to
> WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required in
> order to request an OpenGL version not equal to the default value 1.0
> piglit: error: Failed to create waffle_config for OpenGL 2.1 Compatibility
> Context
> piglit: info: Failed to create any GL context
> PIGLIT: {"result": "skip" }
>
> I'll look into this problem later today. I suppose I missed a build switch
> somewhere along the way.
As the error says, you appear to be missing GLX_ARB_create_context, and that
particular test requires GL 2.1... are you running this on X? Can you provide
the output of 'glxinfo' with any LD_LIBRARY_PATH's that you use to run the
tests? [Also, the classic swrast doesn't have support for that extension, so
you won't get too far if that's what you're testing... either softpipe or
llvmpipe should have it though. Or pick a different test.]
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #14 from Ilia Mirkin --- (In reply to Dan Sebald from comment #11) > "it's all a bit annoying as it uses cmake" > > Yes, as bit, but eventually was able to make everything. The one > significant issue was making Waffles in /usr/local couldn't be found by > Piglit ccmake. Because cmake has no uninstall, I manually deleted all the > files Waffles installed and then used the prefix "/usr" to make Waffles. > Piglit could then find Waffles. Too late now, but you were looking for PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:/usr/lib/pkgconfig" > > Anyway, writing the C program shouldn't be difficult, but I can't seem to > get the basics working correctly. When I built Piglit all seemed OK, at > least there was about 8 minutes to the build process as it methodically Time to upgrade your CPU, or use "make -j8" :) > stepped through directories building things. However, nothing I supply to > ./piglit seems to be accepted: > > [sebald@ piglit]$ ./piglit run As Ian said, don't worry about that. Just run 'bin/gl-1.0-pixelzoom -fbo -auto', or omit the -fbo -auto if you want it to see why it's not doing the thing you wanted it to do. For reference, this is how I do full piglit runs on nouveau: http://people.freedesktop.org/~imirkin/ -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #13 from Dan Sebald ---
OK, thanks. I'll just run the executable binaries then:
[sebald@ piglit]$ bin/ext_polygon_offset_clamp-draw
piglit: error: waffle_config_choose failed due to
WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM: GLX_ARB_create_context is required in
order to request an OpenGL version not equal to the default value 1.0
piglit: error: Failed to create waffle_config for OpenGL 2.1 Compatibility
Context
piglit: info: Failed to create any GL context
PIGLIT: {"result": "skip" }
I'll look into this problem later today. I suppose I missed a build switch
somewhere along the way.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #12 from Ian Romanick --- (In reply to Dan Sebald from comment #11) > "it's all a bit annoying as it uses cmake" > > Yes, as bit, but eventually was able to make everything. The one > significant issue was making Waffles in /usr/local couldn't be found by > Piglit ccmake. Because cmake has no uninstall, I manually deleted all the > files Waffles installed and then used the prefix "/usr" to make Waffles. > Piglit could then find Waffles. > > Anyway, writing the C program shouldn't be difficult, but I can't seem to > get the basics working correctly. When I built Piglit all seemed OK, at > least there was about 8 minutes to the build process as it methodically > stepped through directories building things. However, nothing I supply to > ./piglit seems to be accepted: The individual programs are just in the bin/ directory, so you can run your test directly from there. To run it from the piglit command, you'll have to add your test to tests/all.py. './piglit run tests/quick.py results/' should work. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #11 from Dan Sebald ---
"it's all a bit annoying as it uses cmake"
Yes, as bit, but eventually was able to make everything. The one significant
issue was making Waffles in /usr/local couldn't be found by Piglit ccmake.
Because cmake has no uninstall, I manually deleted all the files Waffles
installed and then used the prefix "/usr" to make Waffles. Piglit could then
find Waffles.
Anyway, writing the C program shouldn't be difficult, but I can't seem to get
the basics working correctly. When I built Piglit all seemed OK, at least
there was about 8 minutes to the build process as it methodically stepped
through directories building things. However, nothing I supply to ./piglit
seems to be accepted:
[sebald@ piglit]$ ./piglit run
usage: piglit [-h] [-n ] [-d] [-t ] [-x ]
[-b {json,junit}] [-c | -1]
[-p {glx,x11_egl,wayland,gbm,mixed_glx_egl}] [--valgrind]
[--dmesg] [-s] [--junit_suffix JUNIT_SUFFIX] [-f config_file]
[-v | -l {quiet,verbose,dummy}] [--test-list TEST_LIST]
[ ...]
piglit: error: too few arguments
[sebald@ piglit]$ ./piglit run -h
usage: piglit run
piglit run: error: unrecognized arguments: -h
[sebald@ piglit]$ ./piglit run sanity results/sanity
usage: piglit run
piglit run: error: unrecognized arguments: sanity results/sanity
[sebald@ piglit]$ ./piglit run tests/sanity.py results/sanity
usage: piglit run
piglit run: error: unrecognized arguments: tests/sanity.py results/sanity
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #10 from Dan Sebald --- OK, src/mesa/state_tracker/st_cb_drawpixels.c is it, thanks. Saved me a lot of time. And here's a comment about image size in the code: /* Limit the size of the glDrawPixels to the max texture size. * Strictly speaking, that's not correct but since we don't handle * larger images yet, this is better than crashing. */ I simply removed the limit and the image displays fine with no segfaults. There is a tiny discrepancy compared with the swrast/ result, however. There may still be a bug floating about. I will explain in a different bug report. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #9 from Ilia Mirkin --- (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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #8 from Dan Sebald --- 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. 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. 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. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #7 from Ilia Mirkin --- Would you be able to supply a short program that reproduces the issue that could be added to the piglit test suite? (http://cgit.freedesktop.org/piglit) There are two tests in there that make use of glPixelZoom, but very far from a thorough test. Also, you're using swrast, which has seen very little activity of late -- do these issues happen with the more up-to-date and commonly used gallium-based softpipe or llvmpipe drivers? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added CC||daniel.seb...@ieee.org -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #6 from Dan Sebald --- One last comment about the efficiency of the pixel zooming. This routine seems slow when I rescale the image; it's tolerable, but could be faster. There is a setup of the memory addresses and context for every row of the image written to the frame buffer. malloc() is used every row as well. I think things could be simplified if in s_drawpix.c a single big memory buffer is first created and these routines that "write" spans could be changed to simply "fill" the big memory buffer. That would avoid the setting up of the frame buffer memory for each row. Instead, it would just be an extra tight loop inside SPAN_LOOP_X() that copies r1-r0-1 rows. Then after the big buffer is filled with the image (pretty much the same loop as is currently done for writing), then use the fast image write routine. That would then be just one malloc(), filled buffer piecewise, write to frame buffer, free(). To get an accurate pixel size for the zoomed image, put the declaration static GLboolean compute_zoomed_bounds(struct gl_context *ctx, GLint imageX, GLint imageY, GLint spanX, GLint spanY, GLint spanWidth, GLint *x0, GLint *x1, GLint *y0, GLint *y1) in s_zoom.h. With the changes made in the attached changeset, that routine should be very accurate with something like compute_zoomed_bounds(ctx, imageX, imageY, 0, 0, imageX, &x0, &x1, &y0, &y1); -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #5 from Dan Sebald --- Created attachment 114342 --> https://bugs.freedesktop.org/attachment.cgi?id=114342&action=edit Changeset to fix vertical lines and fine tune positive_unzoom_x() and negative_unzoom_x() -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
--- Comment #4 from Dan Sebald ---
I'm now going to attach the full patch which fixes what I believe is another
subtle bug and attempts to make things slightly more efficient in the innermost
loop.
I notice in the following hunk of code from s_zoom.c:
static inline GLint
unzoom_x(GLfloat zoomX, GLint imageX, GLint zx)
{
/*
zx = imageX + (x - imageX) * zoomX;
zx - imageX = (x - imageX) * zoomX;
(zx - imageX) / zoomX = x - imageX;
*/
GLint x;
if (zoomX < 0.0)
zx++;
x = imageX + (GLint) ((zx - imageX) / zoomX);
return x;
}
there is a test for zoomX < 0.0. That zoomX test is run for every unzoomed
computation, which can be a lot of tests if the image displayed is large. (I
will say more about efficiency later.) That is, in the calling routine:
for (i = 0; i < zoomedWidth; i++) {
GLint j = unzoom_x(ctx->Pixel.ZoomX, imgX, x0 + i) - span->x;
assert(j >= 0);
assert(j < (GLint) span->end);
COPY_4V(zoomed.array->attribs[VARYING_SLOT_COL0][i], rgba[j]);
}
that value of ctx->Pixel.ZoomX is a constant. So, really, the zoom sign test
could be brought outside the for-loop, and perhaps increase efficiency by, oh,
maybe 25%. (For the loop, but there is inefficiency elsewhere of course so may
not be noticeable. However, I'm one who tends to aim for efficiency.) That
is, this "if (zoomX < 0.0)" is probably one or two machine instructions, while
"x = imageX + (GLint) ((zx - imageX) / zoomX);" is probably about five machine
instructions.
In the full patch I have replaced the unzoom_x() with a positive_unzoom_x() and
negative_unzoom_x(). As you might imagine, the changeset then first tests the
polarity of zoomX the picks a loop to run, depending on the sign of zoomX.
This is done in a clean and graceful way using a macro called SPAN_LOOP_X()
where the argument is one or two lines of code that is run inside the loop,
i.e., the memory copy.
Now, having done the positive/negative_unzoom_x() construct, I also wrote some
more extensive formula derivations in comments in the code to show what I think
is a discrepancy with the formula of unzoom_x() above, in particular at least
this
if (zoomX < 0.0)
zx++;
By my derivation, the addition (effectively subtraction) should be done after
the division operation. Doing the addition before dividing is something
different that really doesn't have the same effect. Also, notice there is the
subtle case of ((xz - xr) / xfactor) being an integer that isn't properly
addressed. It takes some time to think through, and if you don't agree with my
derivation/code, point out what is wrong and we can refine things.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #3 from Dan Sebald --- Created attachment 114341 --> https://bugs.freedesktop.org/attachment.cgi?id=114341&action=edit Example gradient image resulting after changeset applied. Vertical lines gone. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 Dan Sebald changed: What|Removed |Added Attachment #114338|text/plain |image/png mime type|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #2 from Dan Sebald --- Created attachment 114340 --> https://bugs.freedesktop.org/attachment.cgi?id=114340&action=edit Illustration of why ceil() is the correct operation to apply to zoom box -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586 --- Comment #1 from Dan Sebald --- Created attachment 114339 --> https://bugs.freedesktop.org/attachment.cgi?id=114339&action=edit Minimal changeset to fix vertical lines when -1 < xfactor < 1 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89586] Drivers/DRI/swrast
https://bugs.freedesktop.org/show_bug.cgi?id=89586
Bug ID: 89586
Summary: Drivers/DRI/swrast
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Other
Assignee: mesa-dev@lists.freedesktop.org
Reporter: daniel.seb...@ieee.org
QA Contact: mesa-dev@lists.freedesktop.org
Created attachment 114338
--> https://bugs.freedesktop.org/attachment.cgi?id=114338&action=edit
Example image with droped pixels during zoom, creating vertical lines in image
When plotting large images (images that typically span in the x-direction
greater than GL_MAX_TEXTURE_SIZE) with an application using Mesa/OpenGL,
several developers with quite varying versions of Mesa were seeing vertical
white lines spaced at GL_MAX_TEXTURE_SIZE. I assume that Mesa is displaying
images in hunks of GL_MAX_TEXTURE_SIZE x GL_MAX_TEXTURE_SIZE or less, and it
seems that--at least in the X-dimension--that either the first pixel or the
last pixel is being dropped.
I've attached an example gradient image run through a palette called
Screenshot-Mesa-VerticalLines.png. The various colors should make the vertical
lines easily visible. This sample image has an input buffer which is 40,000
pixels wide, enough to span a couple GL_MAX_TEXTURE_SIZE (16384) pixels. This
image as a pixel scaling factor which is quite small, approximately 1/100. But
that doesn't seem unreasonably small, meaning it's not in the realm where it
should coincide with numerical issues.
After getting to know the Mesa code a bit and compiling from scratch locally
using PKG_CONFIG_PATH, I eventually tracked down the problem to this hunk of
code (which appears at several different locations in the code, based upon the
type of data being worked on) in the file s_zoom.c:
for (i = 0; i < zoomedWidth; i++) {
GLint j = unzoom_x(ctx->Pixel.ZoomX, imgX, x0 + i) - span->x;
assert(j >= 0);
assert(j < (GLint) span->end);
COPY_4V(zoomed.array->attribs[VARYING_SLOT_COL0][i], rgba[j]);
}
When printing out these variable values on the fly when j happens to be less
than zero (one of the assert conditions) when x0+i = x0 (i.e., i=0, or the
"first" pixel in the zoomed image block). For example,
j=-71, imgX=73, x0=250, i=0, zoom=0.010850
j=-50, imgX=73, x0=428, i=0, zoom=0.010850
But it strikes me that the j < 0 or j > span->end cases cannot be ignored,
i.e., tossed out via the assert(), because these correspond to an i value of
the mapped output image which is visible. There has to be something there.
Basically, my thinking is that, approximately, -1/xfactor < j < 0 corresponds
to a valid pixel, it's just that the pixel crosses the memory chunk/block
boundary in the transformation (the code used the word "chunks", so I will use
chunk). That is, the pixel for j < 0 should come from the previous
GL_MAX_TEXTURE_SIZE/SWRAST_MAX_WIDTH chunk of data.
I'm going to attach two git changesets to address this issue, a minimal
changeset and a more thorough changeset. The first changeset will be something
just to make the current code work by adding a few lines and show where the
main bug is. The second changeset has a few extra changes, mostly
straightforward, but when taken as a whole they might seem confusing. I'll
attach the second changeset as a different post to help organization.
So I'll explain how I went about this and my thought process for making those
changes in the changeset. First, let's verify this formula is correct:
GLint j = unzoom_x(ctx->Pixel.ZoomX, imgX, x0 + i) - span->x;
I will refer to 'j' as the "chunk" unzoomed x. Elsewhere I'll use the OpenGL
nomenclature of 'n' as the pixel array unzoomed x. By the OpenGL definition
when x0 + i = imgX the value of j (and n, because it is the first block) should
be exactly zero. That condition is the scenario of looking at the first
unzoomed pixel. I will print out the value as follows:
GLint j = unzoom_x(ctx->Pixel.ZoomX, imgX, x0 + i) - span->x;
if (x0 + i == imgX)
fprintf(stderr, "x0+i = imgX: j=%d\n", j);
Here is the result:
x0+i = imgX: j=0
That's a good result, and it suggests that those values of j < 0 aren't some
bogus offset or some numerical problem.
Now, let's verify that j < 0 is a valid value, corresponding to a pixel by
testing whether it correctly fits the OpenGL standard for zooming a pixel array
listed here:
https://www.opengl.org/sdk/docs/man2/xhtml/glPixelZoom.xml
xr + n * xfactor <= xz < xr + (n+1) * xfactor (1)
yr + m * yfactor <= yz < yr + (m+1) * xfactor (2)
Rather than list the commands for printing, I'll just state what I'm printing
from this point forward. I will run the same app program and this time print
out the value of j when j < 0, the zoomed pixel value, and the formula shown in
the link above:
j=-71: spanX
