Bug 40920 - [openvg] defective pixels using mesa with openvg
Summary: [openvg] defective pixels using mesa with openvg
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-15 12:45 UTC by Andreas Betz
Modified: 2012-05-14 08:09 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Picture showing the defective pixels (12.65 KB, image/png)
2011-09-21 14:59 UTC, Andreas Betz
Details
A win32 studio project showing the defective pixels. (2.86 MB, application/octet-stream)
2011-09-21 15:09 UTC, Andreas Betz
Details
PART II of A win32 studio project showing the defective pixels. (2.48 MB, application/octet-stream)
2011-09-21 15:10 UTC, Andreas Betz
Details
mesademos patch w/ example (5.52 KB, patch)
2012-01-20 06:43 UTC, Jose Fonseca
Details | Splinter Review

Description Andreas Betz 2011-09-15 12:45:19 UTC
Hi,

every time im using a path e.g. describing a text or a complex thing - like a stick figure :) - i see strange defective pixels.

What i can tell you is that i have seen this phenomena on WindowsXP-32bit, Windows7-64bit, WindowsVista-64bit, Kubuntu and Debian.

Though mesa is - in my eyes - the best OpenVG emulation for Win32 the defective pixels and the missing antializing are the only two obstacles for "us"...

Thank you,
    Andy
Comment 1 Chia-I Wu 2011-09-20 21:11:06 UTC
Does it happen with all drivers (llvmpipe v.s. softpipe)?  Do you have a test case for this bug?
Comment 2 Andreas Betz 2011-09-21 00:29:40 UTC
Hi,

sry that i forgot to mention it ... im using the llvmpipe (because ... it is simply faster ...).

Using the soft-pipe it look good ... but it is very slow ... 
The point is  ... i have to use the llvm because we simulate animations with our software.

I will upload a simple example and pictures later today ... if it is ok.
Comment 3 Andreas Betz 2011-09-21 14:59:51 UTC
Created attachment 51472 [details]
Picture showing the defective pixels
Comment 4 Andreas Betz 2011-09-21 15:09:33 UTC
Created attachment 51473 [details]
A win32 studio project showing the defective pixels.

This file contains a win32 visual studio project including the mesa library i used to build this. It shows a path and some kind of dash animation.
NOTE: the bug does not only occur with dash ... i added this just for demonstration purpose ...


I had to split the archive into 2 ... :)
Comment 5 Andreas Betz 2011-09-21 15:10:38 UTC
Created attachment 51474 [details]
PART II of A win32 studio project showing the defective pixels.

This file contains a win32 visual studio project including the mesa library i used to build this. It shows a path and some kind of dash animation.
NOTE: the bug does not only occur with dash ... i added this just for demonstration purpose ...


I had to split the archive into 2 ... :)
Comment 6 Andreas Betz 2012-01-20 03:10:02 UTC
Hello,

i just checked it again with MESA trunk and still see those defects.

My setup is:
MESA src from trunk
LLVM 2.9

and i build it for Windows using scons with the following parameters:

scons platform=windows machine=x86 statetrackers=vega drivers=llvmpipe winsys=gdi build=release gles=no



As this only happens with the LLVM ... is there another configuration to build MESA for Win32 so that it is fast AND does not show these defects ?

Best Regards,
    Andy
Comment 7 Jose Fonseca 2012-01-20 06:00:34 UTC
From the picture this looks like a rasterization issue.

(In reply to comment #6)
> As this only happens with the LLVM ... is there another configuration to build
> MESA for Win32 so that it is fast AND does not show these defects ?

No. I think your best bet is trying to fix the defect in llvmpipe.

It would help to reproduce and debug if we could have a linux version of the sample you wrote.
Comment 8 Jose Fonseca 2012-01-20 06:43:24 UTC
Created attachment 55832 [details] [review]
mesademos patch w/ example

Linux port of the windows example.

Issue can be reproduced doing:

  EGL_LOG_LEVEL=info EGL_SOFTWARE=1 ./fdo40920_x11
Comment 9 Jose Fonseca 2012-05-14 08:09:05 UTC
This is now fixed with

commit 24678700edaf5bb9da9be93a1367f1a24cfaa471
Author: James Benton <jbenton@vmware.com>
Date:   Mon May 14 16:00:06 2012 +0100

    llvmpipe: Calculate fixed point coordinates for triangle setup earlier.
    
    This allows us to calculate the triangle's area using fixed point,
    previously it was cacluated in floating point space. It was possible
    that a triangle which had negative area in floating point space had
    a positive area in fixed point space.
    
    Fixes fdo 40920.
    
    Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>


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.