Bug 13759 - [i965 FBO GEM] render to 1D texture work incorrecly
Summary: [i965 FBO GEM] render to 1D texture work incorrecly
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
Depends on:
Reported: 2007-12-20 19:18 UTC by Shuang He
Modified: 2009-05-20 18:59 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

test case (6.08 KB, text/plain)
2007-12-20 19:22 UTC, Shuang He

Description Shuang He 2007-12-20 19:18:41 UTC
System Environment:
--Platform: FC6

Bug detailed description:
render to 1D texture seems not working correctly
Pls try the attached test case

Reproduce steps:
start X
compile and run the attached test case

Current result:
nothing was rendered to 1D texture

Expected result:
render to 1D texture should work correcly
Comment 1 Shuang He 2007-12-20 19:22:21 UTC
Created attachment 13263 [details]
test case

this test case attach a 1d texture image to FBO's COLOR_ATTACHMENT0
render to this 1d texture through FBO
then apply the the 1d texture
a small red 2x2 rectangle should be rendered.
Comment 2 Shuang He 2007-12-20 19:23:08 UTC
this issue doesn't happen on i915
Comment 3 Shuang He 2008-07-28 19:19:56 UTC
This issue still exists with latest GEM
Comment 4 Eric Anholt 2008-12-19 13:40:55 UTC
Not a release blocker.  Not a regression, and not likely to be commonly used.
Comment 5 Shuang He 2009-03-22 20:28:36 UTC
this issue still exists with:
Kernel_version:         2.6.29-rc7
Libdrm:         (master)2e2e8575b1ed4703653a72ac2b60b75316c388d7
Mesa:            (mesa_7_4_branch)a8528a2e8653b5237c1d1d66fe98c6e031d007f9
Xserver:         (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:      (2.7)238c2c40afd9f8b61479b8640d53f20d52fd7ddf
Kernel:       (for-airlied)dc529a4fe1ae4667c819437a94185e8581e1e680
Comment 6 Eric Anholt 2009-05-20 18:59:52 UTC
Nothing appears to be wrong with 1D FBOs.  The test is being overly picky about the line rasterization -- replace the GL_LINES with a GL_TRIANGLE_FAN covering those pixels, and it's fine.  Even with GL_LINES and increasing Y by some epsilon works.  And the spec says we're OK:

OpenGL 2.1 spec section 3.4:
The coordinates of a fragment produced by the algorithm may not deviate by
more than one unit in either x or y window coordinates from a corresponding
fragment produced by the diamond-exit rule.

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.