Summary: | radeon driver should support 3d texture maps without raster fallback | ||
---|---|---|---|
Product: | Mesa | Reporter: | Roland Scheidegger <sroland> |
Component: | Drivers/DRI/R100 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | high | CC: | a.stenglein, rtlm10 |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
patch for enabling 3d textures
new patch for enabling 3d textures |
Description
Roland Scheidegger
2005-10-18 11:20:31 UTC
Created attachment 3577 [details] [review] patch for enabling 3d textures patch to enable 3d textures. If it doesn't work, one reason could be that texcoord routing for unit 2 might need adjustments (e.g. the RADEON_TXFORMAT_ST_ROUTE_STQ bits), dunno. There could be other things wrong too :-). I've just added a page to the DRI wiki on the subject of handling mipmaps on hardware that doesn't do mipmapping: http://dri.freedesktop.org/wiki/HardwareWithoutMipmaps This patch does not work. I don't have time to investigate this right now, but results don't seem to be very different than when you'd treat the texture just as a 2d texture with stex3d. Not sure, but since apparently the 3rd texture unit is used to handle the depth dimension, it might maybe be necessary to route the 3rd (i.e. r) coordinate to the 3rd unit explicitly as the s coord of that unit (with the t coord set to 0), while only routing the two first coords (s,t) to the first unit? There is some info in the IRC logs: http://dri.sourceforge.net/IRC-logs/20040510.txt Created attachment 7064 [details] [review] new patch for enabling 3d textures New try for 3d textures, it now disables the perspective bit, as it just makes things worse. However, this still doesn't work. I'm now pretty sure that you indeed have to route the r coord manually as s coord to unit 2, and setup won't do that for you. (With this patch, you can see that r tex coord is not set up, just start multiarb demo (with unit 2 enabled) and you can see that the output of stex3d will change according to redraws of multiarb, and permanently change after multiarb has been closed.). If TXFORMAT_2 is initialized to use RADEON_TXFORMAT_ST_ROUTE_STQ0 (instead of STQ2) then you no longer have that problem, but it looks to me like the interpolator of unit 2 for the r coord will simply use the s coord (as a result s and r coord are always identical), which is obviously wrong. So, unless I'm missing some setup bits to change that, this makes 3d textures practically unimplementable. You could hack up tex gen / tex matrix stuff on unit 2 more or less easily in tcl mode, but I don't think the swtcl code could handle that easily. And noone really seemed to have missed that feature too hard, so you can see where this is heading... I hope nobody minds fielding newbie questions - can one of you explain what 3D texture maps are, and what they get used for? I understand 2D texture maps already, I think, but I'm not sure what is meant by 3D, the gl man page for glTexCoordxx is really terse, and searching online hasn't totally clarified it for me. I'll send a brief explanation to your email address, Simon. Mass version move, cvs -> git I am nearly certain that this got handled by the radeon-rewrite adventure; I distinctly remember Dave certifying that 3D textures work on r100. If not, go ahead and re-open... |
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.