Summary: | r600: glPolygonStipple broken | ||
---|---|---|---|
Product: | Mesa | Reporter: | Rafael Monica <monraaf> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | gsr.bugs, hramrach, hysvats, MostAwesomedude, sa |
Version: | git | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Rafael Monica
2009-11-25 06:48:52 UTC
Also broken on r600g Pity-reassigning to r600g, as r600c is never going to get fixed. I don't see difference whit mesa-demos poly* between swrast and r600g. I see a difference with tri-stipple. smooth and stippled polygons/lines/etc. are not implemented in r600c/g or r300c/g at the moment as they require adding special code to the fragment shader to handle them. r300c at least can use software fallbacks (see driconf), which make app like Blender usable (polygon and line stipples are used to give feedback about item relations, object types, selection status, etc). Should not Gallium also use software fallbacks, at least as stop gap until shader method is coded? Specially if r[36]00c are going to be deprecated in the near future. Looks like r600g recently gained initial stipple support: 391e33ffbf01180d66d4c4e9a6c91fc17f9feaca It seems to be enough to make Blender happy at least. *** Bug 28049 has been marked as a duplicate of this bug. *** -- 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/390. |
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.